Analisar e explorar os seus relatórios TLS-RPT: detetar problemas antes que eles afetem os seus emails

Por CaptainDNS
Publicado em 14 de fevereiro de 2026

Atualizado em 4 de março de 2026

Analisar um relatório TLS-RPT: estrutura JSON e tipos de erros TLS de email

TL;DR

Um relatório TLS-RPT é um ficheiro JSON compactado (gzip) enviado diariamente pelos servidores remetentes: ele detalha cada falha de negociação TLS no seu domínio
Os 3 erros mais frequentes são certificate-host-mismatch, starttls-not-supported e sts-policy-fetch-error, cada um com uma causa e uma correção específica
Analise o campo failure-details para identificar o servidor MX envolvido, o IP do remetente e o tipo exato da falha
Use o validador de sintaxe TLS-RPT para verificar a sua configuração antes e depois da correção

Configurou o TLS-RPT no seu domínio e os relatórios começaram a chegar. Ficheiros JSON compactados, enviados por Google, Microsoft, Yahoo e outros fornecedores. Os abre e encontra blocos de dados estruturados com campos como policy-type, result-type, failed-session-count. O que esses dados significam? Como transformá-los em ações concretas?

Essa é a parte menos documentada do TLS-RPT. A RFC 8460 define o formato, mas não explica como interpretar os resultados em um contexto operacional. Este guia preenche essa lacuna: aprenderá a ler a estrutura JSON de um relatório, a identificar cada tipo de erro e a seguir um workflow de diagnóstico para corrigir os problemas antes que eles afetem a entrega dos seus emails.

Se ainda não configurou o TLS-RPT, comece pelo guia completo TLS-RPT que cobre a implementação de A a Z (veja a secção Guias relacionados no final do artigo). Se procura a configuração específica para o seu fornecedor (Microsoft 365, Google Workspace, OVHcloud), o guia de configuração por fornecedor também está disponível no final do artigo.

Anatomia de um relatório TLS-RPT

Um relatório TLS-RPT é um ficheiro JSON enviado como anexo compactado (.json.gz). Cada fornecedor que envia emails para si gera o seu próprio relatório, uma vez por dia. Veja a estrutura completa de um relatório típico:

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-02-12T00:00:00Z",
    "end-datetime": "2026-02-13T00:00:00Z"
  },
  "contact-info": "smtp-tls-reporting@google.com",
  "report-id": "2026-02-12T00: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",
        "mx-host": ["mail.captaindns.com"]
      },
      "summary": {
        "total-successful-session-count": 1842,
        "total-failure-session-count": 3
      },
      "failure-details": [
        {
          "result-type": "certificate-host-mismatch",
          "sending-mta-ip": "209.85.220.41",
          "receiving-mx-hostname": "mail.captaindns.com",
          "receiving-ip": "203.0.113.10",
          "failed-session-count": 3
        }
      ]
    }
  ]
}

Os 4 blocos do relatório

Cada relatório contém exatamente 4 níveis de informação:

1. Cabeçalho do relatório: quem envia e quando:

organization-name: o fornecedor remetente (Google, Microsoft, Yahoo)
date-range: o período coberto (sempre 24 horas)
report-id: identificador único do relatório

2. Bloco policy: qual política TLS foi avaliada:

policy-type: o tipo de política (sts para MTA-STS, tlsa para DANE, no-policy-found se nenhuma)
policy-string: o conteúdo da política MTA-STS ou DANE aplicada
policy-domain: o seu domínio
mx-host: os servidores MX envolvidos

3. Bloco summary: o resumo em números:

total-successful-session-count: ligações TLS bem-sucedidas
total-failure-session-count: ligações TLS com falha

4. Bloco failure-details: o detalhe de cada falha (o mais importante):

result-type: o tipo exato do erro
sending-mta-ip: o IP do servidor que tentou enviar o email para si
receiving-mx-hostname: o seu servidor MX envolvido
receiving-ip: o IP do seu servidor MX
failed-session-count: número de falhas desse tipo

