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

Por CaptainDNS
Publicado em 14 de fevereiro 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 arquivo 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 sua configuração antes e depois da correção

Você configurou o TLS-RPT no seu domínio e os relatórios começaram a chegar. Arquivos JSON compactados, enviados por Google, Microsoft, Yahoo e outros provedores. Você 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: você 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 você ainda não configurou o TLS-RPT, comece pelo guia completo TLS-RPT que cobre a implementação de A a Z (veja a seção Guias relacionados no final do artigo). Se você procura a configuração específica para o seu provedor (Microsoft 365, Google Workspace, OVHcloud), o guia de configuração por provedor também está disponível no final do artigo.

Anatomia de um relatório TLS-RPT

Um relatório TLS-RPT é um arquivo JSON enviado como anexo compactado (.json.gz). Cada provedor que envia emails para você gera 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 provedor 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: seu domínio
mx-host: os servidores MX envolvidos

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

total-successful-session-count: conexões TLS bem-sucedidas
total-failure-session-count: conexõ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 você
receiving-mx-hostname: 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 arquivo 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 você 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 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 arquivo `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 registro DANE TLSA é inválido	Corrija o registro TLSA na sua zona DNS
`dnssec-invalid`	A validação DNSSEC falhou	Corrija sua cadeia DNSSEC
`dane-required`	DANE é obrigatório, mas o servidor não o suporta	Implante o DANE ou remova os registros 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: seu MX é mail.captaindns.com, mas o certificado foi emitido para *.outrodominio.com (hospedagem compartilhada) 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 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 registro 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 você 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 você 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 seu registro DNS está correto e que as políticas associadas (MTA-STS, DANE) estão sendo detectadas.

Etapa 5: Corrija e monitore

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

Workflow de diagnóstico TLS-RPT: da recepçã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 conexões TLS bem-sucedidas, zero falhas. Sua configuração funciona perfeitamente. Este relatório confirma que:

Seu certificado TLS é válido e corresponde ao hostname MX
O STARTTLS está ativo no seu servidor
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 detectou seu registro MTA-STS (_mta-sts.captaindns.com), mas não conseguiu baixar 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. Você pode parsear os relatórios automaticamente e acionar alertas quando total-failure-session-count ultrapassar um limite.

Verificar sua configuração com o CaptainDNS

Antes de modificar sua configuração TLS ou MTA-STS, use o gerador TLS-RPT para criar um registro 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 seu primeiro relatório: abra um arquivo .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
Monitore 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 arquivo JSON compactado (gzip) enviado diariamente pelos servidores de email que enviam mensagens para você. 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 conexõ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 arquivo .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 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 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 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 provedor que envia emails para você (Google, Microsoft, Yahoo, etc.) gera seu próprio relatório de forma independente. Você pode receber vários relatórios por dia, um por provedor remetente. Os primeiros relatórios chegam de 24 a 48 horas após a publicação do seu registro TLS-RPT.

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

Os relatórios DMARC monitoram a autenticação dos emails (SPF, DKIM, alinhamento do domínio), enquanto os relatórios TLS-RPT monitoram a criptografia 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 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 criptografia TLS para a recepção de emails.
DANE: DNS-Based Authentication of Named Entities (RFC 7672), mecanismo alternativo ao MTA-STS que utiliza DNSSEC e os registros TLSA.
STARTTLS: extensão SMTP que permite criptografar uma conexão inicialmente em texto puro. Oportunista por padrã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 sua configuração agora: Use nosso verificador TLS-RPT para verificar se seu registro _smtp._tls está correto e se as políticas associadas estão sendo detectadas.

Analisar e explorar seus relatórios TLS-RPT: detectar problemas antes que eles afetem 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 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

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

MTA-STS não funciona? Guia completo de solução de problemas

Configurar TLS-RPT: guia passo a passo para Microsoft 365, Google Workspace e OVHcloud