MTA-STS Validator Grátis

Por que usar um validador offline

Um validador de sintaxe MTA-STS analisa o seu registro DNS TXT e o seu arquivo de política sem publicá-los nem consultar o DNS. Esta abordagem offline cobre três casos de uso chave que uma auditoria ao vivo não consegue tratar.

Casos de uso típicos:

• Antes da implantação → Valide um rascunho de política antes da publicação, para evitar uma configuração incorreta em produção.
• Preparação multi-domínio → Verifique várias políticas em lote durante uma migração ou auditoria interna.
• Depuração offline → Reproduza e corrija um erro sem acesso ao 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 as regras de sintaxe do RFC 8461: versão, identificador, modo, padrões MX, max_age e coerência entre o registro DNS e a política. Não se conecta a nenhum servidor, não faz resolução DNS e não baixa nenhum arquivo remoto.

Como usar este validador em 3 passos

Passo 1: colar o registro e a política

Você pode validar três combinações:

• Apenas o registro TXT _mta-sts (modo record_only)
• Apenas o conteúdo do arquivo mta-sts.txt (modo policy_only)
• Ambos juntos para verificar a coerência (modo combinado)

Nenhuma conexão de rede é feita. Os seus dados permanecem no seu navegador.

Passo 2: adicionar um domínio (opcional)

Adicionar um domínio ativa a validação híbrida: o validador resolve os registros MX do domínio e verifica se os padrões declarados na política correspondem aos servidores reais. Este modo ajuda a detectar uma política demasiado restritiva ou um MX esquecido.

Sem domínio, apenas a sintaxe pura é analisada.

Passo 3: analisar o veredicto

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

• ❌ Erro → Problema bloqueante, a política será ignorada pelos MTA destinatários
• ⚠️ Aviso → Funcional mas melhoria recomendada
• ✅ Válido → Sintaxe conforme com RFC 8461

Corrija cada alerta antes de publicar o seu registro e o seu arquivo em produção.

Validador ou record check: quando usar cada ferramenta

As duas ferramentas são complementares. Não se substituem entre si: intervêm em momentos diferentes do ciclo de vida de uma política MTA-STS.

Fluxo de trabalho recomendado:

1. Desenhe a política → validador para verificar a sintaxe
2. Publique DNS + arquivo → aguarde a propagação
3. Record check para confirmar a auditoria ao vivo completa

O validador detecta erros de entrada antes que cheguem aos seus utilizadores. O record check detecta drifts, certificados expirados e problemas de fetch HTTPS que só aparecem em condições reais.

Modos de validação

O validador suporta quatro modos consoante os campos preenchidos.

Modo record_only

Cola apenas o registro TXT. Validação de:

• Formato v=STSv1
• Presença e formato da tag id
• Tags desconhecidas ou duplicadas

Modo policy_only

Cola apenas o conteúdo do arquivo de política. Validação de:

• Diretiva version
• Diretiva mode (enforce, testing, none)
• Padrões mx (pelo menos um obrigatório)
• Diretiva max_age (limites 0 a 31557600)

Modo combinado de registro e política

Cola ambos. Validação completa mais:

• Coerência de versão entre TXT e arquivo
• Coerência de intenção (um mode: none com um id ativo é suspeito)

Modo híbrido com domínio

Adicione um domínio ao modo combinado para ativar:

• Resolução dos MX do domínio
• Verificação de que cada MX real corresponde a pelo menos um padrão mx:
• Detecção de servidores MX esquecidos ou padrões demasiado estritos

Esta validação MX permanece estática: compara os padrões com os hosts MX declarados sem testar as conexões SMTP.

Regras de sintaxe verificadas

Registro DNS

O validador aplica as regras do RFC 8461 §3.1 sobre o TXT _mta-sts.dominio:

Exemplo válido:

v=STSv1; id=20240115120000

Arquivo de política

O validador aplica RFC 8461 §3.2 sobre mta-sts.txt:

Exemplo válido:

version: STSv1
mode: enforce
mx: mail.captaindns.com
mx: *.backup.captaindns.com
max_age: 604800

Coerência entre registro e política

Quando ambos são fornecidos:

• O id do TXT deve corresponder a uma política coerente (uma mudança de política implica um novo id).
• mode: none com um TXT ativo é sinalizado: muitas vezes indica uma intenção de retirada incompleta.

Padrões MX e regras wildcard

O RFC 8461 §4.1 define um formato estrito para os padrões mx:. O validador aplica o seguinte matching exato.

Nome de host exato

mx: mail.captaindns.com
mx: smtp.captaindns.com

Corresponde ao nome exato, sem distinguir maiúsculas/minúsculas.

Padrão wildcard

mx: *.mail.captaindns.com

Regras estritas:

• O wildcard * deve ser o rótulo mais à esquerda
• Corresponde a exatamente um rótulo (server1.mail.captaindns.com corresponde, a.b.mail.captaindns.com não)
• Sem duplo wildcard (**.captaindns.com é inválido)
• Sem wildcard no meio ou no fim (mail.*.captaindns.com é inválido)

