Os registros DMARC (Domain-based Message Authentication, Reporting and Conformance) servem como políticas baseadas em DNS que informam aos servidores de email receptores como lidar com emails do seu domínio. Compreender a sintaxe precisa dos registros DMARC é crucial para organizações que implementam protocolos robustos de autenticação de email em 2026.

Um registro DMARC consiste em pares tag-valor separados por ponto e vírgula, publicado como um registro TXT no local DNS específico _dmarc.seudominio.com. Cada componente serve uma função distinta na cadeia de autenticação, desde a aplicação de políticas até a configuração de relatórios forenses.

I. Visão Geral da Estrutura do Registro DNS DMARC

Processo de cinco etapas para criar registros DMARC, desde a tag de versão até a publicação no DNS.

Formato de Sintaxe Básica

Os registros DMARC seguem um formato padronizado tag=valor com requisitos específicos de ordenação:

v=DMARC1; p=política; rua=mailto:relatórios@domínio.com; ruf=mailto:forense@domínio.com; sp=política_subdomínio; pct=porcentagem; adkim=alinhamento; aspf=alinhamento; rf=formato; ri=intervalo; fo=opções

Tags Obrigatórias vs Opcionais

Tags Obrigatórias:

  • v (versão)
  • p (política)

Tags Opcionais:

  • rua (relatórios agregados)
  • ruf (relatórios forenses)
  • sp (política de subdomínio)
  • pct (porcentagem)
  • adkim (alinhamento DKIM)
  • aspf (alinhamento SPF)
  • rf (formato de relatório)
  • ri (intervalo de relatório)
  • fo (opções de falha)

II. Tag de Versão (v)

Sintaxe

v=DMARC1

A tag de versão deve sempre ser o primeiro componente em qualquer registro DMARC e atualmente suporta apenas um valor: DMARC1. Isso identifica o registro como uma política DMARC para os servidores de email receptores.

Exemplos

v=DMARC1; p=none
v=DMARC1; p=quarantine; rua=mailto:[email protected]

Casos Especiais

  • A ausência da tag de versão torna todo o registro inválido
  • A tag de versão aparecendo em qualquer lugar exceto na primeira posição causa falhas de análise
  • Qualquer valor diferente de DMARC1 resulta na rejeição do registro

III. Tag de Política (p)

Sintaxe

p=none|quarantine|reject

A tag de política define como os servidores receptores devem lidar com emails que falham nas verificações de autenticação DMARC.

Valores de Política Explicados

none: Modo de monitoramento – nenhuma ação tomada em mensagens que falharam

v=DMARC1; p=none; rua=mailto:relatórios@domínio.com

quarantine: Mensagens que falharam são entregues nas pastas de spam/lixo eletrônico

v=DMARC1; p=quarantine; pct=25; rua=mailto:relatórios@domínio.com

reject: Mensagens que falharam são completamente bloqueadas no nível SMTP

v=DMARC1; p=reject; rua=mailto:relatórios@domínio.com

Casos Especiais

  • A aplicação da política depende da implementação do receptor
  • Alguns receptores podem tratar quarantine como reject por razões de reputação
  • A escalação da política deve seguir padrões de implantação gradual (none → quarantine → reject)

IV. URI de Relatórios Agregados (rua)

Sintaxe

rua=mailto:endereço1@domínio.com,mailto:endereço2@domínio.com

Especifica endereços de email para receber relatórios XML agregados contendo estatísticas de autenticação.

Exemplos de Configuração

Destinatário único:

rua=mailto:relató[email protected]

Múltiplos destinatários:

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

Relatórios de domínio externo:

rua=mailto:[email protected]

Casos Especiais

  • Destinatários de domínios externos requerem registros de autorização DNS
  • Relatórios gerados diariamente pela maioria dos receptores (ciclos de 24 horas)
  • A ausência da tag rua elimina a visibilidade do desempenho DMARC
  • Alguns receptores impõem limites de tamanho nos destinos de relatórios

V. URI de Relatórios Forenses (ruf)

Sintaxe

ruf=mailto:endereço@domínio.com

