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.

Última atualização: 2026-09-20

Diagnosticar os relatórios de conexões TLS falhadas (TLS-RPT)

Adotar MTA-STS ou DANE deixa uma coisa fora da vista: **se a entrega está falhando de verdade só o sabe o lado remetente.** TLS-RPT é o arranjo que preenche esse vazio. Escreva um endereço de relatório no registro TXT `_smtp._tls` e **os servidores remetentes lhe enviarão um relatório diário.** Esta ferramenta recolhe esse registro e comunica se a sua forma se ajusta à RFC 8460.

**TLS-RPT não é em si uma defesa, e sim um meio de observação.** Nada faz por deter um ataque; limita-se a dizer-lhe com que frequência o estabelecimento de TLS falhou. **Sem essa observação, porém, não há modo de julgar quando passar o MTA-STS a `enforce`.** Se a entrega se detivesse no instante em que começa a obrigatoriedade, você não o saberia até que alguém se queixasse. **A ordem assentada na prática consiste, portanto, em montar primeiro o TLS-RPT, ter o MTA-STS em `testing` enquanto se leem os relatórios, e passar a `enforce` só quando se estiver satisfeito de que nada falha.**

Como se usa

Insira o domínio Indique unicamente o domínio, na forma `example.com`.
Confira o registro TXT **Busque `v=TLSRPTv1` e um `rua=`.**
Confirme a forma do endereço de relatório Escreve-se com `mailto:` ou `https:`. **Confirme também que esse endereço possa receber de verdade.**
Decida quem lerá os relatórios **Montá-lo e nunca lê-los não conduz a nada.** Decida quem olha, e quando.

Dicas para aproveitar melhor

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.

Quando é útil

Antes de passar o MTA-STS à obrigatoriedade

**Você pode medir se algo está falhando enquanto se segue em `testing`**, o que lhe dá fundamento para decidir.

Advertir cedo um problema de entrega

Você fica sabendo que há falhas sem esperar que alguém lhe diga.

Vigiar depois de adotar DANE

**Um desajuste entre certificado e registro TLSA aparece nos relatórios como uma falha.**

Confirmar a forma do seu registro

Um erro em como se escreve `rua` manifesta-se em que não chega relatório algum.

Termos de TLS-RPT

_smtp._tls TXT: **O registro DNS que leva o endereço de relatório.** Escreve-se na forma `v=TLSRPTv1; rua=mailto:...`.
Rua: Aonde hão de ir os relatórios. **Indique um endereço de correio ou um ponto HTTPS preparado para recebê-los.**
RFC 8460: A norma que define o formato de TLS-RPT e o conteúdo de um relatório.
Relatório diário: O relatório que um servidor remetente envia cobrindo um dia. Leva as contagens de êxitos e falhas e os motivos destas.
MTA-STS: O arranjo que impõe o TLS. **O TLS-RPT combina-se com ele para ver como essa imposição está resultando.**
DANE: O arranjo que valida certificados sobre a premissa do DNSSEC. **Os problemas daqui afloram também nos relatórios de TLS-RPT.**

Perguntas frequentes

O MTA-STS é o mecanismo de aplicação que força o TLS no e-mail recebido. O TLS-RPT é o mecanismo de observabilidade que relata se as conexões TLS estão de fato falhando. Eles são configurados de forma independente, e você pode adotar apenas um deles.

Não necessariamente — a maioria dos domínios ainda não usa TLS-RPT. Mas se você já adotou o MTA-STS ou o DANE, vale a pena configurar o TLS-RPT junto para conseguir detectar erros de configuração.

Para o endereço mailto: ou o endpoint https: informado no campo rua do registro TXT. É possível listar vários destinos separados por vírgulas.

Os relatórios são dados JSON estruturados, então a maioria dos operadores usa uma ferramenta de monitoramento ou script para agregação automática, em vez de lê-los manualmente. Vários fornecedores oferecem serviços dedicados de análise de relatórios.

Esta ferramenta verifica apenas a sintaxe e os campos obrigatórios (v, rua) do registro TXT. Ela não verifica se os relatórios realmente chegam, então, após a configuração, espere alguns dias e confirme se um e-mail de relatório realmente aparece.

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.

Ver todas as curiosidades