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 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á. Se você preencher o campo domínio, o validator limita-se a identificar as URIs externas a título informativo, sem nunca as rejeitar.

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 tocar no DNS público, por exemplo em ambiente isolado ou pré-produção.
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. Nenhuma consulta DNS é realizada. Os seus dados permanecem no seu navegador.

Como usar este validador em 3 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 realiza nenhuma conexão de rede nesta etapa.

Passo 2: adicionar um domínio (opcional)

Indicar um domínio ativa a detecção das URIs externas. O validador passa ao modo record_and_domain e identifica cada URI rua que aponta para outro domínio. Esta informação é puramente indicativa: o TLS-RPT não exige qualquer autorização do lado do destinatário para uma rua externa.

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

Modos de validação

O validador suporta dois modos conforme os campos preenchidos.

Modo record_only

Cole apenas o registro TLS-RPT. Validação pura de sintaxe:

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

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

Modo record_and_domain

Cole o registro e um domínio. Além da validação de sintaxe, o validador identifica as URIs externas (rua que aponta para outro domínio):

detecta cada URI cujo domínio difere do domínio analisado
sinaliza essas URIs externas a título informativo

Ao contrário do DMARC, o TLS-RPT não exige qualquer registro de autorização do lado do destinatário (a RFC 8460 afastou esse mecanismo). Uma URI para um fornecedor terceiro de coleta de relatórios é, portanto, válida tal como está; este modo serve apenas para avisar você de que os seus relatórios partem para um domínio externo.

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

Se você preencher o campo domain, o validador identifica as URIs externas a título puramente informativo, para avisar você de que os seus relatórios partem para um domínio terceiro. Nunca as rejeita.

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)