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

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

Por que validar a sintaxe TLS-RPT offline?

Um registro inválido é silenciosamente ignorado pelos servidores emissores: você não recebe nenhum relatório e só descobre o problema quando ocorre um incidente. A validação offline detecta 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 da URI, endereço email mal formado e tag desconhecido herdado 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 registro 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 registro 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 registro. 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 criptografia TLS, TLS-RPT informa-o quando essa imposição falha. Sem TLS-RPT, você não saberá se servidores externos não conseguem se conectar via TLS ao seu domínio.

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

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

TLS-RPT Validator gratuito - Sintaxe offline

Por que usar um validador offline

Um validador de sintaxe TLS-RPT analisa o seu registro 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 registro seja silenciosamente ignorado pelos MTAs.
Validação de rascunho → verifique a sintaxe de um registro copiado de um gerador, wiki interno ou template compartilhado.
Depuração offline → reproduza e corrija um erro sem depender do DNS público, por exemplo em um registro de pré-produção que ainda não foi publicado.
Revisão de configuração → examine um registro 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 roda nos nossos servidores: o registro que você cola é enviado ao CaptainDNS para análise. Nada é publicado, nenhuma consulta DNS é feita e nenhuma URI rua é contatada.

Como usar este validador em 2 passos

Passo 1: colar o registro

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

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

Você pode colar um rascunho, um registro existente ou a saída de um gerador. O validador não lê nenhuma fonte externa: analisa apenas o texto que você fornece.

Passo 2: analisar o veredito

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

Erro → problema bloqueante, o registro 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 registro 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 registro 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 registro	manual (colado)	DNS público
Identificação das URIs externas	nenhuma	automática
Detecção do valor publicado	estática	estado real
Dados enviados ao servidor	o registro colado	domínio analisado

Fluxo recomendado:

Projete o registro → 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 detecta erros de digitação antes da publicação. O record check detecta desvios e confirma que o registro 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 registro 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

Essa sobriedade vem da RFC 8460. O DMARC exige um registro de autorização _report._dmarc no destinatário assim que os relatórios seguem para outro domínio; o §7 da RFC 8460 descartou de propósito esse mecanismo no TLS-RPT. Não há, então, nada com que confrontar as suas URIs rua: um endereço num fornecedor terceiro de coleta de relatórios vale do jeito que está.

Para saber quais das suas URIs já publicadas saem do seu domínio, quem as aponta é o record check, a partir do domínio consultado.

Regras de sintaxe verificadas

O validador aplica as regras da RFC 8460 §3 sobre o registro 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 em um domínio diferente do registro

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 em um domínio diferente do registro

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 coleta 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 registro _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 controle prévio do lado do destinatário

O validador nunca as rejeita. Também não as distingue das demais: sem um domínio de referência, não tem com o que compará-las.

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 registro 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 aceitas 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 coleta) é perfeitamente válida. Ao contrário do DMARC, o TLS-RPT não impõe qualquer registro de autorização do lado do destinatário: o validador nunca rejeita um registro por causa de uma rua externa.

Você 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 criptografia TLS para email de entrada
TLS-RPT	reporta falhas e anomalias de conexão TLS

Por que 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 criptografia
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 registro TLS-RPT com este validator
Publique TLS-RPT primeiro (para coletar relatórios desde a fase testing de MTA-STS)
Publique MTA-STS em mode: testing
Monitore 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 registro publicado no DNS
Monitoramento TLS-RPT	receba e analise automaticamente os seus relatórios TLS-RPT
TLS-RPT generator	criar um registro 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 monitorar a criptografia TLS dos seus emails - entender 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 registro TLS-RPT (§3)
Considerações de segurança - rua externa (§7)