Compreender a sintaxe de registro DMARC é fundamental para implementar autenticação de e-mail eficaz. Um registro DMARC (Domain-based Message Authentication, Reporting and Conformance) consiste em tags e valores específicos que instruem os servidores de e-mail receptores sobre como lidar com e-mails que falham na autenticação SPF ou DKIM. Este guia abrangente detalha cada tag DMARC com exemplos práticos e técnicas de validação para ajudá-lo a construir políticas DMARC à prova de falhas.

I. Estrutura Central do Registro DMARC

Estrutura de registro DMARC em quatro etapas mostrando versão, política, relatórios e tags de alinhamento.

Os registros DMARC são publicados como registros TXT DNS no subdomínio _dmarc.seudominio.com. A sintaxe básica segue um formato de pares tag-valor separados por ponto e vírgula:

"v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; sp=reject; adkim=s; aspf=s"

Cada tag serve uma função específica na definição da política de autenticação de e-mail do seu domínio. Vamos examinar cada tag em detalhe.

II. Tags DMARC Obrigatórias

Tabela comparativa dos três níveis de política DMARC: none, quarantine e reject, com suas ações e casos de uso.

v (Versão)

Sintaxe: v=DMARC1
Propósito: Especifica a versão do DMARC
Obrigatória: Sim (deve ser a primeira tag)

A tag de versão deve sempre ser DMARC1 e aparecer como a primeira tag no seu registro. Nenhuma outra versão existe.

Exemplo:

v=DMARC1

Erro Comum: Usar qualquer coisa diferente de DMARC1 fará com que o registro seja ignorado.

p (Política)

Sintaxe: p=none|quarantine|reject
Propósito: Define a ação para falha de alinhamento de domínio
Obrigatória: Sim

A tag de política determina o que os servidores receptores devem fazer com e-mails que falham na autenticação DMARC:

  • p=none: Apenas monitoramento, nenhuma ação de aplicação
  • p=quarantine: Colocar e-mails reprovados na pasta de spam/lixo eletrônico
  • p=reject: Rejeitar e-mails reprovados imediatamente

Exemplos:

p=none         # Fase de monitoramento
p=quarantine   # Aplicação moderada
p=reject       # Aplicação total

Melhor Prática: Comece com p=none para monitoramento, progrida gradualmente para p=quarantine e depois p=reject com base na análise de tráfego legítimo.

III. Tags de Política Opcionais

sp (Política de Subdomínio)

Sintaxe: sp=none|quarantine|reject
Propósito: Política para mensagens de subdomínios
Padrão: Herda o valor da política principal

A política de subdomínio permite tratamento diferente para mensagens de subdomínios.

Exemplo:

v=DMARC1; p=quarantine; sp=reject

Esta configuração coloca em quarentena e-mails reprovados do domínio principal, mas rejeita e-mails reprovados de subdomínios.

pct (Porcentagem)

Sintaxe: pct=1-100
Propósito: Porcentagem de mensagens às quais aplicar a política
Padrão: 100

Permite implementação gradual da política especificando qual porcentagem de mensagens reprovadas deve ter a política aplicada.

Exemplos:

pct=25    # Aplicar política a 25% das mensagens reprovadas
pct=50    # Aplicar política a 50% das mensagens reprovadas
pct=100   # Aplicar política a todas as mensagens reprovadas (padrão)

Caso de Uso: Ao migrar de p=none para p=quarantine, comece com pct=10 e aumente gradualmente.

IV. Tags de Alinhamento

Comparação entre os modos de alinhamento relaxado e estrito na autenticação DKIM e SPF.

adkim (Alinhamento DKIM)

Sintaxe: adkim=r|s
Propósito: Modo de alinhamento do identificador DKIM
Padrão: r (relaxado)

  • adkim=r: Alinhamento relaxado (correspondência de subdomínio permitida)
  • adkim=s: Alinhamento estrito (correspondência exata de domínio necessária)

Exemplos:

adkim=r    # mail.exemplo.com pode assinar para exemplo.com
adkim=s    # Apenas exemplo.com pode assinar para exemplo.com

aspf (Alinhamento SPF)

Sintaxe: aspf=r|s
Propósito: Modo de alinhamento do identificador SPF
Padrão: r (relaxado)

  • aspf=r: Alinhamento relaxado (correspondência de subdomínio permitida)
  • aspf=s: Alinhamento estrito (correspondência exata de domínio necessária)

Exemplos:

aspf=r    # Return-Path: [email protected] passa para From: [email protected]
aspf=s    # Return-Path deve corresponder exatamente ao domínio From

V. Tags de Relatórios

rua (Relatórios Agregados)

Sintaxe: rua=mailto:[email protected]
Propósito: Endereço de e-mail para relatórios agregados
Formato: Relatórios XML diários com estatísticas de autenticação

Exemplos:

rua=mailto:[email protected]
rua=mailto:[email protected],mailto:[email protected]

Múltiplos Endereços: Separe com vírgulas para redundância.

ruf (Relatórios Forenses)

Sintaxe: ruf=mailto:[email protected]
Propósito: Endereço de e-mail para relatórios de falhas
Formato: Notificações individuais de falhas com amostras de mensagens

Exemplos:

ruf=mailto:[email protected]
ruf=mailto:[email protected],mailto:[email protected]

Nota de Privacidade: Relatórios forenses contêm conteúdo de mensagens e podem ter implicações de privacidade.

ri (Intervalo de Relatórios)

Sintaxe: ri=segundos
Propósito: Intervalo de relatórios agregados
Padrão: 86400 (24 horas)

Exemplos:

ri=3600     # Relatórios por hora (não recomendado)
ri=86400    # Relatórios diários (padrão)
ri=604800   # Relatórios semanais

