DMARC quarantine ou reject: qual política usar (e quando mudar)

Um registro DMARC sem uma política ativa é como uma câmera de segurança que não grava. A tag p= é onde o DMARC começa de fato a proteger o seu domínio, e a escolha entre quarantine e reject pesa mais do que a maioria dos remetentes imagina.

Este guia explica o que cada política faz, quando usar cada uma e o caminho mais seguro de p=none até uma política ativa.

As três políticas DMARC

O DMARC aceita três valores para a tag p=:

Política	O que acontece com o e-mail que falha no DMARC	Quando usar
p=none	Entregue normalmente; reportado a você	Dia 1 (só visibilidade)
p=quarantine	Entregue na pasta de spam	Fase de transição
p=reject	Devolvido (não entregue)	Estado final: proteção total

A tag pct= da RFC 7489 permite aplicar a política a uma porcentagem dos e-mails. Por exemplo, p=quarantine; pct=25 pede aos destinatários que coloquem em quarentena 25% dos e-mails que falham e deixem passar o resto. O padrão atual, a RFC 9989 (maio de 2026), elimina o pct e mantém só o uso para testes, como t=y, então trate as porcentagens como um pedido que muitos servidores aplicam com pouco rigor.

O que o p=quarantine faz de verdade

O e-mail que falha no DMARC é entregue na pasta de spam do destinatário. O destinatário ainda consegue encontrar e recuperar a mensagem, o que ajuda enquanto você ainda está descobrindo remetentes legítimos que não estão alinhados.

Pontos fortes:

• Impede que a maior parte dos e-mails falsificados chegue à caixa de entrada.
• Revela falhas de alinhamento sem devolver e-mails reais.
• Risco baixo de prejudicar e-mails legítimos durante a transição.

Pontos fracos:

• Alguns provedores tratam a quarentena de forma inconsistente (a Microsoft é mais rígida que o Gmail).
• Não impede o destinatário de resgatar manualmente um e-mail falsificado.
• Dá só uma proteção parcial à marca.

O que o p=reject faz de verdade

O e-mail que falha no DMARC é recusado de vez pelo servidor do destinatário. Ele não cai em lugar nenhum. O remetente recebe um bounce.

Pontos fortes:

• A proteção mais forte possível contra falsificação.
• Elegibilidade para o BIMI (exibição do logo nos clientes de e-mail compatíveis).
• Deixa você alinhado com as recomendações do Gmail e do Yahoo para remetentes em massa.

Pontos fracos:

• Qualquer remetente legítimo mal alinhado some sem aviso.
• Erros de configuração fazem e-mails reais de clientes voltarem.
• Exige que todo remetente de shadow IT seja descoberto e alinhado antes.

Quando escolher cada uma

Use esta árvore de decisão:

• Você acabou de publicar o DMARC → p=none com relatórios rua. Fique aqui até os relatórios agregados mostrarem 99% ou mais dos e-mails legítimos alinhados.
• Os relatórios agregados mostram >99% de alinhamento dos remetentes legítimos, com alguns desconhecidos → p=quarantine; pct=10. Analise toda semana e aumente o pct aos poucos.
• Os relatórios agregados mostram 100% de alinhamento dos e-mails legítimos, sem preocupação com falsificação → p=quarantine; pct=100.
• Você quer a proteção máxima E todos os remetentes legítimos estão comprovadamente alinhados → p=reject; pct=100.
• Você é um banco, uma empresa de saúde, um órgão de governo ou qualquer marca falsificada com frequência → vá para p=reject sem demora. O risco de dano por falsificação é maior que o risco de erro de configuração.

O caminho seguro de p=none até p=reject

O cronograma padrão que evita desastres:

Semana	Política	O que fazer
1-4	p=none	Publique o registro, analise os relatórios agregados, identifique todos os remetentes
5-6	p=none	Alinhe os remetentes não alinhados (domínios próprios, CNAMEs do ESP)
7-8	p=quarantine; pct=10	Monitore, corrija qualquer falha nova
9-10	p=quarantine; pct=50	O mesmo
11-12	p=quarantine; pct=100	O mesmo
13-16	p=reject; pct=10, depois 50, depois 100	Rampa final

