Verificador de registros TLS-RPT (SMTP TLS Reporting)
Obtém o registro TXT _smtp._tls de um domínio para diagnosticar se o destino dos relatórios (rua) de conexões TLS malsucedidas está configurado corretamente conforme a RFC 8460. Útil junto com MTA-STS/DANE.
Dicas
- O TLS-RPT é declarado pelo domínio receptor, mas é consumido pelos servidores de e-mail remetentes, que o usam para saber para onde enviar as estatísticas sempre que uma conexão TLS com o seu domínio falha.
- O campo rua pode listar um endereço mailto:, um endpoint https:, ou ambos, separados por vírgulas, permitindo enviar os relatórios simultaneamente para uma caixa de e-mail e para um coletor automatizado.
- Os relatórios chegam em formato JSON (application/tlsrpt+json, muitas vezes compactado com gzip), por isso é útil preparar um analisador ou caixa de e-mail dedicados em vez de esperar lê-los manualmente.
- Logo após implantar o MTA-STS ou o DANE, vale a pena acompanhar os relatórios do TLS-RPT por um tempo para detectar qualquer erro de configuração que possa ter passado despercebido.
- Os principais provedores de e-mail, como Google, Microsoft e Yahoo, enviam relatórios TLS-RPT, então domínios que trocam muitos e-mails com eles se beneficiam mais ao adotá-lo.
Perguntas frequentes
Curiosidade — A lacuna da "falha silenciosa" que o TLS-RPT veio fechar
O TLS-RPT (TLS Reporting, RFC 8460) foi publicado em 2018, quase junto com o MTA-STS (RFC 8461). Os dois foram desenvolvidos no mesmo grupo de trabalho e têm muito em comum — ambos se baseiam em um registro TXT de DNS, e ambos foram impulsionados conjuntamente por Google, Microsoft, Yahoo e outros —, mas desempenham papéis bem diferentes. O MTA-STS é a camada de aplicação que força o uso de TLS; o TLS-RPT é a camada de observabilidade que revela o que de fato aconteceu depois disso.
Antes da existência do TLS-RPT, uma falha no handshake TLS durante a entrega via SMTP era, na maioria dos casos, registrada apenas no servidor remetente, sem que o administrador do domínio receptor fosse notificado. Um certificado expirado ou uma política MTA-STS mal configurada podiam interromper silenciosamente a entrega de e-mails, e ninguém percebia até que os e-mails realmente parassem de chegar — um verdadeiro ponto cego operacional.
Com o TLS-RPT em vigor, um relatório agregado diário é enviado ao destino indicado em rua. O relatório é um JSON estruturado (application/tlsrpt+json, frequentemente compactado com gzip) contendo o número de sucessos e falhas e, no caso de falhas, a causa subjacente (incompatibilidade de certificado, falha na negociação STARTTLS etc.) — pensado para ser processado por ferramentas de monitoramento, não lido por uma pessoa.
Na prática, o TLS-RPT costuma ser configurado junto com o MTA-STS ou o DANE. Implantar apenas a aplicação forçada não permite perceber se um erro de configuração está bloqueando silenciosamente e-mails legítimos; monitorar os relatórios do TLS-RPT permite implantar essa aplicação forçada com segurança.