Define destinatários para relatórios forenses detalhados de falhas individuais de autenticação.

Exemplos

ruf=mailto:[email protected]
v=DMARC1; p=quarantine; ruf=mailto:[email protected],mailto:[email protected]

Casos Especiais

  • Muitos receptores não enviam mais relatórios forenses devido a preocupações de privacidade
  • Relatórios forenses contêm cabeçalhos completos de mensagens e dados potencialmente sensíveis
  • Destinatários de domínios externos requerem autorização DNS explícita
  • O volume pode ser avassalador para domínios com alto tráfego de email

VI. Política de Subdomínio (sp)

Sintaxe

sp=none|quarantine|reject

Estabelece herança de política para subdomínios quando não existe um registro DMARC explícito no nível do subdomínio.

Exemplos de Configuração

Política de subdomínio mais rigorosa:

v=DMARC1; p=none; sp=quarantine; rua=mailto:relató[email protected]

Políticas correspondentes:

v=DMARC1; p=reject; sp=reject; rua=mailto:relató[email protected]

Casos Especiais

  • Registros DMARC específicos de subdomínios substituem as configurações sp
  • O comportamento padrão aplica a política do domínio pai aos subdomínios quando sp está ausente
  • Subdomínios organizacionais podem requerer abordagens de política diferentes

VII. Tag de Porcentagem (pct)

Implantação de DMARC em três fases, do monitoramento à aplicação total com testes de porcentagem.

Sintaxe

pct=1-100

Controla a porcentagem de mensagens que falharam sujeitas à aplicação da política DMARC.

Exemplos

Implementação gradual:

v=DMARC1; p=quarantine; pct=10; rua=mailto:relató[email protected]

Aplicação completa (padrão):

v=DMARC1; p=reject; pct=100; rua=mailto:relató[email protected]

Casos Especiais

  • O valor padrão é 100 quando a tag pct é omitida
  • Útil para implantação e teste gradual de políticas
  • Amostragem aleatória pode criar experiências inconsistentes para usuários
  • Nem todos os receptores honram especificações de porcentagem

VIII. Modo de Alinhamento DKIM (adkim)

Sintaxe

adkim=r|s

Define requisitos de alinhamento entre o domínio da assinatura DKIM e o domínio do cabeçalho From.

Modos de Alinhamento

Relaxado (r) – Padrão:

v=DMARC1; p=quarantine; adkim=r; rua=mailto:relató[email protected]
  • Permite alinhamento de domínio organizacional (subdomínio.exemplo.com alinha com exemplo.com)

Rigoroso (s):

v=DMARC1; p=quarantine; adkim=s; rua=mailto:relató[email protected]
  • Requer correspondência exata de domínio

Casos Especiais

  • O alinhamento relaxado acomoda serviços legítimos de email de subdomínio
  • O alinhamento rigoroso previne spoofing de subdomínio mas pode quebrar fluxos legítimos de email
  • Múltiplas assinaturas DKIM avaliadas independentemente para alinhamento

IX. Modo de Alinhamento SPF (aspf)

Sintaxe

aspf=r|s

Especifica requisitos de alinhamento entre o domínio Return-Path do SPF e o domínio do cabeçalho From.

Exemplos

Alinhamento SPF relaxado:

v=DMARC1; p=none; aspf=r; adkim=s; rua=mailto:relató[email protected]

Alinhamento SPF rigoroso:

v=DMARC1; p=quarantine; aspf=s; rua=mailto:relató[email protected]

Casos Especiais

  • Cenários de encaminhamento frequentemente quebram o alinhamento SPF independentemente do modo
  • Serviços de email de terceiros requerem configuração cuidadosa do Return-Path
  • O modo relaxado acomoda estruturas de domínio organizacionais

X. Formato de Relatório (rf)

Sintaxe

rf=afrf|iodef

Especifica preferência de formato para relatórios forenses.

Opções de Formato

Authentication Failure Report Format (afrf) – Padrão:

v=DMARC1; p=none; rf=afrf; ruf=mailto:[email protected]

