Analisador de relatórios TLS-RPT

Por que analisar seus relatórios TLS-RPT?

O protocolo TLS-RPT (RFC 8460) obriga os provedores compatíveis a enviar relatórios diários. Google, Microsoft, Yahoo e Apple reportam cada tentativa de conexão TLS com seu domínio.

Esses relatórios contêm dados cruciais: número de conexões bem-sucedidas, falhas TLS e suas causas técnicas. O problema: são arquivos JSON de centenas de linhas, frequentemente compactados em gzip. Sem ferramenta, a análise manual é inviável.

Três motivos para analisar seus relatórios TLS-RPT:

• Detectar certificados expirados - um certificado vencido no servidor MX bloqueia a criptografia TLS e expõe emails em texto puro
• Validar sua política MTA-STS - política inacessível ou inválida gera alertas sts-policy-fetch-error nos relatórios
• Antecipar problemas de entrega - uma taxa de falha crescente sinaliza erros de configuração antes que os emails sejam rejeitados

Faça upload do seu relatório acima para identificar cada falha em segundos.

Como analisar um relatório TLS-RPT em 3 passos

Passo 1: Obtenha o relatório

Localize o email enviado por noreply-smtp-tls-reporting@google.com, Microsoft ou outro provedor. Baixe o anexo .json.gz ou .json para o seu computador.

Passo 2: Faça upload do arquivo

Arraste e solte o arquivo na área de upload acima ou clique em "Procurar". Formatos aceitos: .json e .json.gz, até 10 MB.

Passo 3: Leia o diagnóstico

O CaptainDNS descompacta o arquivo, interpreta o JSON e exibe os resultados em segundos:

• Pontuação de saúde de 0 a 100 - 4 níveis: excelente (90+), bom (70-89), atenção (50-69) ou crítico (abaixo de 50)
• Detalhamento por política - resultados MTA-STS e DANE separados, com taxa de sucesso por política
• Falhas explicadas - cada falha inclui gravidade, causa técnica e recomendação prática
• Link direto para correção - cada problema aponta para a ferramenta CaptainDNS adequada

Teste agora: faça upload do seu primeiro relatório e obtenha seu diagnóstico.

Estrutura de um relatório TLS-RPT (RFC 8460)

A RFC 8460 define o esquema JSON dos relatórios TLS-RPT. Cada relatório contém três blocos principais:

• organization-name - identifica o remetente (ex.: "Google Inc.")
• date-range - período coberto, normalmente 24 horas
• policies - uma ou mais políticas avaliadas (MTA-STS e/ou DANE)

Para cada política, o relatório indica:

Compreender esta estrutura permite identificar rapidamente onde estão os problemas. Faça upload de um relatório para visualizar esses dados de forma legível.

Os 12 tipos de falhas TLS analisados

O analisador CaptainDNS cobre todos os códigos de falha definidos pela RFC 8460. Cada falha é classificada por gravidade e acompanhada de uma ação corretiva.

Falhas STARTTLS

Falhas de certificado

Falhas MTA-STS

Falhas DANE

Se o seu relatório contém algum desses códigos, faça upload acima para obter as recomendações detalhadas.

Casos de uso concretos

Incidente 1: Certificado expirado em um MX secundário

Sintoma: O relatório do Google mostra 200 falhas certificate-expired em mail2.exemplo.com. Diagnóstico: O certificado Let's Encrypt do MX secundário não foi renovado. O cron do certbot estava quebrado. Ação: Renovar o certificado imediatamente e verificar a automação de renovação.

Incidente 2: Política MTA-STS inacessível

Sintoma: O relatório da Microsoft indica sts-policy-fetch-error com código HTTP 503. Diagnóstico: O servidor que hospeda https://mta-sts.exemplo.com/.well-known/mta-sts.txt está fora do ar. Ação: Restabelecer o servidor ou migrar para a hospedagem MTA-STS do CaptainDNS para garantir alta disponibilidade.

Incidente 3: Nenhuma política TLS configurada

Sintoma: O relatório mostra no-policy-found para um subdomínio. Diagnóstico: O subdomínio não possui política MTA-STS nem registros DANE. Os emails transitam sem verificação de criptografia. Ação: Configurar MTA-STS com o Gerador MTA-STS ou implantar DANE com o Gerador DANE/TLSA.

Reconhece algum desses cenários? Analise seu relatório para descobrir qual falha afeta seu domínio.

FAQ

P: O que é um relatório TLS-RPT e como interpretá-lo?

R: Um relatório TLS-RPT é um arquivo JSON definido pela RFC 8460. Provedores como Google e Microsoft o enviam diariamente ao seu domínio. Ele contém o número de conexões TLS bem-sucedidas, o número de falhas e o código técnico de cada falha. Os arquivos vêm em .json.gz. Use o analisador acima para decodificá-los automaticamente.

P: Por que recebo emails de noreply-smtp-tls-reporting@google.com?

R: Seu domínio possui um registro DNS TLS-RPT com um endereço mailto:. O Google envia um relatório diário sobre as conexões TLS dos seus servidores. Isso é normal e desejável - indica que o monitoramento está ativo. Faça upload desses relatórios aqui para interpretar os resultados.

P: Qual é a diferença entre um TLS-RPT checker e um TLS-RPT report analyzer?

R: São duas ferramentas complementares. O TLS-RPT checker verifica seu registro DNS _smtp._tls.dominio - valida a configuração. O report analyzer interpreta os relatórios JSON recebidos - analisa os resultados. Use o Inspetor TLS-RPT para verificar a configuração e este analisador para interpretar os relatórios.

Ferramentas complementares

Cada etapa da segurança TLS do seu domínio tem uma ferramenta dedicada:

Execute a auditoria completa do seu domínio para uma visão global da sua segurança de email.

Recursos úteis

• RFC 8460 - SMTP TLS Reporting - especificação oficial do protocolo TLS-RPT (IETF, 2018)
• RFC 8461 - MTA Strict Transport Security - protocolo que impõe TLS obrigatório na entrega de emails (IETF, 2018)
• RFC 7672 - SMTP Security via DANE - autenticação DANE para conexões SMTP (IETF, 2015)
• Google Workspace - Configurar TLS Reporting - guia oficial do Google para ativar TLS-RPT