Anatomia de um relatório TLS-RPT: os 4 blocos de dados JSON (cabeçalho, política, resumo, detalhes das falhas)

Como receber e descompactar os relatórios?

Os relatórios chegam por email a partir de endereços como noreply-smtp-tls-reporting@google.com. O ficheiro anexo tem um nome no formato:

google.com!captaindns.com!2026-02-12T00:00:00Z!2026-02-13T00:00:00Z.json.gz

Para descompactá-lo:

# Linux / macOS
gunzip google.com\!captaindns.com\!2026-02-12T00:00:00Z\!2026-02-13T00:00:00Z.json.gz

# Ou exibir diretamente sem extrair
zcat rapport.json.gz | python3 -m json.tool

Se recebe os relatórios via HTTPS (endpoint https://), o servidor recebe diretamente o JSON compactado em POST com o Content-Type application/tlsrpt+gzip.

Tipos de falha TLS-RPT (result-type)

O campo result-type em failure-details identifica precisamente o que falhou. A RFC 8460 define 11 tipos de falha, distribuídos em 3 categorias:

Falhas relacionadas ao certificado TLS

result-type	Causa	Ação corretiva
`certificate-host-mismatch`	O certificado TLS do servidor MX não corresponde ao hostname	Renove o certificado com o CN/SAN correto para o seu MX
`certificate-expired`	O certificado TLS expirou	Renove o certificado imediatamente
`certificate-not-trusted`	O certificado não é assinado por uma CA reconhecida	Use um certificado assinado por uma CA pública (Let's Encrypt, DigiCert)

Falhas relacionadas ao STARTTLS

result-type	Causa	Ação corretiva
`starttls-not-supported`	O servidor MX não oferece STARTTLS	Ative o STARTTLS na configuração do seu servidor de email
`validation-failure`	Falha genérica de validação TLS	Verifique a cadeia de certificados completa e a configuração TLS

Falhas relacionadas às políticas MTA-STS e DANE

result-type	Causa	Ação corretiva
`sts-policy-fetch-error`	Impossível recuperar a política MTA-STS	Verifique se `https://mta-sts.captaindns.com/.well-known/mta-sts.txt` está acessível
`sts-policy-invalid`	A política MTA-STS está mal formatada	Corrija a sintaxe do ficheiro `mta-sts.txt`
`sts-webpki-invalid`	O certificado HTTPS do servidor MTA-STS é inválido	Renove o certificado do subdomínio `mta-sts.captaindns.com`
`tlsa-invalid`	O registo DANE TLSA é inválido	Corrija o registo TLSA na sua zona DNS
`dnssec-invalid`	A validação DNSSEC falhou	Corrija a sua cadeia DNSSEC
`dane-required`	DANE é obrigatório, mas o servidor não o suporta	Implante o DANE ou remova os registos TLSA

Os 3 erros mais frequentes em detalhe

certificate-host-mismatch

É o erro mais comum. Ele aparece quando o certificado TLS apresentado pelo seu servidor MX não contém o hostname esperado no campo CN (Common Name) ou SAN (Subject Alternative Name).

Cenário típico: o seu MX é mail.captaindns.com, mas o certificado foi emitido para *.outrodominio.com (alojamento partilhado) ou para captaindns.com sem o subdomínio mail.

Diagnóstico:

# Verificar o certificado do seu MX
openssl s_client -connect mail.captaindns.com:25 -starttls smtp \
  -servername mail.captaindns.com 2>/dev/null | \
  openssl x509 -noout -subject -ext subjectAltName

Correção: obtenha um certificado que inclua o FQDN exato do seu MX no SAN. Com Let's Encrypt:

certbot certonly --standalone -d mail.captaindns.com

starttls-not-supported

O servidor MX não oferece o comando STARTTLS no seu banner SMTP. Os emails chegam em texto puro.

Diagnóstico:

# Testar se STARTTLS é anunciado
openssl s_client -connect mail.captaindns.com:25 -starttls smtp 2>&1 | head -5
# Se "CONNECTED" aparecer, STARTTLS funciona
# Se houver erro, STARTTLS não é suportado

Correção: ative o STARTTLS no seu servidor de email. Para Postfix:

# /etc/postfix/main.cf
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.captaindns.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.captaindns.com/privkey.pem
smtpd_tls_security_level = may

sts-policy-fetch-error

O servidor remetente não conseguiu recuperar a sua política MTA-STS na URL https://mta-sts.captaindns.com/.well-known/mta-sts.txt.

Causas frequentes:

O subdomínio mta-sts.captaindns.com não tem registo DNS A/AAAA
O servidor HTTPS não responde ou retorna erro 404/500
O certificado HTTPS do subdomínio mta-sts expirou

Diagnóstico:

# Testar o acesso à política
curl -v https://mta-sts.captaindns.com/.well-known/mta-sts.txt

Para um diagnóstico completo dos seus problemas MTA-STS, consulte nosso guia de troubleshooting MTA-STS.

Diagnóstico passo a passo: do erro à correção

Quando recebe um relatório com falhas, siga este workflow em 5 etapas:

Etapa 1: Identifique a gravidade

Observe a proporção falhas/sucessos no bloco summary:

total-successful-session-count: 1842
total-failure-session-count: 3

Uma proporção inferior a 1% de falhas é normal: pode se tratar de tentativas vindas de servidores mal configurados do lado do remetente. Acima de 5%, há um problema a ser investigado.

Etapa 2: Identifique o result-type

O campo result-type em failure-details indica exatamente o que falhou. Consulte a tabela dos 11 tipos acima.

Etapa 3: Identifique o servidor MX envolvido

O campo receiving-mx-hostname indica qual servidor está afetado. Se tem vários MX (primário + backup), apenas um pode estar mal configurado.

Etapa 4: Verifique com as ferramentas CaptainDNS

Use o verificador TLS-RPT do CaptainDNS para confirmar que o seu registo DNS está correto e que as políticas associadas (MTA-STS, DANE) estão a ser detetadas.

Etapa 5: Corrija e monitorize

Aplique a correção correspondente ao result-type e monitorize os relatórios das 48 a 72 horas seguintes para confirmar que o erro desapareceu.

Workflow de diagnóstico TLS-RPT: da receção do relatório à correção do erro

Casos práticos: analisar um relatório real

Caso 1: relatório limpo (nenhuma falha)

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-02-12T00:00:00Z",
    "end-datetime": "2026-02-13T00:00:00Z"
  },
  "report-id": "2026-02-12_captaindns.com",
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-domain": "captaindns.com"
      },
      "summary": {
        "total-successful-session-count": 2156,
        "total-failure-session-count": 0
      },
      "failure-details": []
    }
  ]
}

