TLS-RPT: o guia completo para monitorar a segurança TLS dos seus emails

Q: Como configurar um registro TLS-RPT?

Publique um registro DNS TXT em _smtp._tls.captaindns.com com o valor v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com . Use um gerador TLS-RPT para criar o registro e depois adicione-o na sua zona DNS. Os primeiros relatórios chegam em 24 a 48 horas.

Por CaptainDNS
Publicado em 10 de fevereiro de 2026

TLS-RPT: monitorar falhas de criptografia TLS na entrega de emails

TL;DR

TLS-RPT (RFC 8460) envia a você um relatório diário sobre cada falha de criptografia TLS detectada pelos servidores que enviam emails para o seu domínio
Sem TLS-RPT, você não sabe se seus emails estão chegando em texto plano por causa de um certificado expirado, um MX mal configurado ou um ataque de downgrade
Basta publicar um único registro DNS TXT: _smtp._tls.captaindns.com com a diretiva v=TLSRPTv1; rua=mailto:...
TLS-RPT é o complemento indispensável do MTA-STS: ele fornece a visibilidade necessária antes de ativar o modo enforce

Seu domínio usa MTA-STS ou está pensando em ativá-lo? Você configurou STARTTLS nos seus servidores de email? Nos dois casos, uma pergunta fica sem resposta: como saber se a criptografia TLS está realmente funcionando durante a entrega dos seus emails?

É exatamente esse o problema que o TLS-RPT resolve. Definido na RFC 8460, o SMTP TLS Reporting é um mecanismo que permite aos servidores remetentes (Gmail, Microsoft, Yahoo e todos os provedores compatíveis) enviar a você relatórios detalhados sobre as falhas de negociação TLS que encontram ao tentar entregar emails ao seu domínio.

Este guia explica o que é TLS-RPT, como funciona, como configurá-lo em poucos minutos e como interpretar os relatórios que você receberá. Seja você administrador de sistemas, DevOps ou responsável pela infraestrutura de email, aqui você encontra tudo o que precisa para implantar o TLS-RPT no seu domínio.

O que é TLS-RPT?

TLS-RPT, sigla para SMTP TLS Reporting, é um padrão da internet (RFC 8460) publicado em setembro de 2018. Seu papel é simples: permitir que o proprietário de um domínio receba relatórios sobre as tentativas de conexão TLS que falham quando servidores tentam entregar emails a ele.

Na prática, quando o Gmail tenta enviar um email para contact@captaindns.com, ele verifica se o servidor de recepção suporta TLS e se a negociação TLS é bem-sucedida. Se algo falha (certificado expirado, STARTTLS não suportado, política MTA-STS não respeitada), o Gmail registra essa falha. Uma vez por dia, ele agrega todas as falhas e envia um relatório JSON para o endereço especificado no seu registro TLS-RPT.

Por que TLS-RPT é indispensável?

Sem TLS-RPT, você fica às cegas sobre a qualidade da criptografia dos seus emails recebidos:

Um certificado TLS expira no seu servidor MX → os emails continuam chegando (em texto plano se o MTA-STS não estiver em modo enforce), mas você não sabe
Um MX secundário não suporta STARTTLS → os emails para esse MX trafegam sem criptografia
Um ataque man-in-the-middle força um downgrade → impossível detectar sem relatórios

TLS-RPT preenche essa lacuna. Você recebe diariamente um balanço preciso: quantas conexões TLS foram bem-sucedidas, quantas falharam e por que falharam.

Diagrama comparativo: sem TLS-RPT vs com TLS-RPT, visibilidade sobre falhas TLS

Qual a diferença entre TLS-RPT e relatórios DMARC?

Os relatórios DMARC (RUA/RUF) e os relatórios TLS-RPT cobrem áreas diferentes:

Critério	Relatórios DMARC	TLS-RPT
O que monitora	A autenticação dos emails (SPF, DKIM, alinhamento)	A criptografia do transporte (TLS)
RFC	RFC 7489	RFC 8460
Registro DNS	`_dmarc.domínio`	`_smtp._tls.domínio`
Formato do relatório	XML (agregado) ou texto (forense)	JSON
Frequência	Configurável (geralmente 24h)	Sempre 24h
Protocolo	Autenticação do remetente	Segurança do canal de transporte

Os dois são complementares: o DMARC verifica quem envia o email, o TLS-RPT verifica como o email é transportado. Um domínio seguro precisa dos dois.

Como funciona o TLS-RPT?

O mecanismo TLS-RPT se integra ao fluxo normal de entrega de emails:

