DMARC explicado: a política que amarra SPF e DKIM

SPF e DKIM apenas validam a origem e a integridade. Quem decide o que fazer quando a validação falha é o DMARC. Este guia mostra como sair do p=none com segurança e chegar em p=reject sem quebrar seu envio.

O que o DMARC resolve

Antes do DMARC, cada provedor decidia por conta própria o que fazer com e-mails que falhavam em SPF ou DKIM — alguns marcavam como spam, outros rejeitavam, outros aceitavam normalmente. O resultado era caótico e imprevisível.

DMARC deu ao dono do domínio o controle. Você publica no DNS uma política dizendo: "se um e-mail falhar SPF e DKIM em meu nome, faça X". Provedores que seguem DMARC (todos os grandes) obedecem.

Publicando o DMARC

Um registro mínimo mas útil:

Tipo:  TXT
Nome:  _dmarc
Valor: v=DMARC1; p=none; rua=mailto:dmarc@seudominio.com; aspf=r; adkim=r

Os parâmetros que importam de verdade:

• v=DMARC1 — versão.
• p= — política: none, quarantine ou reject.
• rua= — endereço que recebe os relatórios agregados (diários).
• ruf= — endereço que recebe relatórios forenses (por mensagem; poucos provedores ainda enviam).
• aspf= e adkim= — alinhamento estrito (s) ou relaxado (r). Comece com r.
• pct= — percentual de mensagens a que a política se aplica (útil para ramp-up).

Os três estágios de maturidade

Estágio 1: p=none

Modo observação. DMARC não faz nada com as mensagens — apenas pede aos provedores que enviem relatórios para o seu rua. Fique aqui por no mínimo 2 semanas. Durante esse tempo, os relatórios vão revelar todos os sistemas que enviam em seu nome — muitos você nem sabia que existiam (ex.: sistema antigo de RH, integração de CRM, formulário do site).

Estágio 2: p=quarantine

Depois de autorizar todos os remetentes legítimos no SPF e DKIM, avance para p=quarantine. Agora mensagens que falharem vão para a caixa de spam do destinatário em vez de ser entregues normalmente.

Use pct=25 inicialmente para aplicar só a 25% das mensagens, monitore por alguns dias, aumente para 50%, depois 100%.

Estágio 3: p=reject

Política completa. Qualquer mensagem que falhar SPF e DKIM em seu nome será rejeitada pelo provedor receptor, sem cair sequer no spam.

Chegar aqui é obrigatório para quem envia em volume: Google e Yahoo exigem p=quarantine ou p=reject para bulk senders desde 2024.

Alinhamento: o detalhe que quebra tudo

DMARC exige que o domínio do cabeçalho From: (o que o usuário vê) alinhe com o domínio que passou no SPF ou no DKIM.

Exemplo do problema clássico:

• O From: diz contato@seudominio.com.
• O SPF valida, mas pelo envelope (Return-Path), que é bounce@mailgun.org.
• Como os domínios não alinham, DMARC considera o e-mail inválido — mesmo com SPF passando.

Solução: configure o provedor de envio para usar um subdomínio seu no envelope (ex.: bounce.seudominio.com) ou confie no DKIM alinhado, que é mais comum.

Lendo os relatórios

Os relatórios vêm como XML compactado, um por provedor por dia. Abrir manualmente é inviável — use uma ferramenta que agrupa por fonte de envio. Cada linha do relatório mostra:

• IP que enviou.
• Volume do dia.
• Se SPF e DKIM passaram.
• Se houve alinhamento.
• Qual política foi aplicada.

Olhe semanalmente. Surpresas aparecem: serviços esquecidos, domínios em uso por terceiros, até tentativas de spoofing reais.

Testando o DMARC do seu domínio

O MailTester RapidCloud mostra o resultado do DMARC de cada mensagem enviada — você vê em tempo real se a política está sendo aplicada e se o alinhamento bateu.

Checklist rápido antes de p=reject: todos os remetentes listados nos relatórios passam SPF e DKIM alinhados? Se sim, pode subir. Se algum serviço legítimo ainda falha, resolva primeiro.