Porquê validar a sintaxe DMARC antes da publicação?
Um registo DMARC mal formatado é ignorado silenciosamente pelo Gmail, Outlook, Yahoo e todos os servidores destinatários. Nenhum alerta é emitido. Os seus emails ficam sem protecção contra spoofing e phishing.
O validador lê o seu registo antes da publicação DNS, verifica cada tag e os URIs de relatório. Corrige 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 7489
A RFC 7489 define cada tag permitida num registo 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 |
| adkim | Modo de alinhamento DKIM, r (relaxado) ou s (estrito) | adkim=s |
| aspf | Modo de alinhamento SPF, r ou s | aspf=r |
| pct | Percentagem de mensagens sujeitas à política, 1 a 100 | pct=50 |
| 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. As restantes assumem valores por defeito se omissas (adkim=r, aspf=r, pct=100).
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 registos 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 7489.
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 aceites 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; pct=100; rua=mailto:dmarc@captaindns.com
O valor pct deve ser um inteiro entre 1 e 100.
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 1-100 | Usar um inteiro entre 1 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 7489 |
| 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 mas parcial: a protecção permanece incompleta enquanto a política se mantém em none ou pct está abaixo de 100.
FAQ - Perguntas frequentes
Que progressão adoptar 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 directamente 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. Active-os apenas se dispuser de uma pipeline de análise e de um parecer jurídico sobre a recolha desses dados.
Devo configurar a tag sp= nos subdomínios?
Por defeito, 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?
Esta versão aplica as regras da RFC 7489. Para antecipar a transição para DMARCbis (remoção de pct, ri, rf, adição de np, psd, t), use o DMARCbis Checker ou a ferramenta de migração DMARCbis.
Ferramentas complementares
| Ferramenta | Utilidade |
|---|---|
| DMARC Checker | Verificar a publicação e resolver o registo DMARC a partir do DNS |
| Gerador DMARC | Criar um registo DMARC conforme à 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 registo DMARC para o novo padrão |
| Monitoring DMARC | Receba e analise automaticamente seus relatórios DMARC agregados |