1. Publicação do registro DNS

Você publica um registro TXT em _smtp._tls.captaindns.com que contém o endereço onde receber os relatórios.

2. Detecção pelo servidor remetente

Quando o Gmail (ou qualquer outro servidor compatível) quer enviar um email para o seu domínio, ele faz uma consulta DNS em _smtp._tls.captaindns.com para verificar se você configurou o TLS-RPT.

3. Coleta dos resultados TLS

A cada tentativa de entrega, o servidor remetente registra o resultado da negociação TLS: sucesso ou falha, com o tipo de erro quando aplicável.

4. Agregação e envio do relatório

A cada 24 horas, o servidor remetente agrega os resultados e envia um relatório JSON para o endereço rua especificado no seu registro TLS-RPT.

Quem envia os relatórios?

Os principais provedores que enviam relatórios TLS-RPT:

Provedor	Endereço de envio	Suportado
Google / Gmail	`noreply-smtp-tls-reporting@google.com`	Sim
Microsoft / Outlook	`tlsrpt@microsoft.com`	Sim
Yahoo / AOL	Variável	Sim
LinkedIn	Variável	Sim
Comcast	Variável	Sim

Se você receber um email de noreply-smtp-tls-reporting@google.com, não se preocupe: é um relatório TLS-RPT legítimo enviado pelo Google. Ele contém um arquivo JSON compactado (gzip) detalhando os resultados TLS das últimas 24 horas.

A sintaxe do registro TLS-RPT

O registro TLS-RPT é um registro DNS TXT publicado em _smtp._tls.<domínio>.

Formato básico

_smtp._tls.captaindns.com. 300 IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com"

Tag	Obrigatório	Descrição
`v`	Sim	Versão do protocolo, sempre `TLSRPTv1`
`rua`	Sim	URI(s) de destino dos relatórios (`mailto:` ou `https:`)

Exemplos de configurações válidas

Relatórios por email (o mais comum):

_smtp._tls.captaindns.com. TXT "v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com"

Relatórios por endpoint HTTPS:

_smtp._tls.captaindns.com. TXT "v=TLSRPTv1; rua=https://report.captaindns.com/tlsrpt"

Relatórios múltiplos (email + HTTPS):

_smtp._tls.captaindns.com. TXT "v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com,https://report.captaindns.com/tlsrpt"

Relatórios para um domínio externo

Quando você envia os relatórios para um domínio diferente do seu (por exemplo, um serviço terceirizado de monitoramento), o domínio destinatário deve publicar um registro de autorização:

captaindns.com._report._tls.monitoring-tiers.com. TXT "v=TLSRPTv1"

Esse mecanismo impede que um invasor redirecione os relatórios para um domínio não autorizado. Sempre verifique se o domínio externo publicou corretamente esse registro de autorização.

Dicas de configuração

Caixa dedicada: use um endereço de email dedicado (ex: tlsrpt@captaindns.com) para não misturar os relatórios com sua caixa de entrada principal
TTL razoável: um TTL de 300 a 3.600 segundos é adequado para esse registro
HTTPS para alto volume: se você recebe muitos emails, um endpoint HTTPS é mais adequado do que uma caixa de email para processar os relatórios

Entendendo o relatório JSON TLS-RPT

Os relatórios TLS-RPT são enviados em formato JSON, compactados em gzip. Veja a estrutura de um relatório típico:

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-02-08T00:00:00Z",
    "end-datetime": "2026-02-09T00:00:00Z"
  },
  "contact-info": "smtp-tls-reporting@google.com",
  "report-id": "2026-02-08T00:00:00Z_captaindns.com",
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-string": [
          "version: STSv1",
          "mode: enforce",
          "mx: mail.captaindns.com",
          "max_age: 604800"
        ],
        "policy-domain": "captaindns.com"
      },
      "summary": {
        "total-successful-session-count": 4523,
        "total-failure-session-count": 2
      },
      "failure-details": [
        {
          "result-type": "certificate-expired",
          "sending-mta-ip": "192.0.2.1",
          "receiving-mx-hostname": "mail.captaindns.com",
          "failed-session-count": 2
        }
      ]
    }
  ]
}

Detalhamento do relatório

Campo	Significado
`organization-name`	Quem envia o relatório (Google, Microsoft, etc.)
`date-range`	Período coberto (sempre 24h)
`policy-type`	Tipo de política aplicada: `sts` (MTA-STS), `tlsa` (DANE) ou `no-policy-found`
`total-successful-session-count`	Número de conexões TLS bem-sucedidas
`total-failure-session-count`	Número de conexões TLS com falha
`failure-details`	Detalhes de cada tipo de falha

