Qual é a diferença entre validator e record check para TLS-RPT?

O validator analisa uma sintaxe que cola, antes da publicação DNS, sem ler a configuração já ativa. O record check consulta o DNS em tempo real para inspecionar o registo publicado em _smtp._tls.domínio. Use o validator a montante, o record check a jusante.

Porquê validar a sintaxe TLS-RPT offline?

Um registo inválido é silenciosamente ignorado pelos servidores emissores: não recebe qualquer relatório e só descobre o problema quando ocorre um incidente. A validação offline deteta os problemas antes que afetem a sua visibilidade sobre falhas TLS.

Quais são os erros de sintaxe TLS-RPT mais comuns?

Erros típicos: versão em falta ou incorreta (TLSRPT1 em vez de TLSRPTv1), tag rua em falta, esquema mailto: ou https: esquecido antes da URI, endereço email mal formado e tag desconhecida herdada do DMARC como ruf= que não existe no TLS-RPT.

É necessária autorização para enviar os relatórios para outro domínio?

Não. Ao contrário do DMARC, o TLS-RPT não exige qualquer registo de autorização do lado do destinatário para uma rua externa: a RFC 8460 afastou esse mecanismo. Uma URI que aponta para um serviço terceiro é, portanto, válida tal como está, e o validador nunca rejeita um registo por causa de uma rua externa.

Qual é a diferença entre URIs mailto e https?

As URIs mailto recebem os relatórios como anexos email (JSON comprimido com gzip). As URIs https recebem os relatórios via HTTP POST num webhook. mailto é mais simples de implementar, https permite processamento automatizado.

Como corrijo um erro 'versão inválida'?

A versão deve ser exatamente v=TLSRPTv1 (sensível a maiúsculas), no início do registo. Verifique a capitalização, os espaços e a ausência de caracteres estranhos. v=TLSRPT1 e v=tlsrptv1 são rejeitados.

Devo também implementar MTA-STS em conjunto com TLS-RPT?

Sim, altamente recomendado. MTA-STS impõe a encriptação TLS, TLS-RPT informa-o quando essa imposição falha. Sem TLS-RPT, não saberá se servidores externos não conseguem ligar-se em TLS ao seu domínio.

Como validar a sintaxe TLS-RPT para Microsoft 365 e Google Workspace?

Cole o seu registo TLS-RPT no validator. A sintaxe é idêntica seja qual for o fornecedor. Para Microsoft 365 ou Google Workspace, o registo deve ser publicado em _smtp._tls.captaindns.com após a validação. Combine com MTA-STS para forçar a encriptação.

TLS-RPT Validator gratuito - Sintaxe offline

Porquê usar um validador offline

Um validador de sintaxe TLS-RPT analisa o seu registo sem publicar nem consultar o DNS. Esta abordagem offline cobre quatro casos de uso principais que a auditoria em tempo real não pode tratar.

Casos de uso típicos:

Antes do deployment → valide um rascunho antes da publicação DNS, para evitar que um registo seja silenciosamente ignorado pelos MTAs.
Validação de rascunho → verifique a sintaxe de um registo copiado de um gerador, wiki interno ou template partilhado.
Depuração offline → reproduza e corrija um erro sem depender do DNS público, por exemplo num registo de pré-produção que ainda não foi publicado.
Revisão de configuração → examine um registo recebido de um parceiro ou exportado de uma ferramenta de terceiros antes de aplicá-lo.

O validador aplica a especificação RFC 8460 sobre a sintaxe: versão TLSRPTv1, tag rua, formato das URIs mailto: e https:, e ausência de tags desconhecidas. A validação corre nos servidores da CaptainDNS: o registo que cola é enviado para análise. Nada é publicado, não é emitida qualquer consulta DNS nem contactada qualquer URI rua.

Como usar este validador em 2 passos

Passo 1: colar o registo

Copie o valor do seu registo TLS-RPT no campo previsto:

v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com

Pode colar um rascunho, um registo existente ou a saída de um gerador. O validador não lê qualquer fonte externa: analisa apenas o texto que fornece.

Passo 2: analisar o veredicto

Os resultados são classificados por nível de gravidade:

Erro → problema bloqueante, o registo será ignorado ou rejeitado pelos servidores emissores
Aviso → funcional mas melhoria recomendada
Válido → sintaxe conforme RFC 8460

