Analisador de relatórios TLS-RPT

Porque analisar os seus relatórios TLS-RPT?

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

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

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

• Detetar certificados expirados - um certificado vencido no servidor MX bloqueia a encriptação TLS e expõe emails em texto puro
• Validar a 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 fornecedor. Descarregue o anexo .json.gz ou .json para o seu computador.

Passo 2: Faça upload do ficheiro

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

Passo 3: Leia o diagnóstico

O CaptainDNS descompacta o ficheiro, 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 o 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 os 11 códigos de falha definidos pela RFC 8460, mais starttls-not-offered, uma variante alheia à RFC emitida por alguns remetentes. 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 num 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 aloja https://mta-sts.exemplo.com/.well-known/mta-sts.txt está fora do ar. Ação: Restabelecer o servidor ou migrar para o alojamento 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 registos DANE. Os emails transitam sem verificação de encriptação. Ação: Configurar MTA-STS com o Gerador MTA-STS ou implantar DANE com o Gerador DANE/TLSA.

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

FAQ

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

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

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

R: O seu domínio possui um registo DNS TLS-RPT com um endereço mailto:. O Google envia um relatório diário sobre as ligações TLS dos seus servidores. Isso é normal e desejável - indica que a monitorização está ativa. 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 o seu registo 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 ligações SMTP (IETF, 2015)
• Google Workspace - Configurar TLS Reporting - guia oficial do Google para ativar TLS-RPT