Os tipos de falhas TLS

Cada falha é categorizada por um result-type. Veja os principais:

Código	Descrição	Gravidade	Ação
`starttls-not-supported`	O servidor MX não suporta STARTTLS	Crítica	Ativar STARTTLS no servidor
`certificate-expired`	O certificado TLS do servidor expirou	Crítica	Renovar o certificado imediatamente
`certificate-host-mismatch`	O certificado não corresponde ao hostname do MX	Crítica	Corrigir o certificado ou o hostname
`certificate-not-trusted`	Certificado não assinado por uma CA confiável	Elevada	Usar um certificado de uma CA reconhecida
`validation-failure`	Falha genérica de validação TLS	Elevada	Verificar a configuração TLS completa
`sts-policy-fetch-error`	Impossível obter a política MTA-STS	Média	Verificar o arquivo `mta-sts.txt`
`sts-policy-invalid`	A política MTA-STS é inválida	Média	Corrigir a sintaxe da política
`sts-webpki-invalid`	O certificado HTTPS do servidor de política é inválido	Média	Renovar o certificado do subdomínio `mta-sts`
`tlsa-invalid`	Registro TLSA inválido (DANE)	Média	Corrigir os registros TLSA
`dnssec-invalid`	Validação DNSSEC falhou	Elevada	Verificar a configuração DNSSEC

Tabela resumo dos tipos de falha TLS-RPT com gravidade e ação recomendada

TLS-RPT e MTA-STS: a dupla indispensável

TLS-RPT faz total sentido quando combinado com o MTA-STS. Veja por quê:

O fluxo recomendado

Configurar TLS-RPT: publique seu registro _smtp._tls para começar a receber relatórios
Ativar MTA-STS em modo testing: publique sua política MTA-STS com mode: testing
Analisar os relatórios: durante 1 a 2 semanas, os relatórios TLS-RPT mostram se há conexões TLS falhando
Corrigir os problemas: certificados expirados, MX não cobertos, configurações TLS incorretas
Passar para o modo enforce: quando os relatórios confirmarem zero falhas, mude o MTA-STS para mode: enforce

Sem TLS-RPT, passar para o modo enforce é como navegar às cegas: você corre o risco de rejeitar emails legítimos sem saber.

TLS-RPT também funciona com DANE

TLS-RPT não se limita ao MTA-STS. Ele também reporta falhas relacionadas aos registros DANE TLSA (RFC 7672). Se o seu domínio usa DNSSEC e publica registros TLSA, os relatórios TLS-RPT incluirão os resultados de validação DANE com o policy-type: tlsa.

Configurar TLS-RPT em 5 minutos

Etapa 1: Escolher o endereço de relatórios

Crie um endereço de email dedicado para receber os relatórios:

tlsrpt@captaindns.com (recomendado)
Ou use um endpoint HTTPS se você tiver um sistema de processamento automatizado

Etapa 2: Gerar o registro DNS

Use nosso gerador TLS-RPT para criar o registro adequado ao seu domínio. Você obterá um registro pronto para copiar.

Etapa 3: Publicar o registro DNS

Adicione o registro TXT na sua zona DNS:

Campo	Valor
Host	`_smtp._tls`
Tipo	`TXT`
Valor	`v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com`
TTL	`3600`

Etapa 4: Verificar a configuração

Use nosso validador de sintaxe TLS-RPT para verificar se o seu registro está formatado corretamente.

Etapa 5: Aguardar os primeiros relatórios

Os relatórios geralmente chegam 24 a 48 horas após a publicação do registro. O Google costuma ser o primeiro a enviar relatórios.

Erros comuns e solução de problemas

Nenhum relatório recebido após 48 horas

Verifique se o registro está publicado em _smtp._tls.captaindns.com (não em _smtp-tls ou smtp._tls)
Verifique a sintaxe: v=TLSRPTv1 (não v=TLSRPTv2 nem v=TLSRPT1)
Certifique-se de que a caixa de email de recebimento existe e aceita anexos gzip
Verifique se o seu domínio recebe emails suficientes para gerar relatórios

Os relatórios chegam mas estão vazios

Se total-failure-session-count está sempre em 0, isso é uma boa notícia: sua configuração TLS está funcionando corretamente. Os relatórios confirmam que todas as conexões TLS estão sendo bem-sucedidas.

Emails de `noreply-smtp-tls-reporting@google.com`