Corrija cada alerta antes de publicar o registo no DNS público.

Validator ou record check: quando usar cada ferramenta

As duas ferramentas são complementares. Não se substituem: intervêm em momentos diferentes do ciclo de vida de um registo TLS-RPT.

Dimensão	Validator (esta ferramenta)	Record check
Momento de uso	antes do deployment	depois do deployment
Lookup DNS	nenhum	resolução `_smtp._tls` em tempo real
Origem do registo	manual (colado)	DNS público
Identificação das URIs externas	nenhuma	automática
Deteção do valor publicado	estática	estado real
Dados enviados ao servidor	o registo colado	domínio analisado

Fluxo recomendado:

Projete o registo → validator para verificar a sintaxe
Publique o TXT no DNS → aguarde a propagação
Record check para confirmar o estado em tempo real

O validador deteta erros de digitação antes da publicação. O record check deteta desvios e confirma que o registo servido pelo DNS corresponde ao projeto previsto.

Um único campo, um único modo

O formulário tem uma só caixa de texto: o próprio registo TLS-RPT. Sem domínio, sem segundo modo. É isto que fica verificado:

versão TLSRPTv1 exata, em primeira posição
presença da tag rua=
formato das URIs (mailto: ou https:)
endereços email bem formados em URIs mailto:
tags desconhecidas reportadas como avisos

Esta sobriedade vem da RFC 8460. O DMARC exige um registo de autorização _report._dmarc junto do destinatário assim que os relatórios seguem para outro domínio; o §7 da RFC 8460 afastou deliberadamente esse mecanismo no TLS-RPT. Não há, pois, nada com que confrontar as URIs rua: um endereço num fornecedor terceiro de recolha de relatórios é válido tal como está.

Para saber quais das URIs já publicadas saem do domínio, é o record check que as assinala, a partir do domínio consultado.

Regras de sintaxe verificadas

O validador aplica as regras da RFC 8460 §3 sobre o registo TXT em _smtp._tls.dominio:

Campo	Regra
v	deve ser exatamente `TLSRPTv1` (case-sensitive), em primeira posição
rua	obrigatório, contém uma ou mais URIs separadas por `,`
Formato global	pares `chave=valor` separados por `;`
Tags desconhecidas	toleradas mas reportadas como avisos
Espaços	tolerados ao redor do `;` e após `=`

Exemplo válido:

v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com

Formato das URIs rua

Cada URI em rua= deve usar um esquema reconhecido:

Esquema	Formato	Uso
`mailto:`	`mailto:endereco@dominio`	relatórios recebidos como anexos email
`https:`	`https://host/caminho`	relatórios enviados a um webhook

Várias URIs são possíveis, separadas por ,:

v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com,https://api.captaindns.com/tlsrpt

Cada URI recebe os mesmos relatórios agregados (um por 24 horas e por emissor).

URIs rua: mailto vs https

A escolha entre mailto: e https: impacta a complexidade do deployment e o processamento dos relatórios.

URIs mailto

rua=mailto:tls-reports@captaindns.com

Características:

relatórios recebidos como anexos email (JSON comprimido com gzip)
configuração simples, sem desenvolvimento necessário
frequentemente um endereço dedicado (tlsrpt@, reports@)
nenhuma autorização do lado do destinatário necessária, mesmo para um endereço num domínio diferente do registo

URIs https

rua=https://tlsrpt.captaindns.com/v1/report

Características:

relatórios enviados via HTTP POST a um webhook
permite processamento automatizado em tempo real
requer um endpoint HTTPS válido (certificado reconhecido)
nenhuma autorização do lado do destinatário necessária, mesmo para um host num domínio diferente do registo

URIs externas (rua para outro domínio)

Quando uma URI aponta para um domínio diferente do analisado (por exemplo um serviço terceiro de recolha de relatórios), o TLS-RPT não exige qualquer autorização do lado do destinatário:

ao contrário do DMARC e do seu registo _report._dmarc, a RFC 8460 não define nenhum mecanismo de verificação: o seu §7 afastou deliberadamente qualquer autorização cross-domain
uma URI externa é, portanto, válida tal como está; os servidores emissores enviam os relatórios sem controlo prévio do lado do destinatário

