Bit Happens Bits happen. Fix them before shit happens.
PT
MENU
EMAIL // DMARC // SPF // DKIM

DMARC: diferença entre p=none, quarantine e reject

Entenda as políticas DMARC p=none, quarantine e reject, como o alinhamento funciona e como evoluir a política sem bloquear remetentes legítimos.

Atualizado em 2026-09-25Leitura prática
VER EMAIL HEALTH →

DMARC depende de alinhamento

DMARC não substitui SPF ou DKIM. Ele verifica se pelo menos um desses mecanismos passou com alinhamento em relação ao domínio visível no campo From da mensagem.

Isso significa que um SPF tecnicamente válido para um domínio de envelope diferente pode não satisfazer DMARC. O mesmo princípio vale para DKIM: a assinatura precisa estar alinhada ao domínio usado pelo remetente visível, de acordo com o modo configurado.

p=none: observar sem pedir bloqueio

Com p=none, o domínio publica DMARC e pode receber relatórios, mas não pede aos destinatários que coloquem em quarentena ou rejeitem mensagens que falham.

É um ponto de partida útil para inventariar serviços legítimos de envio. O risco aparece quando o domínio permanece indefinidamente em monitoramento sem que os fluxos sejam corrigidos e a política evolua.

p=quarantine: tratar falhas como suspeitas

p=quarantine solicita aos destinatários que tratem mensagens que falham DMARC como suspeitas, normalmente encaminhando-as para spam ou aplicando controles equivalentes.

Antes de adotar essa política, valide plataformas de marketing, sistemas transacionais, help desks, gateways e qualquer serviço que envie usando o domínio no campo From.

p=reject: pedir rejeição de mensagens que falham

p=reject é a política mais restritiva. Ela solicita que mensagens sem autenticação e alinhamento adequados sejam rejeitadas.

Essa configuração reduz a capacidade de terceiros enviarem mensagens simples de spoofing usando o domínio visível, mas exige que os remetentes legítimos estejam corretamente configurados.

Como evoluir a política com menor risco

  1. publique DMARC e receba relatórios agregados;
  2. identifique todas as fontes legítimas de envio;
  3. corrija SPF e/ou DKIM para garantir alinhamento;
  4. valide o resultado em mensagens reais;
  5. avance gradualmente para quarantine e depois reject conforme a evidência permitir.

Use o Email Health para revisar os registros públicos e o Email Header Analyzer para conferir autenticação em uma mensagem recebida.

IMPORTANTE //

O registro DNS mostra a política publicada; o cabeçalho de uma mensagem real mostra o que aconteceu naquele fluxo específico. Use as duas evidências juntas.