Esses emails são legítimos. O Google envia um relatório TLS-RPT diário para cada domínio que publicou um registro _smtp._tls. O arquivo anexo (.json.gz) contém o relatório. Não marque esses emails como spam.

🎯 Plano de ação recomendado

Publique seu registro TLS-RPT: 5 minutos com o gerador TLS-RPT (veja a etapa 2 acima)
Configure o MTA-STS em modo testing: ative a política MTA-STS para que os relatórios TLS-RPT incluam os resultados de validação
Analise os relatórios por 2 semanas: identifique as falhas TLS e corrija-as
Mude o MTA-STS para o modo enforce: quando os relatórios estiverem limpos, ative a rejeição de conexões TLS com falha
Monitore continuamente: os relatórios diários alertam você sobre qualquer novo problema (certificado expirado, mudança de MX, etc.)

FAQ

O que é TLS-RPT e para que serve?

TLS-RPT (SMTP TLS Reporting, RFC 8460) é um mecanismo que permite ao proprietário de um domínio receber relatórios diários sobre falhas de negociação TLS durante a entrega de emails. Ele fornece visibilidade completa sobre a qualidade da criptografia dos seus emails recebidos.

Como configurar um registro TLS-RPT?

Publique um registro DNS TXT em _smtp._tls.captaindns.com com o valor v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com. Use um gerador TLS-RPT para criar o registro e depois adicione-o na sua zona DNS. Os primeiros relatórios chegam em 24 a 48 horas.

Por que estou recebendo emails de noreply-smtp-tls-reporting@google.com?

Esses emails são relatórios TLS-RPT legítimos enviados pelo Google. Seu domínio tem um registro _smtp._tls configurado, e o Google envia diariamente um relatório JSON compactado detalhando os resultados de negociação TLS dos emails que ele enviou para você.

Qual é a diferença entre TLS-RPT e relatórios DMARC?

O DMARC monitora a autenticação dos emails (SPF, DKIM, alinhamento), enquanto o TLS-RPT monitora a criptografia do transporte (TLS). O DMARC verifica quem envia o email, o TLS-RPT verifica como ele é transportado. Os dois são complementares e recomendados juntos.

TLS-RPT é obrigatório se eu uso MTA-STS?

Não, TLS-RPT não é tecnicamente obrigatório para o MTA-STS. Mas é altamente recomendado: sem TLS-RPT, você não saberá se conexões TLS estão falhando. Isso é particularmente crítico antes de mudar o MTA-STS para o modo enforce, pois os relatórios permitem identificar e corrigir problemas antecipadamente.

Com que frequência os relatórios TLS-RPT são enviados?

Os relatórios TLS-RPT são enviados uma vez por dia (período de 24 horas). Cada provedor compatível (Google, Microsoft, Yahoo, etc.) envia seu próprio relatório de forma independente. Portanto, você pode receber vários relatórios por dia, um por provedor.

Como ler um relatório TLS-RPT em JSON?

Um relatório TLS-RPT é um arquivo JSON compactado em gzip. Ele contém a organização remetente, o período coberto e, para cada política TLS (MTA-STS ou DANE): o número de sessões bem-sucedidas, o número de falhas e o detalhe de cada tipo de falha (certificado expirado, STARTTLS não suportado, etc.).

É possível usar mailto: e https: ao mesmo tempo no TLS-RPT?

Sim, você pode especificar vários URIs de relatórios separados por vírgulas. Por exemplo: rua=mailto:tlsrpt@captaindns.com,https://report.captaindns.com/tlsrpt. O endpoint HTTPS é recomendado para domínios com alto volume de emails.

📖 Glossário

TLS-RPT: SMTP TLS Reporting, mecanismo de relatório sobre falhas TLS definido na RFC 8460.
MTA-STS: Mail Transfer Agent Strict Transport Security (RFC 8461), política que impõe a criptografia TLS para a recepção de emails.
DANE: DNS-Based Authentication of Named Entities (RFC 7672), mecanismo alternativo ao MTA-STS que usa DNSSEC e registros TLSA para validar certificados TLS.
STARTTLS: Extensão SMTP que permite criptografar uma conexão inicialmente em texto plano. Oportunista por padrão (sem rejeição se a criptografia falhar).
Ataque de downgrade: Ataque em que um intermediário força a conexão a permanecer em texto plano, removendo o comando STARTTLS da resposta do servidor.
RUA: Reporting URI for Aggregated reports, o endereço para onde os relatórios TLS-RPT são enviados.

Verifique sua configuração agora: Use nosso verificador TLS-RPT para analisar o registro _smtp._tls do seu domínio em poucos segundos.