Interpretação: 2.156 ligações TLS bem-sucedidas, zero falhas. A sua configuração funciona perfeitamente. Este relatório confirma que:

O seu certificado TLS é válido e corresponde ao hostname MX
O STARTTLS está ativo no seu servidor
A sua política MTA-STS está acessível e é respeitada

Caso 2: falha de certificado em um MX secundário

{
  "organization-name": "Microsoft Corporation",
  "date-range": {
    "start-datetime": "2026-02-12T00:00:00Z",
    "end-datetime": "2026-02-13T00:00:00Z"
  },
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-domain": "captaindns.com",
        "mx-host": ["mail.captaindns.com", "mail2.captaindns.com"]
      },
      "summary": {
        "total-successful-session-count": 890,
        "total-failure-session-count": 47
      },
      "failure-details": [
        {
          "result-type": "certificate-host-mismatch",
          "sending-mta-ip": "40.107.22.89",
          "receiving-mx-hostname": "mail2.captaindns.com",
          "receiving-ip": "198.51.100.20",
          "failed-session-count": 47
        }
      ]
    }
  ]
}

Interpretação: 47 falhas em mail2.captaindns.com (MX secundário) com erro certificate-host-mismatch. O MX primário (mail.captaindns.com) funciona corretamente. O certificado do MX secundário não contém mail2.captaindns.com no SAN.

