Por que monitorar os relatórios TLS-RPT?
O monitoramento TLS-RPT torna visíveis as falhas de criptografia SMTP que seu servidor nunca registra. É o único canal definido por uma norma (RFC 8460) pelo qual os remetentes informam o que quebrou no transporte. Sem ele, um e-mail recusado por um problema de TLS não deixa nenhum rastro do lado do destinatário. Sua reputação se desgasta. Seus usuários não esperam nada porque nem sabem que uma mensagem existia.
Três falhas voltam em quase todos os relatórios.
Um certificado expirado no MX faz a negociação criptografada falhar, e os remetentes em modo estrito rejeitam a mensagem em vez de entregá-la em texto simples. Uma política MTA-STS que aponta para um MX que sumiu produz o mesmo resultado: conexão recusada, e-mail que nunca chegou. E o pior continua sendo o downgrade de STARTTLS, quando um equipamento de rede retira o anúncio STARTTLS do diálogo SMTP. Os e-mails passam então em texto simples. Ninguém sabe. O relatório TLS-RPT, esse sim, enxerga.
Como configurar o monitoramento TLS-RPT em 3 passos
Passo 1: Adicione seu domínio
Faça login e adicione seu domínio. O CaptainDNS fornece um endereço de email para receber os relatórios do monitor e uma URL HTTPS alternativa.
Passo 2: Verifique a propriedade do domínio
Adicione o TXT de verificação do CaptainDNS para comprovar a propriedade do domínio. A verificação do domínio e a ativação não confirmam o recebimento de relatórios.
Passo 3: Publique o registro TLS-RPT
Confira a configuração do monitor para publicar o TXT _smtp._tls recomendado com o destino mailto. Confira os destinatários mantidos antes de substituir um TXT existente. Se a leitura DNS falhar, adicione apenas o fragmento em rua= sem remover outros destinatários, ou tente novamente para obter o valor completo.
O que é TLS-RPT?
O TLS-RPT (SMTP TLS Reporting), definido pela RFC 8460, permite aos remetentes participantes informar os resultados das conexões TLS. O TXT indica o destino dos relatórios, sem garantir o envio.
Exemplo de registro DNS:
_smtp._tls.captaindns.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt-TOKEN@mailsrv1.captaindns.com"
Exemplo ilustrativo: substitua TOKEN pelo token indicado na configuração do seu monitor. Para um TXT existente, use a recomendação do monitor para conferir os destinatários a manter. O fragmento mailto sozinho não é um TXT completo.
O que contém um relatório TLS-RPT?
Um relatório TLS-RPT é um documento JSON que agrega, numa janela de 24 horas, todas as tentativas de conexão TLS de um remetente para o seu domínio. Ele conta as sessões bem-sucedidas e as que falharam, e detalha cada falha por tipo. O CaptainDNS decodifica esse JSON e o exibe de forma legível.
| Campo | Descrição |
|---|---|
| Organização remetente | O provedor de e-mail que enviou o relatório |
| Período | Timestamps de início e fim da janela de relatório |
| Políticas aplicadas | Políticas MTA-STS, DANE ou STARTTLS detectadas |
| Sessões bem-sucedidas | Número de conexões TLS estabelecidas com sucesso |
| Sessões com falha | Número de falhas de negociação TLS com detalhes do erro |
Os 11 tipos de falha TLS-RPT (RFC 8460)
O §4.3 da RFC 8460 define 11 valores de result-type, e o monitoramento reporta todos eles. Alguns remetentes emitem ainda starttls-not-offered, uma variante de starttls-not-supported alheia à RFC: é tratada da mesma forma.
| Tipo de falha | Descrição |
|---|---|
starttls-not-supported | O servidor destinatário não suporta STARTTLS |
certificate-expired | O certificado TLS apresentado pelo MX expirou |
certificate-host-mismatch | O certificado não corresponde ao nome de host do MX |
certificate-not-trusted | A cadeia de certificados não é confiável para o remetente |
validation-failure | Falha de validação TLS genérica |
tlsa-invalid | O registro DANE TLSA é inválido ou não corresponde |
dnssec-invalid | A cadeia DNSSEC necessária ao DANE está quebrada ou ausente |
dane-required | DANE é necessário, mas não pôde ser validado |
sts-policy-fetch-error | Impossível obter a política MTA-STS (HTTPS ou DNS) |
sts-policy-invalid | A política MTA-STS não pôde ser validada |
sts-webpki-invalid | O host da política MTA-STS tem um certificado Web PKI inválido |
TLS-RPT vs DMARC
| TLS-RPT | DMARC | |
|---|---|---|
| Protege | Criptografia do transporte (SMTP TLS) | Autenticação do remetente (SPF/DKIM) |
| Reporta | Falhas de conexão TLS, erros de certificado | Falhas de alinhamento de autenticação |
| RFC | RFC 8460 | RFC 7489 |
| Registro DNS | _smtp._tls TXT | _dmarc TXT |
| Ameaças detectadas | Certificados expirados, remoção STARTTLS, erros DANE/MTA-STS | Falsificação, phishing, usurpação de domínio |
Os dois protocolos são complementares. Implemente o monitoramento DMARC junto com TLS-RPT para visibilidade completa sobre a segurança do e-mail.
Quem envia relatórios TLS-RPT?
Os relatórios vêm de remetentes que oferecem suporte a TLS-RPT e tentam entregar email ao seu domínio. A disponibilidade e a frequência dependem do tráfego e da implementação de cada remetente. Publicar o TXT não garante relatórios de um provedor específico.
Casos de uso concretos
A maioria dos incidentes TLS se resolve em uma hora quando você os vê, e se arrasta por semanas quando não vê. Veja duas falhas reais que o monitoramento TLS-RPT trouxe à tona.
Incidente 1: Certificado expirado não detectado
Sintoma: Grandes remetentes (Google, Microsoft) reportam falhas certificate-expired em seus relatórios TLS-RPT.
Diagnóstico: O painel do CaptainDNS mostra um pico de falhas nas últimas 24h, todas relacionadas a um certificado Let's Encrypt expirado no MX principal. Sem TLS-RPT, o problema teria ficado invisível por semanas.
Ação: Renovar o certificado TLS do servidor de e-mail. Os relatórios seguintes confirmam a resolução.
Incidente 2: Política MTA-STS dessincronizada
Sintoma: Relatórios indicam falhas sts-policy-invalid apesar de uma política MTA-STS publicada.
Diagnóstico: Os relatórios TLS-RPT revelam que a política MTA-STS referencia um servidor MX que não existe mais. Remetentes estritos abandonam a entrega sem notificar o destinatário.
Ação: Atualizar a política MTA-STS para refletir os MX atuais.
O CaptainDNS analisa os relatórios recebidos sem servidores para gerenciar nem JSON para decodificar. O envio depende dos remetentes e do tráfego para seu domínio.
FAQ - Perguntas frequentes
P: O que é um registro TLS-RPT?
R: Um registro TLS-RPT é um registro DNS TXT colocado em _smtp._tls.seudominio.com. Ele contém uma diretiva rua= que indica aos servidores remetentes para onde enviar os relatórios de falha TLS (RFC 8460).
P: O monitoramento TLS-RPT do CaptainDNS é gratuito?
R: A primeira ferramenta da sua conta é gratuita. Cada domínio TLS-RPT conta como uma ferramenta: depois, 3 €/mês sem impostos. Sem taxas ocultas, sem período de teste.
P: Como configuro meu domínio para enviar os relatórios para cá?
R: Confira a configuração do monitor para publicar o TXT _smtp._tls recomendado com o destino mailto. Confira os destinatários mantidos antes de substituir um TXT existente. Se a leitura DNS falhar, adicione apenas o fragmento em rua= sem remover outros destinatários, ou tente novamente para obter o valor completo.
P: Quais formatos de relatório são aceitos?
R: Aceitamos relatórios TLS-RPT JSON definidos pela RFC 8460, com ou sem compressão gzip, por email e HTTPS POST. O email é o destino recomendado; HTTPS continua sendo suportado.
P: Como funciona a verificação de domínio?
R: Adicione o TXT de verificação do CaptainDNS para comprovar a propriedade do domínio. A verificação do domínio e a ativação não confirmam o recebimento de relatórios.
P: Preciso de MTA-STS para usar TLS-RPT?
R: Não, o TLS-RPT funciona de forma independente. No entanto, combinar MTA-STS com TLS-RPT é recomendado: o MTA-STS impõe a criptografia, e o TLS-RPT informa quando os remetentes não conseguem cumpri-la.
P: Quais os riscos sem TLS-RPT?
R: Sem TLS-RPT, falhas de entrega TLS são completamente invisíveis. Um certificado expirado pode bloquear e-mails de Google e Microsoft por dias. Uma política MTA-STS desatualizada faz remetentes rejeitarem suas conexões em silêncio. Você só descobre o problema quando alguém reclama, tarde demais.
P: Com que frequência os relatórios chegam?
R: Os remetentes que oferecem suporte a TLS-RPT geralmente enviam relatórios por períodos de 24 horas. O recebimento depende desses remetentes e do tráfego. Não há prazo garantido para o primeiro relatório; os relatórios recebidos são analisados depois no painel.
P: Quais tipos de falha TLS o TLS-RPT reporta?
R: O TLS-RPT cobre os 11 tipos de falha definidos na RFC 8460: starttls-not-supported, certificate-expired, certificate-host-mismatch, certificate-not-trusted, validation-failure, tlsa-invalid, dnssec-invalid, dane-required, sts-policy-fetch-error, sts-policy-invalid e sts-webpki-invalid. Cada tipo indica um problema específico na cadeia de negociação TLS ou validação de política.
P: Qual é a diferença entre TLS-RPT e DMARC?
R: TLS-RPT e DMARC protegem camadas diferentes. DMARC (RFC 7489) verifica a autenticação do remetente por alinhamento SPF e DKIM e combate falsificação e phishing. TLS-RPT (RFC 8460) monitora a criptografia do transporte e reporta quando conexões SMTP TLS falham, certificados expiram ou STARTTLS é rebaixado. Ambos são essenciais.
Ferramentas complementares
| Ferramenta | Utilidade |
|---|---|
| Verificação de sintaxe TLS-RPT | Validar a sintaxe de um registro TLS-RPT |
| Verificação de registro TLS-RPT | Verificar o registro TLS-RPT DNS do seu domínio |
| Gerador TLS-RPT | Gerar um registro DNS TLS-RPT |
| Leitor de relatórios TLS-RPT | Analisar manualmente um relatório JSON TLS-RPT |
| Hospedagem MTA-STS | Hospedar sua política MTA-STS (primeira ferramenta grátis, depois €3/mês sem impostos) |
| Monitoramento DMARC | Monitorar e analisar relatórios agregados DMARC |
Recursos úteis
- RFC 8460 - SMTP TLS Reporting: Especificação oficial TLS-RPT
- RFC 8461 - MTA-STS: Padrão complementar para impor criptografia SMTP
- Google: Configurar relatórios TLS: Guia do Google Workspace para TLS-RPT