Por que validar a sintaxe DMARC antes da publicação?
Um registro DMARC mal formatado é ignorado silenciosamente pelo Gmail, Outlook, Yahoo e todos os servidores destinatários. Nenhum alerta é emitido. Os seus emails ficam sem proteção contra spoofing e phishing.
O validador lê o seu registro antes da publicação DNS, verifica cada tag e os URIs de relatório. Corrija os erros imediatamente, sem esperar 24 a 48 horas de propagação apenas para descobrir que um detalhe impede a aplicação da política.
Tags DMARC segundo a RFC 9989
A RFC 9989 define cada tag permitida num registro DMARC. O validador verifica o nome, a posição e o valor de cada tag.
| Tag | Função | Exemplo |
|---|---|---|
| v | Versão do protocolo, sempre em primeira posição | v=DMARC1 |
| p | Política aplicada ao domínio principal | p=quarantine |
| sp | Política aplicada aos subdomínios | sp=reject |
| np | Política para subdomínios inexistentes | none / quarantine / reject |
| t | Modo de teste RFC 9989 | y / n |
| adkim | Modo de alinhamento DKIM, r (relaxado) ou s (estrito) | adkim=s |
| aspf | Modo de alinhamento SPF, r ou s | aspf=r |
| pct | Tag histórica / depreciada, intervalo 0-100 | Omitir |
| rua | Destinos dos relatórios agregados (URI mailto) | rua=mailto:dmarc@captaindns.com |
| ruf | Destinos dos relatórios forenses (URI mailto) | ruf=mailto:forensic@captaindns.com |
| fo | Opções de geração dos relatórios forenses | fo=1 |
As tags v e p são obrigatórias. Quando omitidas, adkim e aspf assumem o valor r. Recomenda-se omitir pct, que agora é uma tag histórica.
Exemplos de correção antes e depois
O validador sinaliza cada erro de sintaxe com a sua posição. A seguir três casos frequentes detectados em registros publicados.
URI rua mal formado:
- v=DMARC1; p=reject; rua=reports@captaindns.com
+ v=DMARC1; p=reject; rua=mailto:reports@captaindns.com
O prefixo mailto: é obrigatório segundo a RFC 9989.
Política p inválida:
- v=DMARC1; p=monitor; rua=mailto:dmarc@captaindns.com
+ v=DMARC1; p=none; rua=mailto:dmarc@captaindns.com
Apenas são aceitos os valores none, quarantine e reject.
pct fora do intervalo:
- v=DMARC1; p=quarantine; pct=150; rua=mailto:dmarc@captaindns.com
+ v=DMARC1; p=quarantine; rua=mailto:dmarc@captaindns.com
O valor pct está fora do intervalo 0-100; a correção é omitir pct.
Diagnósticos comuns do validador
O validador devolve um código curto por cada anomalia detectada. Os códigos abaixo são os mais frequentes.
| Código | Causa | Ação |
|---|---|---|
| missing_version_tag | Tag v=DMARC1 ausente | Adicionar v=DMARC1 em primeira posição |
| unsupported_version | Valor de v= diferente de DMARC1 | Substituir por v=DMARC1 |
| missing_policy | Tag p= ausente | Adicionar p=none, p=quarantine ou p=reject |
| invalid_policy | Valor de p= fora de none/quarantine/reject | Corrigir o valor |
| invalid_subdomain_policy | Valor de sp= inválido | Usar none, quarantine ou reject |
| invalid_alignment | Valor de adkim= ou aspf= diferente de r/s | Ajustar para r ou s |
| invalid_percent | pct= fora do intervalo 0-100 | Usar um inteiro entre 0 e 100 |
| invalid_rua_uri | URI rua mal formado | Usar mailto:endereco@dominio |
| invalid_ruf_uri | URI ruf mal formado | Usar mailto:endereco@dominio |
| invalid_failure_option | Valor fo= não reconhecido | Usar 0, 1, d ou s |
| duplicate_tag | Tag declarada duas vezes | Conservar uma única ocorrência |
| unknown_tag | Nome de tag não reconhecido | Verificar a ortografia segundo a RFC 9989 |
| np_absent | np ausente | Verificar a herança de sp ou p |
| deprecated_pct | pct histórico presente | Remover pct |
| testing_mode_active | t=y ativo | A pontuação reflete a aplicação efetiva da política |
| migrate_to_dmarcbis | Tags históricas detectadas | Usar a ferramenta de migração para corrigir o registro |
| record_trailing_quote | Cadeia TXT terminada por aspas | Remover as aspas finais |
Os códigos de aviso (policy_none, pct_less_than_100, subdomain_policy_none) indicam uma configuração válida que deve ser revisada. pct_less_than_100 se refere a uma tag histórica: segundo a RFC 9989, omita pct em vez de definir pct=100.
FAQ - Perguntas frequentes
Que progressão adotar para a política p=?
Comece sempre com p=none para observar o tráfego através dos relatórios agregados (rua). Quando SPF e DKIM estiverem alinhados em todas as suas fontes legítimas, passe para p=quarantine e depois p=reject. Evite saltar diretamente para p=reject: os relatórios rua da fase de observação revelam quase sempre fluxos legítimos esquecidos.
Devo configurar ruf além de rua?
Não no início. Os relatórios rua agregados (diários) são essenciais para orientar a sua implementação. Os relatórios forenses ruf (por mensagem falhada) geram um volume importante e podem conter dados pessoais. Ative-os apenas se dispuser de um pipeline de análise e de um parecer jurídico sobre a coleta desses dados.
Devo configurar a tag sp= nos subdomínios?
Por padrão, os subdomínios herdam a política p. Configure sp= apenas se a política dos subdomínios deve diferir do domínio raiz. Verifique que SPF e DKIM estão alinhados em cada subdomínio emissor antes de endurecer sp=.
O validador aplica as regras DMARCbis?
O DMARCbis foi publicado em maio de 2026 como RFC 9989, RFC 9990 e RFC 9991. A RFC 9989 torna a RFC 7489 obsoleta; v=DMARC1 não muda. O DMARCbis Checker explica o tree walk DNS e a ferramenta de migração remove tags históricas.
Ferramentas complementares
| Ferramenta | Utilidade |
|---|---|
| DMARC Checker | Verificar a publicação e resolver o registro DMARC a partir do DNS |
| Gerador DMARC | Criar um registro DMARC em conformidade com a especificação |
| Validador SPF | Validar a sintaxe SPF do seu domínio |
| Validador DKIM | Validar a sintaxe de uma chave DKIM |
| Migração DMARCbis | Migrar um registro DMARC para o novo padrão |
| Monitoring DMARC | Receba e analise automaticamente seus relatórios DMARC agregados |