TLS-RPT Checker

Por que verificar o seu TLS-RPT

O transporte SMTP usa TLS de forma oportunista: se a negociação falha, a conexão volta a texto claro sem qualquer alerta. Os seus emails saem em texto claro e ninguém o avisa. Pior, um MITM pode suprimir ativamente STARTTLS para forçar essa queda.

O TLS-RPT (RFC 8460) não corrige a falha de criptografia (isso é tarefa do MTA-STS), mas dá a você finalmente visibilidade. Cada MTA emissor que falha ao estabelecer TLS envia um relatório JSON para o endereço rua que você publica. Sem esse mecanismo, você está cego.

Verificar a configuração antes de esquecê-la num canto do DNS é essencial:

• Registro ausente → você não sabe nada sobre as falhas TLS, sem rastro de auditoria
• URI rua inválida → os MTAs não conseguem entregar os relatórios, são descartados
• Registros múltiplos → os MTAs emissores ignoram um TLS-RPT duplicado, nenhum relatório é enviado

Casos de uso comuns:

• Após publicação → confirmar que o registro está corretamente propagado
• Auditoria de segurança email → validar a cobertura TLS e a visibilidade de falhas
• Antes de MTA-STS enforce → assegurar que TLS-RPT coleta relatórios durante a fase testing

Como usar este checker em 3 passos

Passo 1: insira o domínio a analisar

Digite o domínio exatamente como aparece nos seus endereços de email:

• captaindns.com (domínio principal)
• marketing.captaindns.com (subdomínio, se você envia a partir de um subdomínio)

A ferramenta consulta automaticamente _smtp._tls.dominio e recupera o TXT publicado.

Passo 2: analise os resultados

O checker mostra:

Passo 3: corrija os problemas sinalizados

Os resultados são classificados por gravidade:

• Crítico → o registro é inválido, nenhum relatório será enviado
• Aviso → funciona, mas expõe a um risco ou cobertura parcial
• Info → boa prática não bloqueante (tag desconhecido, MTA-STS ausente)

Corrija o DNS, aguarde a propagação e execute o checker novamente.

O que é TLS-RPT

TLS-RPT (SMTP TLS Reporting, RFC 8460) é um mecanismo que:

1. Publica um endereço de relatório no DNS para o domínio receptor
2. Pede aos MTAs emissores que enviem um relatório JSON quando TLS falha
3. Fornece um rastro das falhas de criptografia (certificado expirado, downgrade, mismatch)

A arquitetura é deliberadamente minimalista: um único registro TXT publicado em _smtp._tls.dominio, contendo a versão e uma ou mais URIs rua=.

Exemplo de registro TLS-RPT:

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

Este registro indica aos MTAs emissores (Gmail, Outlook, etc.) que enviem os seus relatórios de falha TLS para tls-reports@captaindns.com.

Diferença para MTA-STS: TLS-RPT é o companheiro do MTA-STS, não uma alternativa. MTA-STS impõe a criptografia TLS, TLS-RPT sinaliza as falhas. Os dois protocolos vivem em locais distintos (_mta-sts.dominio para STS, _smtp._tls.dominio para RPT) e funcionam em conjunto.

O que o checker verifica

Cinco dimensões são analisadas em paralelo para produzir uma pontuação 0-100:

Registro DNS publicado

Sintaxe do registro

URIs de relatório

Qualidade da rua

• O domínio da URI rua coincide com o domínio verificado (destino interno)
• O domínio é diferente (destino externo): válido sem qualquer autorização do lado do destinatário
• A URI https responde com HTTPS válido (sondagem leve do lado do servidor)

Higiene global

• Presença simultânea de MTA-STS (bônus +2 na pontuação)
• Nenhum tag desconhecido a poluir o registro
• Política coerente com o deployment mail do domínio

Diagnósticos comuns e soluções

Registro ausente (missing_record)

Causa: nenhum TXT existe em _smtp._tls.captaindns.com.

Solução: publicar

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

Tag rua ausente (rua_missing)