Vários padrões numa política

Uma política pode conter várias linhas mx::

mx: mail.captaindns.com
mx: smtp.captaindns.com
mx: *.backup.captaindns.com

Um MX real deve corresponder a pelo menos um padrão. O validador sinaliza os MX reais órfãos quando um domínio é fornecido.

Padrões inválidos típicos

Erros de sintaxe comuns e correções

Versão incorreta

Causa: v=sts1, v=STSV1 ou version: stsv1 em vez de STSv1 exatamente.

Correção:

- v=sts1; id=20240115
+ v=STSv1; id=20240115

Identificador ausente

Causa: o registro TXT não contém a tag id.

Correção: adicione um identificador único (timestamp recomendado):

v=STSv1; id=20240115120000

Formato de id incorreto

Causa: espaços, caracteres especiais ou comprimento excessivo em id.

Correção: use apenas caracteres alfanuméricos, 1 a 32 caracteres.

- id=my policy id
+ id=mypolicyid20240115

Modo inválido

Causa: mode: strict, mode: ENFORCE ou erro de digitação.

Correção: apenas um dos três valores permitidos:

- mode: strict
+ mode: enforce

max_age fora dos limites

Causa: negativo, não numérico ou superior a 31557600.

Correção: inteiro em [0, 31557600]. Valor recomendado para produção: 604800 (1 semana).

- max_age: 99999999
+ max_age: 604800

Padrão malformado

Causa: wildcard mal colocado ou caracteres proibidos numa linha mx:.

Correção: veja a secção padrões MX acima.

- mx: mail.*.captaindns.com
+ mx: *.mail.captaindns.com

Sem padrão de servidor

Causa: nenhuma linha mx: numa política em modo enforce ou testing.

Correção: adicione pelo menos uma linha mx: que corresponda à sua infraestrutura. No modo none, a ausência de mx: é tolerada.

Ferramentas complementares e recursos

Guias relacionados

• MTA-STS: o guia completo para proteger o transporte dos seus emails - Configuração, implantação e melhores práticas.
• Resolução de problemas MTA-STS: erros comuns e soluções - Diagnosticar problemas de política em produção.
• Passar MTA-STS do modo testing para o modo enforce - Migração progressiva sem prejudicar a entregabilidade.

Especificações

• RFC 8461 - SMTP MTA Strict Transport Security (especificação oficial)
• Formato do registro DNS MTA-STS (§3.1)
• Formato do arquivo de política MTA-STS (§3.2)
• Documentação MTA-STS do Google (guia Workspace)

FAQ - Perguntas frequentes

P: Qual a diferença entre o validador e o record check MTA-STS?

R: O validador analisa a sintaxe que você cola, antes da publicação, sem tocar no DNS. O record check consulta DNS e HTTPS para verificar a configuração publicada. Use o validador a montante e o record check a jusante.

P: Por que validar a sintaxe MTA-STS offline?

R: Para detectar erros antes que cheguem aos seus utilizadores. Uma política inválida é ignorada pelos MTA destinatários: o seu domínio permanece exposto. É melhor corrigir uma gralha num rascunho do que diagnosticar uma falha em produção.

P: Quais são os erros de sintaxe comuns?

R: Os clássicos: STSV1 em vez de STSv1, mode: strict em vez de enforce, max_age não numérico, wildcard mal colocado (mail.*.captaindns.com), ausência da tag id no TXT ou várias linhas version no arquivo.

P: Quais formatos de padrão MX são válidos?

R: Nome exato (mail.captaindns.com) ou wildcard de um único rótulo em posição leftmost (*.mail.captaindns.com). Sem wildcard nu, sem duplo wildcard, sem wildcard no meio de um nome.

P: Quais valores max_age são recomendados?

R: O RFC 8461 impõe 0 ≤ max_age ≤ 31557600 (1 ano). Valores comuns: 86400 (1 dia) para a fase de testing, 604800 (1 semana) para produção estável, 31557600 (1 ano) para uma política madura e fixa.

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

R: A versão deve ser exatamente STSv1 (sensível a maiúsculas/minúsculas) no TXT (v=STSv1) e na política (version: STSv1). Verifique maiúsculas/minúsculas, espaços e a ausência de caracteres parasitas.

P: Como valido a sintaxe MTA-STS para Microsoft 365?

R: Cole o seu TXT e a sua política. Certifique-se de que os seus padrões MX cobrem *.mail.protection.outlook.com. O validador verifica a conformidade RFC 8461 antes da publicação no DNS, depois use o record check após a implantação.

P: Como verifico a sintaxe MTA-STS para Google Workspace?

R: Cole o seu TXT e a sua política. Os MX do Google estão em *.google.com (ou aspmx.l.google.com). Certifique-se de que os seus padrões correspondem a estes hostnames antes de publicar.