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 qualquer pedido de rede. O record check consulta o DNS em tempo real para inspecionar o registo publicado em _smtp._tls.dominio. 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 ausente ou incorreta (TLSRPT1 em vez de TLSRPTv1), tag rua ausente, esquema mailto: ou https: esquecido antes do endpoint, endereço email mal formado e autorização cross-domain ausente para endpoints externos.

O validator verifica a cross-domain authorization?

Sim, se preencher o campo domínio (modo record_and_domain). O validator analisa então cada endpoint externo (mailto ou https que aponta para outro domínio) e verifica que existe um registo TLSRPT de autorização do lado do destinatário.

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

Os endpoints mailto recebem os relatórios como anexos email (JSON comprimido gzip). Os endpoints 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 cifragem 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 cifragem.

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 três 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 tocar no DNS público, por exemplo em ambiente isolado ou pré-produção.
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: versão TLSRPTv1, tag rua, formato dos endpoints mailto: e https:, cross-domain authorization e ausência de tags desconhecidas. Nenhuma consulta DNS é realizada. Os seus dados permanecem no seu navegador.

Como usar este validador em 3 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 realiza qualquer ligação de rede neste passo.

Passo 2: adicionar um domínio (opcional)

Indicar um domínio ativa a verificação de cross-domain authorization. O validador passa ao modo record_and_domain e analisa cada endpoint externo para verificar que existe um registo TLSRPT de autorização do lado do destinatário.

Sem domínio, apenas a sintaxe pura é analisada (modo record_only).

Passo 3: analisar o veredito

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
Verificação cross-domain	opcional (via domain)	sistemática
Deteção do valor publicado	estática	estado real
Dados enviados ao servidor	nenhum	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.

Modos de validação

O validador suporta dois modos conforme os campos preenchidos.

Modo record_only

Cola apenas o registo TLS-RPT. Validação pura de sintaxe:

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

Nenhum pedido de rede. Ideal para validar um rascunho antes da publicação.

Modo record_and_domain

Cola o registo e um domínio. Além da validação de sintaxe, o validador realiza uma verificação de cross-domain authorization para os endpoints externos:

deteta cada endpoint cujo domínio difere do domínio analisado
procura o registo TLSRPT de autorização do lado do destinatário
sinaliza os endpoints externos sem autorização

Este modo ajuda a detetar configurações em que aponta para um fornecedor terceiro (análise gerida de relatórios) sem que ele tenha publicado a autorização do lado do servidor.

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 um ou mais endpoints separados 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

Formatos de endpoint rua

Cada endpoint 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ários endpoints são possíveis, separados por ,:

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

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

Endpoints rua: mailto vs https

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

Endpoints mailto

rua=mailto:tls-reports@captaindns.com

Características:

relatórios recebidos como anexos email (JSON comprimido gzip)
configuração simples, sem desenvolvimento necessário
frequentemente um endereço dedicado (tls-reports@, reports@)
nenhuma cross-domain authorization necessária se o email estiver no mesmo domínio que o registo

Endpoints 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 cross-domain authorization necessária se o host estiver no mesmo domínio que o registo

Cross-domain authorization

Quando um endpoint aponta para um domínio diferente do analisado (por exemplo um coletor de relatórios de terceiros), a RFC 8460 §3.3 exige uma autorização do lado do destinatário:

o destinatário publica um registo TLSRPT em [dominio-origem]._report._tls.[dominio-destinatario]
sem esta autorização, os servidores emissores não enviarão os relatórios

O validador sinaliza os endpoints externos sem esta autorização, desde que tenha preenchido o campo domínio.

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 ausente ou incorreta

Causa: tag v= ausente 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 ausente

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

Correção: adicione pelo menos um endpoint:

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

Endpoint mailto inválido

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

Endpoint https inválido

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

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

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

Cross-domain não autorizado

Causa: um endpoint externo (outro domínio que o analisado) aponta para um destinatário que não publicou um registo TLSRPT de autorização.

Correção: peça ao fornecedor terceiro para publicar o registo de autorização, ou use um endpoint no seu próprio domínio:

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

Tag desconhecida

Causa: presença de uma tag não definida pela RFC 8460 (por exemplo ruf=, que não existe em 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 cifragem 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 cifragem
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
Monitoramento 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 cifragem 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)
Autorização cross-domain (§3.3)