Limitação: A maioria dos receptores ignora esta tag e envia relatórios diários independentemente.

fo (Opções Forenses)

Sintaxe: fo=0|1|d|s
Propósito: Condições para geração de relatórios forenses
Padrão: 0

  • fo=0: Gerar relatórios quando SPF e DKIM falham
  • fo=1: Gerar relatórios quando SPF ou DKIM falham
  • fo=d: Gerar relatórios quando DKIM falha
  • fo=s: Gerar relatórios quando SPF falha

Exemplos:

fo=1    # Reportar qualquer falha de autenticação
fo=d    # Reportar apenas falhas de DKIM
fo=s    # Reportar apenas falhas de SPF

VI. Exemplos Avançados de Registro DMARC

Configuração de Monitoramento

v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1

Este registro monitora todo o tráfego sem aplicação e gera relatórios agregados e forenses.

Aplicação Gradual

v=DMARC1; p=quarantine; pct=25; sp=none; rua=mailto:[email protected]; adkim=r; aspf=r

Aplica política de quarentena a 25% das mensagens reprovadas do domínio principal enquanto monitora subdomínios.

Aplicação Estrita

v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]; adkim=s; aspf=s

Aplicação total com alinhamento estrito para domínio principal e subdomínios.

Configuração Empresarial

v=DMARC1; p=reject; sp=quarantine; rua=mailto:[email protected],mailto:[email protected]; ruf=mailto:[email protected]; pct=100; adkim=s; aspf=r; fo=1; ri=86400

Configuração empresarial completa com múltiplos destinos de relatórios e políticas de alinhamento mistas.

VII. Erros Comuns de Sintaxe e Validação

Erros de Formatação

Falta de Ponto e Vírgula:

❌ v=DMARC1 p=reject rua=mailto:[email protected]
✅ v=DMARC1; p=reject; rua=mailto:[email protected]

Ordem Incorreta de Tags (v deve ser a primeira):

❌ p=reject; v=DMARC1; rua=mailto:[email protected]
✅ v=DMARC1; p=reject; rua=mailto:[email protected]

Valores de Política Inválidos:

❌ p=block
✅ p=reject

❌ p=spam
✅ p=quarantine

Validação de Endereço de E-mail

Endereços Malformados:

❌ [email protected]          # Falta mailto:
✅ rua=mailto:[email protected]

❌ rua=mailto:teste@dominio       # Domínio inválido
✅ rua=mailto:[email protected]

Valores de Porcentagem

Fora do Intervalo:

❌ pct=150    # Acima de 100
✅ pct=100

❌ pct=0      # Zero não permitido
✅ pct=1

VIII. Técnicas de Validação de Registro DMARC

Verificação de Consulta DNS

dig TXT _dmarc.exemplo.com
nslookup -type=TXT _dmarc.exemplo.com

Ferramentas de Validação Online

Use verificadores de registro DMARC para validar sintaxe e detectar erros comuns. Essas ferramentas verificam:

  • Formatação adequada de tags
  • Valores de política válidos
  • Sintaxe de endereço de e-mail
  • Status de propagação DNS

Lista de Verificação para Validação Manual

  1. Tag de versão: Verifique se v=DMARC1 é a primeira
  2. Tag de política: Confirme se p= tem valor válido
  3. Ponto e vírgula: Verifique se todas as tags estão separadas por ponto e vírgula
  4. Formato de e-mail: Valide o prefixo mailto: em endereços de relatórios
  5. Intervalos numéricos: Verifique se pct= está entre 1-100, ri= é número inteiro positivo
  6. Valores de alinhamento: Confirme se adkim= e aspf= usam apenas r ou s

Testando a Implementação DMARC

Após publicar seu registro, monitore os resultados de autenticação através de:

  • Relatórios agregados DMARC
  • Logs de entrega de e-mail
  • Serviços de monitoramento de terceiros

Skysnag Protect simplifica a implementação DMARC fornecendo geração automatizada de registros, validação e monitoramento contínuo para garantir que suas políticas de autenticação de e-mail funcionem corretamente.

IX. Considerações de Configuração Avançada

Organizações Multi-Domínio

Para organizações gerenciando múltiplos domínios, considere:

  • Endereços de relatórios centralizados
  • Níveis consistentes de aplicação de política
  • Herança de política de subdomínio

Integração com Provedor de Serviço de E-mail

Ao usar serviços de e-mail de terceiros:

  • Verifique o alinhamento de assinatura DKIM
  • Coordene inclusões de registro SPF
  • Teste o impacto da aplicação de política

Planejamento de Resposta a Incidentes

Prepare-se para problemas de entrega relacionados ao DMARC:

  • Monitore tendências de relatórios agregados
  • Estabeleça procedimentos de reversão de política
  • Mantenha inventário de remetentes legítimos

X. Principais Conclusões

A sintaxe de registro DMARC requer formatação precisa e consideração cuidadosa do impacto de cada tag na entrega de e-mail. Comece com políticas de monitoramento usando p=none, aplique gradualmente com p=quarantine e p=reject enquanto analisa relatórios agregados. Configure modos de alinhamento apropriados com base na sua infraestrutura de e-mail e sempre valide registros antes da implantação. Lembre-se de que a eficácia do DMARC depende da implementação adequada de SPF e DKIM juntamente com configuração precisa de política.

Compreender essas regras de sintaxe e técnicas de validação permite que as organizações implementem autenticação de e-mail robusta que protege contra spoofing enquanto mantém a entrega legítima de e-mail. Monitoramento regular e refinamento de política garantem eficácia contínua à medida que a infraestrutura de e-mail evolui.