Incident Object Description Exchange Format (iodef):

v=DMARC1; p=none; rf=iodef; ruf=mailto:[email protected]

Casos Especiais

  • A maioria dos receptores usa afrf por padrão independentemente da especificação rf
  • O formato iodef raramente é implementado na prática
  • A preferência de formato pode ser ignorada pelos sistemas de relatório

XI. Intervalo de Relatório (ri)

Sintaxe

ri=segundos

Solicita intervalo específico para geração de relatórios agregados.

Exemplos

Relatórios diários (86400 segundos):

v=DMARC1; p=none; ri=86400; rua=mailto:relató[email protected]

Relatórios semanais (604800 segundos):

v=DMARC1; p=none; ri=604800; rua=mailto:relató[email protected]

Casos Especiais

  • A maioria dos receptores gera relatórios em seus próprios cronogramas independentemente do valor ri
  • A prática padrão é geração diária de relatórios
  • Intervalos mais curtos raramente são honrados pelos principais provedores de email

XII. Opções de Falha (fo)

Sintaxe

fo=0|1|d|s

Controla condições que acionam a geração de relatórios forenses.

Opções de Falha Explicadas

fo=0 (Padrão): Relatórios gerados quando tanto SPF quanto DKIM falham

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

fo=1: Relatórios gerados quando SPF ou DKIM falha

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

fo=d: Relatórios gerados quando DKIM falha

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

fo=s: Relatórios gerados quando SPF falha

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

Casos Especiais

  • Múltiplos valores podem ser combinados: fo=1:d:s
  • Relatórios forenses cada vez mais desabilitados pelos receptores
  • Domínios de alto volume devem usar fo=0 para minimizar o volume de relatórios

XIII. Exemplos de Configuração Avançada

Implantação Empresarial

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

Implementação Gradual

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

Política Focada em Subdomínios

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

XIV. Requisitos de Publicação DNS

Os registros DMARC devem ser publicados como registros TXT em _dmarc.seudomínio.com com configuração DNS adequada:

Considerações sobre TTL

  • TTL recomendado: 300-3600 segundos para mudanças de política
  • Valores TTL mais baixos permitem atualizações de política mais rápidas
  • Valores TTL mais altos reduzem a carga de consultas DNS

Limites de Registro

  • Registro DMARC único por domínio (múltiplos registros causam falhas)
  • Comprimento máximo de registro varia por provedor DNS
  • Registros longos podem requerer divisão de registros TXT

XV. Erros Comuns de Sintaxe

Problemas de Espaçamento

# Incorreto - espaços em nomes de tags
v = DMARC1; p = none

# Correto
v=DMARC1; p=none

Sensibilidade a Maiúsculas

# Incorreto - maiúsculas importam para valores
v=dmarc1; p=NONE

# Correto
v=DMARC1; p=none

Problemas de Delimitadores

# Incorreto - vírgula em vez de ponto e vírgula
v=DMARC1, p=none

# Correto
v=DMARC1; p=none

Organizações implementando políticas DMARC se beneficiam ao usar o Skysnag Protect para monitorar desempenho DMARC, validar sintaxe de registros e receber relatórios detalhados de autenticação. A plataforma fornece visibilidade em tempo real do status de autenticação de email e ajuda a identificar problemas de configuração antes que impactem a entrega de emails.

XVI. Principais Conclusões

A sintaxe de registros DMARC requer formatação precisa com tags obrigatórias de versão e política, enquanto tags opcionais fornecem controle de relatórios e alinhamento. A implementação bem-sucedida exige compreender a função de cada componente, publicação DNS adequada e escalação gradual de políticas. O monitoramento regular através de relatórios agregados garante a eficácia da autenticação enquanto relatórios forenses ajudam a identificar padrões específicos de falha.

A configuração adequada do DMARC protege domínios de ataques de spoofing mantendo a entrega legítima de emails quando as regras de sintaxe são seguidas corretamente. As organizações devem começar com políticas de monitoramento, validar a sintaxe completamente e implementar autorização de relatórios externos ao usar serviços DMARC de terceiros.