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 Cʼhwevrer 2026

Atualizado em 30 Mezheven 2026

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

TL;DR

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

O seu domínio usa MTA-STS ou está pensando ativá-lo? Configurou STARTTLS nos seus servidores de email? Em ambos os casos, uma pergunta fica sem resposta: como saber se a criptografia TLS está realmente a funcionar 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 emissores (Gmail, Microsoft, Yahoo e todos os fornecedores que o suportam) enviar para 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 é o TLS-RPT, como funciona, como configurá-lo em poucos minutos e como interpretar os relatórios que você vai receber. Seja você administrador de sistemas, DevOps ou responsável pela infraestrutura de email, aqui você encontra tudo o que precisa para implementar o TLS-RPT no seu domínio.

O que é o TLS-RPT?

O TLS-RPT, sigla de SMTP TLS Reporting, é uma norma da internet (RFC 8460) publicada em setembro de 2018. O 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 para você.

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 o TLS-RPT é indispensável?

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

Um certificado TLS expira no seu servidor MX → os emails continuam a chegar (em texto claro se o MTA-STS não estiver em modo enforce), mas você não sabe disso
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 de detectar sem relatórios

O TLS-RPT preenche essa lacuna. Você recebe diariamente um balanço preciso: quantas conexões TLS foram bem-sucedidas, quantas falharam e porque 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.dominio`	`_smtp._tls.dominio`
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 de ambos.

Como funciona o TLS-RPT?

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

1. Publicação do registro DNS

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 emissor

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 emissor 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 emissor 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 fornecedores que enviam relatórios TLS-RPT:

Fornecedor	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 pela Google. Contém um arquivo JSON comprimido (gzip) que detalha 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.<dominio>.

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

Você pode perfeitamente enviar os seus relatórios TLS-RPT para um domínio diferente do seu, por exemplo um serviço terceiro de monitoramento. Ao contrário do DMARC, o TLS-RPT não exige qualquer registro de autorização do lado do domínio destinatário: basta apontar a rua para o endereço do terceiro e os relatórios são enviados diretamente para lá.

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

É uma escolha deliberada dos autores da RFC 8460. A seção 7 (Security Considerations) afasta voluntariamente o mecanismo de verificação de delegação usado pelo DMARC, considerado supérfluo aqui: o risco de amplificação é menor do que com o DMARC. Para desviar relatórios, um atacante teria primeiro de conseguir fazer enviar correio para o domínio-alvo a fim de despoletar a geração de relatórios, o que torna o abuso pouco praticável.

Não confundir com o DMARC. No DMARC, apontar uma rua/ruf para um domínio terceiro impõe que este publique um registro de consentimento da forma dominio-origem._report._dmarc.terceiro. Esse mecanismo não existe no TLS-RPT: não há qualquer registro _report._tls a publicar do lado do destinatário. Uma documentação que o exija decalca por engano o funcionamento do DMARC.

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 a sua caixa de entrada principal
TTL razoável: um TTL de 300 a 3600 segundos é adequado para este registro
HTTPS para volume: se recebe muitos emails, um endpoint HTTPS é mais adequado do que uma caixa de email para processar os relatórios

Compreender o relatório JSON TLS-RPT

Os relatórios TLS-RPT são enviados em formato JSON, comprimidos com 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
        }
      ]
    }
  ]
}

Detalhe 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`	Detalhe 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 de confiança	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

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

O fluxo recomendado

Configurar o TLS-RPT: publique o seu registro _smtp._tls para começar a receber relatórios
Ativar o MTA-STS em modo testing: publique a 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 ao modo enforce: quando os relatórios confirmarem zero falhas, mude o MTA-STS para mode: enforce

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

O TLS-RPT também funciona com o DANE

O TLS-RPT não se limita ao MTA-STS. Também reporta falhas relacionadas com os 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 o 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 o nosso gerador TLS-RPT para criar o registro adequado ao seu domínio. Você vai obter um registro pronto a 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 o 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 chegam geralmente 24 a 48 horas após a publicação do registro. A Google costuma ser a primeira a enviar relatórios.

Erros comuns e resoluçã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 recepção 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, é uma boa notícia: a 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`

Estes emails são legítimos. A 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 estes emails como spam.

🎯 Plano de ação recomendado

Publique o 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 durante 2 semanas: identifique as falhas TLS e corrija-as
Passe 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-no sobre qualquer novo problema (certificado expirado, mudança de MX, etc.)

FAQ

O que é o TLS-RPT e para que serve?

O TLS-RPT (SMTP TLS Reporting, RFC 8460) é um mecanismo que permite ao proprietário de um domínio receber relatórios diários sobre as falhas de negociação TLS durante a entrega de emails. Dá a você 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 recebo emails de noreply-smtp-tls-reporting@google.com?

Estes emails são relatórios TLS-RPT legítimos enviados pela Google. O seu domínio tem um registro _smtp._tls configurado, e a Google envia diariamente um relatório JSON comprimido que detalha os resultados de negociação TLS dos emails que lhe enviou.

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 em conjunto.

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

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

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

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

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

Um relatório TLS-RPT é um arquivo JSON comprimido com gzip. Contém a organização emissora, 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árias URIs de relatórios separadas por vírgulas. Por exemplo: rua=mailto:tlsrpt@captaindns.com,https://report.captaindns.com/tlsrpt. O endpoint HTTPS é recomendado para domínios com elevado volume de emails.

É preciso um registro TLS-RPT por subdomínio?

Sim. O registro TLS-RPT não é herdado do domínio principal. O servidor emissor faz a consulta DNS em _smtp._tls.<domínio do destinatário> (RFC 8460, seção 3). Se você recebe correio em @captaindns.com e em @externo.captaindns.com, precisa publicar dois registros distintos: _smtp._tls.captaindns.com e _smtp._tls.externo.captaindns.com. É o mesmo comportamento do MTA-STS e do DMARC.

📖 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 os certificados TLS.
STARTTLS: Extensão SMTP que permite criptografar uma conexão inicialmente em texto claro. 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 claro, 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 a sua configuração agora: Use o nosso verificador TLS-RPT para analisar o registro _smtp._tls do seu domínio em poucos segundos.