Causa: o registro contém v=TLSRPTv1, mas nenhum destino.

Solução: adicionar pelo menos uma URI: v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com. Sem rua, nenhum MTA enviará relatório.

URI rua inválida (rua_invalid_uri)

Causa: a URI está mal formada (mailto: ausente, espaço no endereço, esquema desconhecido).

Exemplos de correção:

- rua=tls-reports@captaindns.com         # mailto: ausente
+ rua=mailto:tls-reports@captaindns.com

- rua=mailto: tls-reports@captaindns.com # Espaço depois de mailto: proibido
+ rua=mailto:tls-reports@captaindns.com

Vários registros (multiple_records)

Causa: mais de um TXT TLS-RPT existe em _smtp._tls.captaindns.com.

Solução: o RFC 8460 §3 impõe um único registro. Identifique os duplicados, conserve o que deseja aplicar, remova os demais.

CNAME em _smtp._tls (cname_on_smtp_tls)

Causa: _smtp._tls.dominio é um CNAME que aponta para outro lado.

Solução: o RFC proíbe CNAME neste local. Publique um TXT direto.

MTA-STS companheiro ausente (mta_sts_companion_missing)

Causa: TLS-RPT está publicado, mas MTA-STS não.

Solução: implementar MTA-STS para dar sentido aos relatórios TLS-RPT. Veja o MTA-STS Checker e o guia completo.

Enviar os relatórios para um domínio terceiro

Você pode direcionar os seus relatórios TLS-RPT para um domínio que não controla, por exemplo um analisador terceiro. Ao contrário do DMARC, o RFC 8460 não define nenhum registro de autorização do lado do destinatário: uma rua para um domínio terceiro funciona sem qualquer publicação adicional.

O mecanismo

O seu domínio: captaindns.com URI rua: mailto:tls-reports@uriports.com

Não é necessário qualquer registro em uriports.com. O relatório é enviado diretamente. A confiança se apoia em duas salvaguardas previstas pelo RFC 8460 §7:

• mailto: o relatório é assinado com DKIM pelo MTA emissor, o que autentica a sua origem.
• https: o domínio de destino controla o seu próprio ponto de coleta (posse do DNS).

O RFC 8460 §7 afastou deliberadamente qualquer mecanismo de verificação adicional, sendo o risco de amplificação menor do que com o DMARC.

Armadilhas comuns

• Não transponha o mecanismo DMARC: o DMARC exige um registro [dominio]._report._dmarc.[terceiro] para autorizar uma rua para um domínio terceiro. O TLS-RPT não tem equivalente. Publicar um registro _report._tls é inútil e não é esperado por nenhum MTA.
• Verificar o destino: assegure-se simplesmente de que o endereço mailto ou o URL https de coleta está correto e operacional.

TLS-RPT e MTA-STS: deployment combinado

Os dois protocolos formam uma defesa em profundidade:

Ordem de deployment recomendada

1. Publicar TLS-RPT primeiro para coletar os relatórios
2. Implementar MTA-STS em modo testing sem bloquear a entrega
3. Observar 2 a 4 semanas os relatórios TLS-RPT para identificar os MX problemáticos
4. Passar MTA-STS para modo enforce quando os relatórios estiverem limpos
5. Manter TLS-RPT indefinidamente para a vigilância contínua

Sem MTA-STS: TLS-RPT sinaliza as falhas, mas nenhuma política obriga os MTAs emissores a usar TLS. Você vê os problemas sem poder evitá-los.

Sem TLS-RPT: MTA-STS impõe TLS, mas você nunca saberá que um MTA legítimo está bloqueado pela sua política. Risco de não-entrega silenciosa.

Ferramentas complementares e recursos

Recursos:

• TLS-RPT: o guia completo
• Configurar TLS-RPT em Microsoft 365, Google Workspace e OVHcloud
• Analisar os relatórios TLS-RPT no dia a dia
• RFC 8460 - SMTP TLS Reporting
• RFC 8461 - MTA-STS