DMARC (Domain-based Message Authentication, Reporting and Conformance) serve como a pedra angular da autenticação de email, protegendo organizações contra ataques sofisticados de phishing e spoofing que custam às empresas mais de $12 bilhões anualmente. Compreender a sintaxe precisa e as opções de configuração é essencial para implementar políticas eficazes de segurança de email que protegem a reputação do seu domínio.

Um registro DMARC adequadamente configurado atua como um conjunto de instruções de política publicado no seu DNS, informando aos servidores de email receptores como lidar com emails que falham nas verificações de autenticação. Este guia abrangente decompõe todos os componentes da sintaxe DMARC, fornecendo a profundidade técnica necessária para configurar proteção robusta de email.

Compreendendo a Estrutura do Registro DMARC

Os registros DMARC seguem um formato específico de tag-valor publicado como registros TXT no DNS. O registro deve ser colocado no subdomínio _dmarc sob seu domínio principal, criando a entrada DNS completa _dmarc.seudominio.com.

Formato Básico do Registro DMARC

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

Todo registro DMARC começa com a tag de versão e inclui instruções de política. O ponto e vírgula separa cada par tag-valor, e o espaçamento após os pontos e vírgulas é opcional, mas recomendado para legibilidade.

Tags Obrigatórias vs Opcionais

Os registros DMARC contêm tags obrigatórias e opcionais:

Tags Obrigatórias:

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

Tags Opcionais:

• rua (URI de relatórios agregados)
• ruf (URI de relatórios forenses)
• fo (opções forenses)
• aspf (modo de alinhamento ASPF)
• adkim (modo de alinhamento ADKIM)
• pct (percentual)
• rf (formato de relatório)
• ri (intervalo de relatório)
• sp (política de subdomínio)

Referência Completa de Tags DMARC

Tag de Versão (v)

Sintaxe: v=DMARC1

A tag de versão identifica a versão da especificação DMARC e deve sempre ser a primeira tag no registro. Atualmente, DMARC1 é o único valor válido.

Exemplo:

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

Validação: A tag de versão é sensível a maiúsculas/minúsculas e deve aparecer exatamente como mostrado. Qualquer desvio causará invalidez de todo o registro DMARC.

Tag de Política (p)

Sintaxe: p=none|quarantine|reject

A tag de política especifica a ação que os servidores de email receptores devem tomar quando mensagens falham nas verificações de alinhamento DMARC.

Opções de Política:

• none: Modo de monitoramento, nenhuma ação tomada em mensagens falhadas
• quarantine: Mensagens falhadas entregues na pasta de spam/lixo
• reject: Mensagens falhadas rejeitadas no nível SMTP

Exemplos:

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

Melhores Práticas: Comece com p=none para monitorar padrões de tráfego, depois mova gradualmente para p=quarantine e finalmente p=reject para proteção máxima.

URI de Relatórios Agregados (rua)

Sintaxe: rua=mailto:[email protected] ou rua=https://exemplo.com/dmarc

O URI de relatórios agregados especifica onde os relatórios agregados XML devem ser enviados. Esses relatórios contêm dados estatísticos sobre resultados de autenticação de mensagens.

Exemplos:

rua=mailto:[email protected]
rua=mailto:[email protected],mailto:[email protected]
rua=https://coletor-dmarc.exemplo.com/relatorios

Múltiplos Destinatários: Separe múltiplos URIs com vírgulas. Cada destinatário receberá cópias dos relatórios agregados.

Destinatários Externos: Ao enviar relatórios para domínios externos, o domínio receptor deve publicar um registro DMARC autorizando a aceitação de relatórios.

URI de Relatórios Forenses (ruf)

Sintaxe: ruf=mailto:[email protected]

Os relatórios forenses fornecem informações detalhadas sobre falhas de mensagens individuais, incluindo cabeçalhos de mensagem e resultados de autenticação.

Exemplos:

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

Considerações de Privacidade: Relatórios forenses contêm conteúdo sensível de mensagens. Garanta o manuseio adequado de dados e conformidade com privacidade ao configurar esta tag.

Opções Forenses (fo)

Sintaxe: fo=0|1|d|s

A tag de opções forenses controla quando relatórios forenses são gerados para mensagens falhadas.

Opções:

• 0: Gerar relatórios quando tanto SPF quanto DKIM falham (padrão)
• 1: Gerar relatórios quando SPF ou DKIM falham
• d: Gerar relatórios quando DKIM falha
• s: Gerar relatórios quando SPF falha

Exemplos:

fo=1; ruf=mailto:[email protected]
fo=d:s; ruf=mailto:[email protected]

Tags de Modo de Alinhamento

Modo de Alinhamento SPF (aspf)

Sintaxe: aspf=r|s

Controla a rigidez da verificação de alinhamento SPF:

• r: Modo relaxado (padrão) – permite alinhamento de subdomínio
• s: Modo rigoroso – requer correspondência exata de domínio