Ação: renove o certificado de mail2.captaindns.com incluindo esse hostname no SAN.

Caso 3: política MTA-STS inacessível

{
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-domain": "captaindns.com"
      },
      "summary": {
        "total-successful-session-count": 0,
        "total-failure-session-count": 156
      },
      "failure-details": [
        {
          "result-type": "sts-policy-fetch-error",
          "failed-session-count": 156
        }
      ]
    }
  ]
}

Interpretação: 156 falhas, todas do tipo sts-policy-fetch-error. O servidor remetente detetou o seu registo MTA-STS (_mta-sts.captaindns.com), mas não conseguiu descarregar a política em https://mta-sts.captaindns.com/.well-known/mta-sts.txt.

Ação: verifique se o subdomínio mta-sts.captaindns.com aponta para um servidor HTTPS funcional com certificado válido.

Automatizar a análise dos seus relatórios

Volume baixo: caixa de email dedicada

Para um domínio que recebe menos de 1.000 emails por dia, um endereço dedicado é suficiente:

_smtp._tls.captaindns.com. TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"

Crie um filtro no seu cliente de email para classificar os relatórios automaticamente. Consulte-os uma vez por semana procurando por total-failure-session-count superiores a zero.

Volume alto: endpoint HTTPS

Para domínios com alto tráfego, configure um endpoint HTTPS que receba os relatórios via POST:

_smtp._tls.captaindns.com. TXT "v=TLSRPTv1; rua=https://reports.captaindns.com/tls-rpt"

O endpoint recebe o JSON compactado em gzip com o Content-Type application/tlsrpt+gzip. Pode parsear os relatórios automaticamente e acionar alertas quando total-failure-session-count ultrapassar um limite.

Verificar a sua configuração com o CaptainDNS

Antes de modificar a sua configuração TLS ou MTA-STS, use o gerador TLS-RPT para criar um registo correto. Após a correção, verifique com o verificador TLS-RPT que tudo está em ordem.

Plano de ação recomendado

Descompacte e leia o seu primeiro relatório: abra um ficheiro .json.gz recebido do Google ou Microsoft e identifique os 4 blocos (cabeçalho, policy, summary, failure-details)
Verifique a proporção falhas/sucessos: uma taxa de falha acima de 5% requer investigação
Identifique o result-type: use a tabela dos 11 tipos de falha para entender a causa exata
Corrija o problema no servidor envolvido: certificado, STARTTLS ou política MTA-STS conforme o tipo de erro
Monitorize os relatórios seguintes: confirme o desaparecimento do erro nas 48 a 72 horas após a correção

FAQ

O que é um relatório TLS-RPT e o que ele contém?

Um relatório TLS-RPT é um ficheiro JSON compactado (gzip) enviado diariamente pelos servidores de email que enviam mensagens para si. Ele contém o nome da organização remetente, o período coberto (24 horas), a política TLS avaliada (MTA-STS ou DANE), o número de ligações TLS bem-sucedidas e com falha, e o detalhe de cada tipo de falha com os IPs e hostnames envolvidos.

Como ler a estrutura JSON de um relatório TLS-RPT?

O relatório JSON possui 4 níveis: o cabeçalho (organization-name, date-range), o bloco policy (policy-type, policy-string), o bloco summary (contadores de sucesso/falha) e o bloco failure-details (result-type, sending-mta-ip, receiving-mx-hostname). Descompacte o ficheiro .json.gz com gunzip ou zcat e formate com python3 -m json.tool para uma leitura legível.

Quais são os tipos de erro (result-type) em um relatório TLS-RPT?

A RFC 8460 define 11 tipos de falha distribuídos em 3 categorias: erros de certificado (certificate-host-mismatch, certificate-expired, certificate-not-trusted), erros STARTTLS (starttls-not-supported, validation-failure) e erros de política (sts-policy-fetch-error, sts-policy-invalid, sts-webpki-invalid, tlsa-invalid, dnssec-invalid, dane-required). Cada tipo indica precisamente o que falhou durante a negociação TLS.