O validador nunca as rejeita. Também não as distingue das restantes: sem domínio de referência, não tem com que as comparar.

Exemplos inválidos

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

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

- rua=http://tlsrpt.captaindns.com/report
+ rua=https://tlsrpt.captaindns.com/report

Erros de sintaxe comuns e correções

Versão em falta ou incorreta

Causa: tag v= em falta ou valor diferente de TLSRPTv1.

Correção:

- rua=mailto:tls-reports@captaindns.com
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com

- v=TLSRPT1; rua=mailto:tls-reports@captaindns.com
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com

Tag rua em falta

Causa: o registo contém v=TLSRPTv1 sem qualquer URI rua.

Correção: adicione pelo menos uma URI:

- v=TLSRPTv1
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com

URI mailto inválida

Causa: esquema mailto: esquecido, endereço email mal formado ou truncado.

Correção:

- v=TLSRPTv1; rua=tls-reports@captaindns.com
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com

- v=TLSRPTv1; rua=mailto:tlsrpt@
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com

URI https inválida

Causa: esquema http: em vez de https: ou URL incompleta.

Correção: apenas URIs HTTPS são aceites pela RFC 8460.

- v=TLSRPTv1; rua=http://tlsrpt.captaindns.com/report
+ v=TLSRPTv1; rua=https://tlsrpt.captaindns.com/report

URI externa: não é um erro

A saber: uma URI rua que aponta para outro domínio (serviço terceiro de recolha) é perfeitamente válida. Ao contrário do DMARC, o TLS-RPT não impõe qualquer registo de autorização do lado do destinatário: o validador nunca rejeita um registo por causa de uma rua externa.

Pode, portanto, apontar com toda a confiança para um fornecedor terceiro:

v=TLSRPTv1; rua=mailto:tls-reports@uriports.com

Tag desconhecida

Causa: presença de uma tag não definida pela RFC 8460 (por exemplo ruf=, que não existe no TLS-RPT ao contrário do DMARC).

Correção: remova a tag desconhecida:

- v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com; ruf=mailto:forensic@captaindns.com
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com

TLS-RPT e MTA-STS: deployment combinado

TLS-RPT brilha com MTA-STS. Os dois protocolos formam um par inseparável para a segurança do transporte SMTP.

Protocolo	Papel
MTA-STS	aplica a encriptação TLS para email de entrada
TLS-RPT	reporta falhas e anomalias de ligação TLS

Porque implementá-los em conjunto:

MTA-STS sem TLS-RPT → aplica TLS mas não sabe se alguns servidores falham silenciosamente
TLS-RPT sem MTA-STS → recebe relatórios úteis mas sem reforço da encriptação
MTA-STS + TLS-RPT → aplica E mede, com visibilidade completa

Deployment recomendado:

Valide a sua política MTA-STS com o MTA-STS Syntax Checker
Valide o seu registo TLS-RPT com este validator
Publique TLS-RPT primeiro (para recolher relatórios desde a fase testing de MTA-STS)
Publique MTA-STS em mode: testing
Monitorize os relatórios TLS-RPT durante 2 a 4 semanas
Passe MTA-STS para mode: enforce quando os problemas forem resolvidos

Ferramentas complementares e recursos

Ferramenta	Quando usar
TLS-RPT record check	auditoria em tempo real do registo publicado no DNS
Monitorização TLS-RPT	receba e analise automaticamente os seus relatórios TLS-RPT
TLS-RPT generator	criar um registo TLS-RPT conforme RFC 8460
MTA-STS syntax checker	validar a política MTA-STS associada offline
DMARC record check	completar a segurança de autenticação email
Propagação DNS	confirmar a propagação após a publicação

Guias relacionados

TLS-RPT: o guia completo para monitorizar a encriptação TLS dos seus emails - perceber o protocolo e a sua integração com MTA-STS.
Implementar TLS-RPT no Microsoft 365, Google Workspace e OVHcloud - procedimento passo a passo por fornecedor.
Analisar os relatórios TLS-RPT: guia prático - ler e aproveitar os relatórios recebidos.

Especificações

RFC 8460 - SMTP TLS Reporting (especificação oficial)
RFC 8461 - MTA-STS (protocolo complementar)
Formato do registo TLS-RPT (§3)
Considerações de segurança - rua externa (§7)