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 escorrega. Seus usuários não esperam nada porque ignoram que uma mensagem existia.
Três panes 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. O correio passa 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 registre o domínio a ser monitorado. O CaptainDNS gera um coletor de relatórios HTTPS exclusivo e o registro DNS TLS-RPT correspondente.
Passo 2: Verifique a propriedade do domínio
Adicione o registro TXT de verificação ao seu DNS. A validação é automática assim que o registro for detectado.
Passo 3: Publique o registro TLS-RPT
Adicione o registro TXT _smtp._tls fornecido ao seu DNS. Os servidores remetentes começarão a enviar relatórios de falha TLS para o seu endpoint CaptainDNS.
O que é TLS-RPT?
TLS-RPT (SMTP TLS Reporting) é um padrão definido pela RFC 8460 que faz os remetentes reportarem ao domínio destinatário cada negociação TLS que falha. Os servidores remetentes sinalizam toda conexão criptografada que não se completa. Um único registro DNS basta para acioná-los.
Exemplo de registro DNS:
_smtp._tls.captaindns.com. IN TXT "v=TLSRPTv1; rua=https://api.captaindns.com/tls-rpt/ingest/abc123"
O registro _smtp._tls indica aos servidores remetentes para onde enviar seus relatórios JSON quando uma conexão TLS falha com o seu domínio.
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 |
Tipos de falha TLS-RPT (RFC 8460)
| 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 |
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 |
tlsa-invalid | O registro DANE TLSA é inválido ou não corresponde |
dane-required | DANE é necessário, mas não pôde ser validado |
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 grandes provedores de e-mail emitem relatórios TLS-RPT assim que tentam uma conexão TLS para o seu domínio. Sozinhos, Google e Microsoft entregam a maior parte do correio recebido por um domínio profissional típico. Você recebe e-mail de algum deles? Então um registro TLS-RPT publicado já lhe dá uma cobertura útil.
- Google (Gmail, Workspace): Envia relatórios agregados diários cobrindo todas as tentativas de conexão
- Microsoft (Outlook, Exchange Online): Reporta falhas de negociação TLS para os locatários Microsoft 365
- Yahoo: Fornece dados TLS-RPT para a infraestrutura Yahoo Mail e AOL
- Apple (iCloud Mail): Reporta falhas TLS para a entrega do iCloud Mail
- Comcast: Um dos primeiros ISPs a implementar o reporting TLS-RPT
Publique um registro TLS-RPT e esses provedores começam a reportar automaticamente. Não é preciso se inscrever junto a cada provedor.
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 panes 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.
Nos dois casos, o gatilho é o mesmo: um relatório TLS-RPT lido na hora certa. Adicione seu domínio ao CaptainDNS, publique o registro _smtp._tls, e esses sinais chegam ao seu painel sem nenhum servidor para gerenciar.
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: Sim, o serviço de monitoramento TLS-RPT é totalmente gratuito. Acreditamos que todo domínio deveria poder monitorar sua segurança TLS sem restrições técnicas.
P: Como configuro meu domínio para enviar os relatórios para cá?
R: Adicione um registro TXT em _smtp._tls.seudominio.com com o valor v=TLSRPTv1; rua=https://api.captaindns.com/tls-rpt/ingest/{seu-token}. O registro exato é fornecido quando você adiciona seu domínio.
P: Quais formatos de relatório são aceitos?
R: Aceitamos relatórios TLS-RPT no formato JSON conforme definido pela RFC 8460, comprimidos (gzip) ou não. Os relatórios são aceitos via HTTPS POST.
P: Como funciona a verificação de domínio?
R: Você adiciona um registro TXT de verificação fornecido pelo CaptainDNS ao seu DNS. Assim que for detectado, a propriedade do domínio é confirmada e o monitoramento dos relatórios é ativado.
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 relatórios são analisados e disponibilizados no seu painel em poucos segundos após a recepção. A maioria dos provedores de e-mail envia relatórios diariamente.
P: Quais tipos de falha TLS o TLS-RPT reporta?
R: O TLS-RPT cobre todos os tipos de falha definidos na RFC 8460: starttls-not-supported, certificate-expired, certificate-host-mismatch, certificate-not-trusted, validation-failure, sts-policy-invalid, sts-webpki-invalid, tlsa-invalid e dane-required. 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 gratuitamente sua política MTA-STS |
| 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