Total: uns 4 meses entre publicar o DMARC e chegar a p=reject completo. Dá para ir mais rápido, mas o risco de perder e-mails legítimos aumenta.

O que os relatórios agregados mostram

Os relatórios agregados rua do DMARC chegam todo dia como anexos XML de cada provedor destinatário. Eles mostram:

• Quais IPs enviaram e-mails dizendo ser do seu domínio.
• Quantas mensagens alinharam com SPF, com DKIM, com os dois ou com nenhum.
• Que tratamento o destinatário aplicou (none/quarantine/reject).

Transforme esses dados num painel, porque XML bruto é ilegível em escala. O analisador de relatórios DMARC gratuito lê os relatórios que você abre, no seu navegador.

Erros comuns que quebram e-mails reais

• Ir direto para p=reject sem analisar os relatórios agregados. As rodadas de descoberta sempre encontram remetentes legítimos que você esqueceu.
• Esquecer os subdomínios. Um p=reject no domínio raiz também cobre os subdomínios, a menos que uma tag sp= diga o contrário, então um sp=none esquecido isenta todos os subdomínios sem ninguém perceber.
• ESP configurado sem alinhamento. O seu ESP assina o DKIM com o domínio dele por padrão; você precisa configurar um domínio DKIM próprio para ter alinhamento.
• Ferramentas de automação de marketing. Muitas ferramentas SaaS enviam "em nome" do seu domínio via SendGrid/Postmark/etc. Cada uma precisa ser alinhada separadamente.

p=quarantine vs quarentena do filtro de spam

Um ponto que confunde: p=quarantine pede ao servidor destinatário que trate o e-mail que falha como suspeito. O destinatário ainda aplica a própria filtragem de spam por cima. Então um e-mail que falha no DMARC com p=quarantine pode cair no spam ou ser tratado com ainda mais rigor. Os dois filtros se somam.

Perguntas frequentes

É seguro usar p=reject? Sim, depois que você confirmou que todos os remetentes legítimos estão alinhados. O risco está em ativar a política antes de conhecer todos os remetentes.

O que o pct=0 faz? Na prática, vira p=none para e-mails novos. É um truque antigo para testar mudanças de política sem afetar a entrega. A RFC 9989 o substitui por t=y e observa que valores de pct diferentes de 0 e 100 eram aplicados de forma inconsistente de um destinatário para outro.

O p=reject afeta e-mails de listas de discussão? Sim. É a causa mais comum de perda de e-mails legítimos depois de ativar a política. O ARC (Authenticated Received Chain) ajuda as listas de discussão a preservar o alinhamento. A maioria das grandes listas já é compatível com ARC; confira a sua.

A política dos subdomínios deve ser igual à do domínio raiz? Normalmente sim. Defina sp=reject de forma explícita. Se você tem subdomínios sem autenticação, coloque-os em sp=quarantine temporariamente e corrija.

Preciso de DMARC se já tenho SPF e DKIM? Sim. SPF e DKIM verificam mecanismos individuais; só o DMARC exige alinhamento e lhe dá relatórios. O Gmail e o Yahoo exigem DMARC de remetentes em massa.

Resumo

p=none é para aprender. p=quarantine é para a transição. p=reject é para proteger. Pular direto para p=reject é o jeito mais comum de perder e-mails reais de clientes. Invista os quatro meses. Vale a pena fazer a proteção do jeito certo.

👉 Continue lendo: Como corrigir SPF, DKIM e DMARC · Requisitos do Gmail e do Yahoo para remetentes · Experimente o gerador de DMARC

Fontes

• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), o padrão DMARC atual: as políticas p, sp e np, a flag de teste t e por que o pct foi removido.
• RFC 7489: DMARC (2015 informational version), a versão de 2015 que definiu o pct e a regra de que o p vale para os subdomínios quando o sp não existe.
• RFC 8617: The Authenticated Received Chain (ARC) Protocol, como intermediários, por exemplo listas de discussão, repassam resultados de autenticação que, de outra forma, fariam o DMARC falhar.
• Set up DMARC (Google Workspace Help), a recomendação do Google de começar em p=none e avançar para uma política ativa aos poucos, lendo os relatórios.