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

Q: Como configurar um registo TLS-RPT?

Publique um registo 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 registo 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

Atualizado em 30 de junho de 2026

TLS-RPT: monitorizar falhas de encriptação TLS na entrega de emails

TL;DR

O TLS-RPT (RFC 8460) envia-lhe um relatório diário sobre cada falha de encriptação TLS detetada 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 registo DNS TXT: _smtp._tls.captaindns.com com a diretiva v=TLSRPTv1; rua=mailto:...
O TLS-RPT é o complemento indispensável do MTA-STS: dá-lhe a visibilidade necessária antes de passar ao modo enforce

O seu domínio usa MTA-STS ou está a pensar ativá-lo? Configurou STARTTLS nos seus servidores de email? Em ambos os casos, uma pergunta fica sem resposta: como saber se a encriptação 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-lhe 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 vai receber. Seja administrador de sistemas, DevOps ou responsável pela infraestrutura de email, aqui encontra tudo o que é preciso 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 ligação TLS que falham quando servidores tentam entregar-lhe emails.

Na prática, quando o Gmail tenta enviar um email para contact@captaindns.com, verifica se o servidor de receçã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 regista essa falha. Uma vez por dia, agrega todas as falhas e envia um relatório JSON para o endereço especificado no seu registo TLS-RPT.

Porque é que o TLS-RPT é indispensável?

Sem TLS-RPT, fica às cegas sobre a qualidade da encriptação 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 não sabe disso
Um MX secundário não suporta STARTTLS → os emails para esse MX trafegam sem encriptação
Um ataque man-in-the-middle força um downgrade → impossível de detetar sem relatórios

O TLS-RPT preenche essa lacuna. Recebe diariamente um balanço preciso: quantas ligaçõ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 monitoriza	A autenticação dos emails (SPF, DKIM, alinhamento)	A encriptação do transporte (TLS)
RFC	RFC 7489	RFC 8460
Registo 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 registo DNS

Publica um registo TXT em _smtp._tls.captaindns.com que contém o endereço onde receber os relatórios.

2. Deteção pelo servidor emissor

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

3. Recolha dos resultados TLS

A cada tentativa de entrega, o servidor emissor regista 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 registo 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 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 ficheiro JSON comprimido (gzip) que detalha os resultados TLS das últimas 24 horas.

A sintaxe do registo TLS-RPT

O registo TLS-RPT é um registo 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

Pode perfeitamente enviar os seus relatórios TLS-RPT para um domínio diferente do seu, por exemplo um serviço terceiro de monitorização. Ao contrário do DMARC, o TLS-RPT não exige qualquer registo 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 secçã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 registo de consentimento da forma dominio-origem._report._dmarc.terceiro. Esse mecanismo não existe no TLS-RPT: não há qualquer registo _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 registo
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 ligações TLS bem-sucedidas
`total-failure-session-count`	Número de ligaçõ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 ficheiro `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`	Registo TLSA inválido (DANE)	Média	Corrigir os registos 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. Eis porquê:

O fluxo recomendado

Configurar o TLS-RPT: publique o seu registo _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á ligações TLS a falhar
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 registos DANE TLSA (RFC 7672). Se o seu domínio usa DNSSEC e publica registos 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 tiver um sistema de processamento automatizado

Etapa 2: Gerar o registo DNS

Use o nosso gerador TLS-RPT para criar o registo adequado ao seu domínio. Vai obter um registo pronto a copiar.

Etapa 3: Publicar o registo DNS

Adicione o registo 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 registo 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 registo. 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 registo 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 receçã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á a funcionar corretamente. Os relatórios confirmam que todas as ligações TLS estão a ser 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 registo _smtp._tls. O ficheiro anexo (.json.gz) contém o relatório. Não marque estes emails como spam.

🎯 Plano de ação recomendado

Publique o seu registo 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 ligações TLS com falha
Monitorize 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á-lhe visibilidade completa sobre a qualidade da encriptação dos seus emails recebidos.

Como configurar um registo TLS-RPT?

Publique um registo 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 registo e depois adicione-o na sua zona DNS. Os primeiros relatórios chegam em 24 a 48 horas.

Porque é 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 registo _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 monitoriza a autenticação dos emails (SPF, DKIM, alinhamento), enquanto o TLS-RPT monitoriza a encriptação 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, não saberá se há ligações TLS a falhar. Isto é 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 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, 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 ficheiro 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, 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 registo TLS-RPT por subdomínio?

Sim. O registo 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, secção 3). Se recebe correio em @captaindns.com e em @externo.captaindns.com, deve publicar dois registos 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 encriptação TLS para a receção de emails.
DANE: DNS-Based Authentication of Named Entities (RFC 7672), mecanismo alternativo ao MTA-STS que usa DNSSEC e registos TLSA para validar os certificados TLS.
STARTTLS: Extensão SMTP que permite encriptar uma ligação inicialmente em texto claro. Oportunista por predefinição (sem rejeição se a encriptação falhar).
Ataque de downgrade: Ataque em que um intermediário força a ligaçã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 registo _smtp._tls do seu domínio em poucos segundos.