Modo de Alinhamento DKIM (adkim)

Sintaxe: adkim=r|s

Controla a rigidez da verificação de alinhamento DKIM:

• r: Modo relaxado (padrão) – permite alinhamento de subdomínio
• s: Modo rigoroso – requer correspondência exata de domínio

Exemplos:

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

Tag de Percentual (pct)

Sintaxe: pct=1-100

Especifica o percentual de mensagens sujeitas à aplicação da política. Útil para implementação gradual de política.

Exemplos:

v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]
v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]

Padrão: Se omitido, padrão é 100 (todas as mensagens sujeitas à política).

Formato de Relatório (rf)

Sintaxe: rf=afrf|iodef

Especifica o formato para relatórios forenses:

• afrf: Authentication Failure Reporting Format (padrão)
• iodef: Incident Object Description Exchange Format

Intervalo de Relatório (ri)

Sintaxe: ri=segundos

Especifica o intervalo entre relatórios agregados em segundos. A maioria dos sistemas receptores ignora esta tag e envia relatórios diários.

Exemplo:

ri=86400  // 24 horas em segundos

Política de Subdomínio (sp)

Sintaxe: sp=none|quarantine|reject

Define política para subdomínios quando não existe registro DMARC explícito para o subdomínio.

Exemplos:

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

Exemplos de Configuração Avançada

Configuração Básica de Monitoramento

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

Política Rigorosa com Implementação Gradual

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

Configuração de Proteção Máxima

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

Configuração Empresarial Multi-Destinatário

v=DMARC1; p=quarantine; rua=mailto:[email protected],mailto:[email protected]; ruf=mailto:[email protected]; pct=50; fo=1

Ferramentas de Validação e Teste

Validação de Consulta DNS

Use estes comandos para verificar a publicação do registro DMARC:

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

Validação de Sintaxe

Ferramentas como Skysnag Protect fornecem validação abrangente de registro DMARC, verificando erros de sintaxe, conflitos de política e recomendações de configuração.

Erros de Validação Comuns

1. Tag de versão ausente: Registro deve começar com v=DMARC1
2. Valores de política inválidos: Apenas none, quarantine e reject são válidos
3. Endereços de email malformados: URIs devem seguir o formato adequado mailto:
4. Modos de alinhamento conflitantes: Garanta consistência entre modos rigoroso e relaxado
5. Valores de percentual inválidos: Devem ser inteiros entre 1-100

Casos Especiais e Resolução de Problemas

Múltiplos Registros DMARC

Apenas um registro DMARC por domínio é permitido. Múltiplos registros resultam em falha DMARC para todas as mensagens.

Herança de Subdomínio

Subdomínios sem registros DMARC explícitos herdam a política do domínio organizacional ou o valor da tag sp se especificado.

Limitações de Comprimento de Registro

Registros DNS TXT têm limite de 255 caracteres por string. Registros DMARC longos podem exigir concatenação de strings:

"v=DMARC1; p=quarantine; rua=mailto:endereco-email-muito-longo@" "dominio-exemplo-com-nome-longo.com; fo=1"

Problemas de Entrega de Relatório

Destinos de relatório externos requerem autorização DNS adequada. Verifique se o domínio receptor aceita relatórios do seu domínio.

Melhores Práticas de Implementação

Estratégia de Implementação Gradual

1. Fase 1: Implemente p=none com relatórios para estabelecer linha de base
2. Fase 2: Mova para p=quarantine com baixo percentual
3. Fase 3: Aumente o percentual gradualmente enquanto monitora relatórios
4. Fase 4: Implemente p=reject para proteção completa

Monitoramento e Manutenção

A análise regular de relatórios DMARC revela problemas de autenticação, fontes de envio não autorizadas e ameaças potenciais de segurança. Ferramentas como Skysnag Protect automatizam o processamento de relatórios e fornecem insights acionáveis para otimização de política.

Integração com SPF e DKIM

DMARC requer que SPF ou DKIM sejam aprovados na autenticação, com alinhamento adequado. Garanta que ambos os protocolos estejam corretamente configurados antes de implementar políticas DMARC rigorosas.

Principais Conclusões

A sintaxe do registro DMARC segue um formato tag-valor preciso com requisitos específicos de validação. Comece com políticas de monitoramento e aumente gradualmente os níveis de proteção enquanto analisa relatórios agregados. A configuração adequada do modo de alinhamento e implementações baseadas em percentual garantem implantação suave sem interrupção de emails legítimos.

Compreender cada tag DMARC permite que organizações implementem políticas sofisticadas de autenticação de email adaptadas aos seus requisitos específicos de segurança. Validação e monitoramento regulares garantem proteção contínua contra ameaças de email em evolução.

Para gerenciamento abrangente de DMARC e otimização automatizada de política, explore Skysnag Protect para agilizar sua implementação de autenticação de email.