O que significa certificate-host-mismatch em um relatório TLS-RPT?

O erro certificate-host-mismatch significa que o certificado TLS apresentado pelo seu servidor MX não corresponde ao hostname esperado. Por exemplo, se o seu MX é mail.captaindns.com, mas o certificado foi emitido para outro domínio. Corrija obtendo um certificado cujo SAN (Subject Alternative Name) inclua o FQDN exato do seu MX.

Como corrigir um erro starttls-not-supported?

O erro starttls-not-supported significa que o seu servidor MX não anuncia o comando STARTTLS, então os emails trafegam em texto puro. Ative o STARTTLS na configuração do seu servidor: para Postfix, adicione smtpd_tls_security_level = may com os caminhos para o seu certificado e chave privada em main.cf. Verifique depois com openssl s_client -connect mail.captaindns.com:25 -starttls smtp.

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 fornecedor que envia emails para si (Google, Microsoft, Yahoo, etc.) gera o seu próprio relatório de forma independente. Pode receber vários relatórios por dia, um por fornecedor remetente. Os primeiros relatórios chegam de 24 a 48 horas após a publicação do seu registo TLS-RPT.

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

Os relatórios DMARC monitorizam a autenticação dos emails (SPF, DKIM, alinhamento do domínio), enquanto os relatórios TLS-RPT monitorizam a encriptação do transporte (negociação TLS entre servidores). O DMARC verifica quem envia o email, o TLS-RPT verifica como ele é transportado. Os relatórios DMARC são em formato XML, os relatórios TLS-RPT em formato JSON. Ambos são complementares para proteger o seu domínio.

Glossário

TLS-RPT: SMTP TLS Reporting (RFC 8460), mecanismo de relatórios diários sobre falhas de negociação TLS na entrega de emails.
result-type: campo JSON em failure-details que identifica o tipo exato de falha TLS (certificate-host-mismatch, starttls-not-supported, etc.).
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 utiliza DNSSEC e os registos TLSA.
STARTTLS: extensão SMTP que permite encriptar uma ligação inicialmente em texto puro. Oportunista por predefinição.
SAN: Subject Alternative Name, campo do certificado TLS que lista os hostnames válidos.
policy-type: campo JSON que indica o tipo de política avaliada (sts, tlsa ou no-policy-found).

Verifique a sua configuração agora: Use nosso verificador TLS-RPT para verificar se o seu registo _smtp._tls está correto e se as políticas associadas estão a ser detetadas.

Analisar e explorar os seus relatórios TLS-RPT: detetar problemas antes que eles afetem os seus emails

Anatomia de um relatório TLS-RPT

Os 4 blocos do relatório

Como receber e descompactar os relatórios?

Tipos de falha TLS-RPT (result-type)

Falhas relacionadas ao certificado TLS

Falhas relacionadas ao STARTTLS

Falhas relacionadas às políticas MTA-STS e DANE

Os 3 erros mais frequentes em detalhe

certificate-host-mismatch

starttls-not-supported

sts-policy-fetch-error

Diagnóstico passo a passo: do erro à correção

Casos práticos: analisar um relatório real

Caso 1: relatório limpo (nenhuma falha)

Caso 2: falha de certificado em um MX secundário

Caso 3: política MTA-STS inacessível

Automatizar a análise dos seus relatórios

Volume baixo: caixa de email dedicada

Volume alto: endpoint HTTPS

Verificar a sua configuração com o CaptainDNS

Plano de ação recomendado

FAQ

O que é um relatório TLS-RPT e o que ele contém?

Como ler a estrutura JSON de um relatório TLS-RPT?

Quais são os tipos de erro (result-type) em um relatório TLS-RPT?

O que significa certificate-host-mismatch em um relatório TLS-RPT?

Como corrigir um erro starttls-not-supported?

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

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

Glossário

Guias de TLS-RPT relacionados

Fontes

Artigos relacionados

De testing a enforce: estratégia de implantação progressiva do MTA-STS

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

MTA-STS vs DANE: qual protocolo escolher para proteger o transporte de e-mail?