Porquê 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.
TLS-RPT (RFC 8460) não corrige a falha de cifragem (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 ausente → 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
- Sem autorização externa → se delega num analisador terceiro, os servidores dele rejeitam os relatórios
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: 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 envia a partir de um subdomínio)
A ferramenta consulta automaticamente _smtp._tls.dominio, recupera o TXT publicado e resolve a autorização externa se necessário.
Passo 2: analise os resultados
O checker mostra:
| Elemento | Descrição |
|---|---|
| Registo TXT | Conteúdo bruto publicado em _smtp._tls.dominio |
| Versão | Deve ser exatamente TLSRPTv1 |
| URIs rua | Destinos dos relatórios (mailto, https) |
| Autorização externa | Presença de _report._tls.[terceiro] se rua aponta para fora |
| Tags desconhecidos | Campos fora do RFC 8460 sinalizados como info |
| Coerência MTA-STS | Presença de um registo _mta-sts.dominio associado |
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 desconhecido, MTA-STS ausente)
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:
- Publica um endereço de relatório no DNS para o domínio recetor
- Pede aos MTAs emissores que enviem um relatório JSON quando TLS falha
- Fornece um rasto das falhas de cifragem (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 cifragem 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
| Verificação | Erro se... |
|---|---|
TXT presente em _smtp._tls.dominio | Nenhum registo |
Começa por v=TLSRPTv1 | Prefixo ausente ou caixa incorreta |
| Registo único | Vários TXTs TLS-RPT detetados |
| Sem CNAME | _smtp._tls aponta para um CNAME (proibido) |
Sintaxe do registo
| Verificação | Erro se... |
|---|---|
Tag v= em primeira posição | Versão ausente ou não primeira |
Tag rua= presente | Nenhum destino definido |
Valor exato TLSRPTv1 | Variantes como TLSRPT1 ou tlsrptv1 |
URIs de relatório
| Verificação | Erro se... |
|---|---|
mailto: válido | Endereço email mal formado, espaços proibidos |
https: válido | Esquema em falta ou URL malformada |
| Pelo menos uma URI | Tag rua vazio |
Qualidade da rua
- O domínio da URI rua coincide com o domínio verificado → sem necessidade de autorização externa
- O domínio é diferente → verificar a presença de
[dominio]._report._tls.[terceiro](autorização cross-domain) - 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 registo
- Política coerente com o deployment mail do domínio
Diagnósticos comuns e soluções
Registo 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 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: o RFC proíbe CNAME neste local. Publique um TXT direto.
Autorização externa necessária (rua_unauthorized_external)
Causa: o endereço rua usa um domínio diferente do domínio TLS-RPT.
Solução: o domínio recetor (por exemplo uriports.com) deve publicar:
captaindns.com._report._tls.uriports.com. IN TXT "v=TLSRPTv1"
Este registo autoriza a entrega de relatórios para captaindns.com.
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.
Autorização cross-domain e rua externa
O RFC 8460 retoma a convenção DMARC (RFC 7489 §7.1): um domínio não pode pedir a outro domínio que receba os seus relatórios sem o seu consentimento explícito.
O mecanismo
O seu domínio: captaindns.com
URI rua: mailto:tls-reports@uriports.com
O domínio externo uriports.com deve publicar:
captaindns.com._report._tls.uriports.com. IN TXT "v=TLSRPTv1"
Sem este registo, os MTAs emissores conformes recusam reencaminhar os relatórios para uriports.com (protegem os analisadores terceiros contra abusos de redirecionamento).
Armadilhas comuns
- Confusão com DMARC: DMARC usa
_report._dmarc.[terceiro], TLS-RPT usa_report._tls.[terceiro]. Verifique o prefixo correto. - Vários domínios monitorizados: um analisador multi-tenant (Postmark, Uriports, Dmarcian, Valimail, Sendmarc) deve publicar um registo por domínio cliente (
cliente1.pt._report._tls.postmarkapp.com,cliente2.pt._report._tls.postmarkapp.com, etc.). - Sem wildcard permitido: é necessário um registo explícito por par (domínio monitorizado, domínio analisador).
- O checker sinaliza automaticamente as rua externas sem autorização publicada.
TLS-RPT e MTA-STS: deployment combinado
Os dois protocolos formam uma defesa em profundidade:
| Protocolo | Papel | Localização |
|---|---|---|
| MTA-STS | Impõe a cifragem TLS (RFC 8461) | _mta-sts.dominio + política HTTPS |
| TLS-RPT | Reporta as falhas (RFC 8460) | _smtp._tls.dominio |
Ordem de deployment recomendada
- Publicar TLS-RPT primeiro para recolher os relatórios
- Implementar MTA-STS em modo testing sem bloquear a entrega
- Observar 2 a 4 semanas os relatórios TLS-RPT para identificar os MX problemáticos
- Passar MTA-STS para modo enforce quando os relatórios estiverem limpos
- 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
| Ferramenta | Utilidade |
|---|---|
| Validador sintaxe TLS-RPT | Validar a sintaxe de um registo ANTES de publicar |
| Gerador TLS-RPT | Criar um registo TLS-RPT conforme RFC 8460 |
| MTA-STS Checker | Verificar o deployment MTA-STS associado |
| Hospedagem MTA-STS | Aloje gratuitamente a sua política com TLS gerido |
| DMARC Checker | Completar a autenticação email com DMARC |
| DANE TLSA Checker | Alternativa DNSSEC para segurança TLS |
| Analisador de relatórios TLS-RPT | Descodificar os relatórios JSON recebidos |
| Monitoramento TLS-RPT | Receba e analise automaticamente os seus relatórios TLS-RPT |
Recursos: