Como levar o DMARC de p=none a p=reject sem quebrar o e-mail

Para levar o DMARC de p=none a p=reject com segurança, primeiro use os relatórios agregados para encontrar toda fonte legítima que envia como o seu domínio e faça cada uma passar em SPF ou DKIM alinhado. Depois passe para quarantine em modo de teste, em seguida quarantine completo e então reject, avançando só quando os relatórios não mostrarem nada legítimo falhando.

A ordem não muda há uma década. O que mudou em maio de 2026 é a ferramenta que a maioria dos guias usa nas etapas intermediárias. O RFC 9989, o novo padrão do DMARC, aposentou a tag pct. A própria página de implantação recomendada do Google, atualizada pela última vez em 1º de outubro de 2026, ainda manda usar pct=5. Este guia funciona com os dois.

Por que p=none não é a linha de chegada

p=none pede aos receptores que não façam nada diferente com o e-mail que falha no DMARC. Ele cumpre o mínimo que Google, Yahoo e Microsoft exigem de remetentes em massa (veja os requisitos do Gmail e do Yahoo para envio em massa) e gera relatórios. Ele não impede ninguém de enviar e-mails que dizem vir do seu domínio.

A maioria das grandes marcas que analisamos já concluiu essa mudança. Quando consultamos com dig a política DMARC publicada de 40 grandes marcas de consumo e B2B em 1º de outubro de 2026, 35 estavam em p=reject, 4 em p=quarantine e 1 em p=none. Essas empresas têm grandes equipes de segurança. Os passos abaixo são o que elas fizeram, em escala menor.

O que mudou: sai pct, entra t

Na especificação anterior, o RFC 7489, pct=10 pedia aos receptores que aplicassem sua política a 10% do e-mail que falhava. O RFC 9989 explica por que isso caiu (Apêndice A.6):

Operational experience showed that the "pct" tag was usually not accurately applied, unless the value specified was either 0 or 100 (the default), and the inaccuracies with other values varied widely from one implementation to another.

(A experiência operacional mostrou que a tag "pct" geralmente não era aplicada com precisão, a menos que o valor fosse 0 ou 100, o padrão, e as imprecisões com outros valores variavam muito de uma implementação para outra.)

A substituta é a tag t, com dois valores. t=y pede aos receptores que não apliquem a política declarada e apliquem "um nível abaixo" dela: p=reject; t=y se comporta como quarantine, e p=quarantine; t=y se comporta como none. t=n (o padrão) significa aplicar a política. O RFC 9989 diz que eles são "análogos" a pct=0 e pct=100.

O problema da transição é que os receptores vão se atualizar em ritmos diferentes. Um receptor no novo padrão ignora pct ("unknown tags MUST be ignored", tags desconhecidas DEVEM ser ignoradas), e um receptor ainda no RFC 7489 ignora t pelo mesmo motivo. Felizmente, os valores de teste antigos e novos concordam. O RFC 7489 diz que, quando um e-mail escapa de uma política reject por causa do pct, o receptor "SHOULD treat the email as though the 'quarantine' policy applies" (DEVERIA tratar o e-mail como se a política "quarantine" se aplicasse). Então, durante a transição, você pode publicar as duas e obter o mesmo comportamento dos dois tipos de receptor:

v=DMARC1; p=reject; t=y; pct=0; rua=mailto:dmarc@example.com

Um receptor RFC 9989 lê t=y e coloca em quarentena. Um receptor RFC 7489 lê pct=0 e coloca em quarentena. Essa combinação é a nossa leitura das duas especificações, não algo que algum dos documentos prescreva, então acompanhe seus relatórios depois de publicá-la.

O que você perde é a rampa de 1%, 5% e 25%. Considerando que o próprio RFC constatou que os receptores aplicavam esses valores de forma inconsistente, você perdia menos do que parecia.

A implantação em etapas

Etapa	Registro	O que os receptores fazem	Avance quando...
0. Monitorar	p=none; rua=...	Nada; enviam relatórios	Toda fonte legítima passa em SPF ou DKIM alinhado por 2 a 4 semanas
1. Quarantine, teste	p=quarantine; t=y; pct=0; rua=...	Tratam como none (novos) ou aplicam a classificação local (antigos)	Nenhuma nova fonte falhando aparece
2. Quarantine	p=quarantine; rua=...	E-mail que falha vai para o spam	2 a 4 semanas sem e-mail legítimo falhando
3. Reject, teste	p=reject; t=y; pct=0; rua=...	Tratam como quarantine	Os relatórios continuam limpos
4. Reject	p=reject; rua=...	Recusam o e-mail que falha	Continue lendo os relatórios

O tempo em cada etapa é uma avaliação, não um padrão. A página do Google sugere uma semana em p=none porque "One week is usually enough time for the daily reports to contain data representative of all your mail streams" (uma semana costuma bastar para que os relatórios diários tragam dados representativos de todos os seus fluxos de e-mail). Nós ficaríamos mais tempo se o seu domínio tiver algo que envia por mês ou por trimestre, como faturas, avisos de folha de pagamento ou renovações anuais. Um remetente que só envia no primeiro dia do mês fica invisível numa janela de uma semana.

Três tags para resolver antes de sair da etapa 0:

• sp define a política dos subdomínios. Se você a omitir, os subdomínios herdam o p. Se algum subdomínio ainda tiver e-mail desalinhado, use sp=none temporariamente em vez de segurar o domínio inteiro.
• np, padronizada no RFC 9989, é uma política para subdomínios que não existem. np=reject impede a falsificação de subdomínios inventados como billing-secure.example.com, e normalmente dá para configurá-la cedo, porque nada legítimo consegue enviar de um nome que não existe.
• rua precisa estar presente em todas as etapas. Sem relatórios, você muda a política às cegas.

Você pode montar qualquer um desses registros com o nosso gerador de DMARC e conferir o que está publicado com o verificador de DMARC.

Como ler relatórios agregados

Os relatórios agregados (rua) são arquivos XML que os receptores enviam, normalmente uma vez por dia. O RFC 9990 define o formato. Um único registro do exemplo do Apêndice B do RFC 9990 fica assim:

<record>
  <row>
    <source_ip>192.0.2.123</source_ip>
    <count>123</count>
    <policy_evaluated>
      <disposition>pass</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <envelope_from>example.com</envelope_from>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim><domain>example.com</domain><result>pass</result><selector>abc123</selector></dkim>
    <spf><domain>example.com</domain><result>fail</result></spf>
  </auth_results>
</record>

Leia assim: 123 mensagens do IP 192.0.2.123 diziam vir de example.com. O DKIM passou e estava alinhado, o SPF falhou e, como o DMARC precisa de apenas um resultado alinhado aprovado, o resultado é pass.

Para cada IP de origem, faça três perguntas:

1. Esse remetente é nosso? Descubra o dono do IP e o DNS reverso. Se for o seu ESP, CRM ou helpdesk, é legítimo. Se for um IP residencial num país onde você não atua, é falsificação, exatamente o que o reject existe para barrar.
2. Se é nosso, passa alinhado? Olhe policy_evaluated. Um pass em dkim ou em spf basta.
3. Se falha, por quê? Compare auth_results com header_from. O padrão mais comum é o dkim passar, mas com o domínio do fornecedor (por exemplo <domain>sendgrid.net</domain>) em vez do seu. Isso é um pass no DKIM, mas não um pass alinhado. A correção é configurar DKIM para o seu próprio domínio dentro desse fornecedor.

O XML bruto dá para ler num domínio pequeno. Acima de alguns remetentes, use um processador de relatórios, mas aprenda antes a ler um registro na mão para poder conferir o que o processador diz.

Os bloqueios de sempre

Sintoma nos relatórios	Causa provável	Correção
Um fornecedor conhecido falha no alinhamento de SPF e de DKIM	O fornecedor assina com o próprio domínio e usa o próprio domínio de bounce	Configure DKIM personalizado (e return-path personalizado, se houver) para o seu domínio
O SPF mostra permerror	Registro com mais de 10 consultas DNS	Veja como corrigir consultas SPF em excesso
O DKIM falha só em algumas mensagens de uma fonte conhecida	Uma lista de e-mail ou um gateway modificando a mensagem, ou um rodapé adicionado depois da assinatura	Assine depois da última modificação; verifique o gateway
Pequenos volumes falhando a partir de muitos IPs sem relação, com o seu header_from	Encaminhamento (o SPF quebra) ou falsificação	Se o DKIM passa, é encaminhamento e vai sobreviver. Se os dois falham a partir de IPs aleatórios, é falsificação
Falha um subdomínio que você esqueceu que existia	Sistema antigo ainda enviando	Corrija ou use sp=none enquanto corrige

Quando parar no quarantine

O reject é o certo para a maioria dos domínios, mas não automaticamente. Fique no quarantine se uma parte relevante do seu e-mail legítimo é encaminhada por sistemas que o modificam e você não consegue fazer o DKIM sobreviver. O e-mail em quarentena ainda pode ser encontrado numa pasta de spam, enquanto o e-mail recusado some. O BIMI aceita quarantine ou reject, então você não precisa de reject para o logo.

A conclusão prática

Publique hoje p=none com um endereço rua, se ainda não fez isso, e leia os relatórios até conseguir nomear toda fonte de envio. Depois avance por quarantine até reject, usando t=y com pct=0 como etapa de teste para que receptores antigos e novos se comportem do mesmo jeito. Deixe o rua ligado para sempre. É pelos relatórios que você vai descobrir quando alguém do marketing assinar uma ferramenta nova que envia como o seu domínio.