TLS-RPT Checker

Porque verificar o seu TLS-RPT

O transporte SMTP usa TLS de forma oportunista: se a negociação falha, a ligação volta a texto claro sem qualquer alerta. Os seus emails saem em 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 encriptação (isso é tarefa do MTA-STS), mas dá-lhe finalmente visibilidade. Cada MTA emissor que falha ao estabelecer TLS envia um relatório JSON para o endereço rua que publica. Sem este mecanismo, está cego.

Verificar a configuração antes de a esquecer num canto do DNS é essencial:

• Registo em falta → não sabe nada sobre as falhas TLS, sem rasto de auditoria
• URI rua inválida → os MTAs não conseguem entregar os relatórios, são descartados
• Registos 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 registo 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 recolhe relatórios durante a fase testing

Como usar este checker em 3 passos

Passo 1: introduza o domínio a analisar

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

• captaindns.com (domínio principal)
• marketing.captaindns.com (subdomínio se 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 registo é 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 desconhecida, MTA-STS em falta)

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

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 recetor
2. Pede aos MTAs emissores que enviem um relatório JSON quando TLS falha
3. Fornece um rasto das falhas de encriptação (certificado expirado, downgrade, mismatch)

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

Exemplo de registo TLS-RPT:

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

Este registo 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 encriptação 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:

Registo DNS publicado

Sintaxe do registo

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)
• Nenhuma tag desconhecida a poluir o registo
• Política coerente com o deployment mail do domínio

Diagnósticos comuns e soluções

Registo em falta (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 em falta (rua_missing)

Causa: o registo 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: em falta, espaço no endereço, esquema desconhecido).

Exemplos de correção:

- rua=tls-reports@captaindns.com         # mailto: em falta
+ 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 registos (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 registo. Identifique os duplicados, conserve o que deseja aplicar, remova os restantes.

CNAME em _smtp._tls (cname_on_smtp_tls)

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

Solução: nenhum RFC proíbe o CNAME neste local. O checker assinala-o como aviso, não como erro: o Microsoft 365 ignora um _smtp._tls em alias. Um TXT direto continua a ser a configuração segura.

MTA-STS companheiro em falta (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

Pode dirigir 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 registo 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 registo em uriports.com. O relatório é enviado diretamente. A confiança assenta 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 recolha (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 registo [dominio]._report._dmarc.[terceiro] para autorizar uma rua para um domínio terceiro. O TLS-RPT não tem equivalente. Publicar um registo _report._tls é inútil e não é esperado por nenhum MTA.
• Verificar o destino: assegure-se simplesmente de que o endereço mailto ou a URL https de recolha 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 recolher 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. Vê os problemas sem os poder evitar.

Sem TLS-RPT: MTA-STS impõe TLS mas 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