Pular para o conteúdo
couryo

Blog

DMARC: de p=none até p=reject sem perder e-mail

O que p=none, p=quarantine e p=reject fazem, as tags sp, np, pct e t, como ler o relatório agregado e quando subir a política sem sumir com e-mail legítimo.

Entregabilidade7 min de leitura

Ver em Markdown

Alguém do time leu que p=reject protege a marca, trocou o DMARC numa sexta-feira e, na segunda, a nota fiscal do ERP parou de chegar aos clientes. Ninguém associou uma coisa à outra por dias. O DMARC é a melhor proteção contra quem finge ser o seu domínio, mas subir a política sem olhar os relatórios derruba e-mail legítimo junto. Este guia mostra o caminho seguro, com o que dizem as regras atuais.

O que cada política faz#

O DMARC é um registro TXT em _dmarc.seudominio.com.br. Ele confere se a mensagem passou no SPF ou no DKIM com o domínio alinhado ao From e diz ao provedor o que fazer quando não passou:

Política O que acontece com quem falha Para que serve
p=none nada; a mensagem segue o caminho normal observar e receber relatórios
p=quarantine a mensagem é tratada como suspeita, em geral vai para o spam fase intermediária, ainda recuperável
p=reject a mensagem é recusada na entrada proteção completa contra falsificação

Dois pontos que confundem:

  • O DMARC não olha o conteúdo. Ele só responde "esta mensagem é mesmo do domínio do From?". Um e-mail legítimo e bem autenticado pode cair no spam por outros motivos; um e-mail falso com p=none pode chegar.
  • p=none já conta. O Gmail e o Yahoo exigem DMARC de quem envia mais de 5 mil por dia, e p=none é aceito (regras do Gmail); a Microsoft pede pelo menos p=none no Outlook.com (anúncio de 2025). Subir para reject é proteção, não exigência deles.

As tags que importam#

TXT em _dmarc.exemplo.com.br
v=DMARC1; p=none; rua=mailto:dmarc@exemplo.com.br; adkim=r; aspf=r
Tag O que faz
p a política do domínio: none, quarantine ou reject
rua para onde os provedores mandam os relatórios agregados (XML, em geral um por dia)
sp a política para subdomínios que existem (loja.exemplo.com.br); sem ela, vale o p
np a política para subdomínios que não existem (qualquercoisa.exemplo.com.br); sem ela, vale o sp ou o p
adkim, aspf alinhamento: r (relaxado, subdomínio conta como o mesmo domínio) ou s (estrito, só o nome exato)
pct aplicava a política a só uma parte das mensagens; saiu da especificação em 2026 (veja abaixo)
t t=y pede ao provedor que aplique um nível abaixo do publicado, para testar; o padrão é t=n

O que mudou em 2026: pct saiu, t entrou#

Em maio de 2026, o DMARC ganhou uma especificação na trilha de padrões da IETF, o RFC 9989, que substitui o RFC 7489 (que era só informativo). Duas mudanças afetam a subida de política:

  • A tag pct foi removida. O próprio RFC explica que, na prática, valores diferentes de 0 e 100 nunca foram aplicados de forma precisa, e cada provedor fazia de um jeito.
  • Entrou a tag t (de teste). Com t=y, o provedor aplica um nível abaixo: p=quarantine; t=y é tratado como none e p=reject; t=y como quarantine. É o equivalente ao antigo pct=0.

Os provedores levam tempo para mudar, e o guia de implantação do Google ainda mostra exemplos com pct (verificado em 20/10/2026). Como a especificação manda ignorar tags desconhecidas, acrescentar t=y não quebra nada em quem ainda não o conhece. Não conte com pct=10 para aplicar a política a exatamente 10% das mensagens.

Como ler um relatório agregado#

Os relatórios chegam no endereço do rua, em XML (às vezes compactado). Um trecho, no formato do RFC 9990:

Relatório agregado (trecho)
<policy_published>
  <domain>exemplo.com.br</domain>
  <p>none</p>
</policy_published>
<record>
  <row>
    <source_ip>203.0.113.25</source_ip>
    <count>1840</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>exemplo.com.br</header_from>
  </identifiers>
  <auth_results>
    <dkim><domain>exemplo.com.br</domain><selector>s1</selector><result>pass</result></dkim>
    <spf><domain>bounces.exemplo.com.br</domain><result>pass</result></spf>
  </auth_results>
</record>
<record>
  <row>
    <source_ip>198.51.100.7</source_ip>
    <count>212</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>exemplo.com.br</header_from>
  </identifiers>
  <auth_results>
    <spf><domain>servidor.erp-exemplo.com</domain><result>pass</result></spf>
  </auth_results>
</record>

Como ler:

  • source_ip e count: de qual servidor vieram e quantas mensagens.
  • policy_evaluated: o resultado alinhado, que é o que o DMARC usa. dkim ou spf com pass aqui quer dizer que passou e estava alinhado ao From.
  • auth_results: o resultado cru, com o domínio que assinou ou o domínio do envelope.
  • disposition: o que o provedor fez com a mensagem. Com p=none, nada é bloqueado.

No exemplo, o primeiro bloco é o seu serviço de envio, certinho. O segundo é o problema clássico: 212 mensagens de um ERP, com SPF passando para o domínio do ERP (servidor.erp-exemplo.com), não para o seu, e sem DKIM. Para o DMARC, isso é falha. Com p=reject, essas 212 notas fiscais seriam recusadas.

Ler XML todo dia à mão não é viável. Use uma ferramenta que junte os relatórios por fonte e mostre quem falha.

Passo a passo da subida#

1. Inventário. Liste tudo que manda e-mail com o seu domínio no From: e-mail da empresa (Google Workspace, Microsoft 365), sistema ou app, loja, ERP e nota fiscal, gateway de cobrança, CRM, central de atendimento, ferramenta de marketing. Cada um precisa de DKIM com o seu domínio ou de envelope num domínio seu.

2. p=none com rua. Publique e deixe coletando. O Google sugere no mínimo uma semana; se você tem envios mensais (cobrança, nota fiscal, relatório do mês), espere um ciclo inteiro para eles aparecerem nos relatórios.

3. Corrija cada fonte que falha. Para cada IP com fail em policy_evaluated: descubra de quem é, configure DKIM com o seu domínio no serviço ou mova o envelope para um subdomínio seu. Fonte que você não reconhece pode ser golpe: é justamente o que o reject vai barrar.

4. p=quarantine em teste, depois de verdade.

Teste (aplica none onde o RFC 9989 já vale)
v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@exemplo.com.br
Quarentena valendo
v=DMARC1; p=quarantine; rua=mailto:dmarc@exemplo.com.br

5. p=reject. Quando a quarentena rodar sem fonte legítima falhando:

Rejeição
v=DMARC1; p=reject; rua=mailto:dmarc@exemplo.com.br

Quando subir#

Suba de nível quando, no período inteiro de observação:

  • todas as fontes legítimas aparecem com pass alinhado;
  • as falhas que restam vêm de fontes que você não reconhece (falsificação) ou de encaminhamentos;
  • nenhum serviço novo entrou no período sem DKIM configurado;
  • você sabe voltar atrás rápido (veja abaixo).

Encaminhamentos: quando alguém encaminha o seu e-mail, o SPF quebra, porque o servidor que reenvia não está no seu SPF. O DKIM costuma sobreviver. Por isso, todo serviço legítimo deveria passar pelo DKIM alinhado, não só pelo SPF. A Microsoft também cita o ARC como o mecanismo que preserva a autenticação em encaminhamentos e listas.

Subdomínios#

  • Sem sp, os subdomínios herdam o p. Se você sobe o domínio principal para reject, loja.exemplo.com.br também vai para reject, a menos que tenha o próprio registro _dmarc.
  • Subdomínio com registro próprio manda nele mesmo. _dmarc.marketing.exemplo.com.br vale para marketing.exemplo.com.br, e o sp publicado num subdomínio é ignorado.
  • Suba os subdomínios em separado quando cada um tem um serviço diferente. Um caminho comum: p=reject; sp=quarantine enquanto os subdomínios ainda estão em observação.
  • Use np=reject para que nomes inventados (seguranca-banco.exemplo.com.br) não sejam usados em golpes.
  • Domínio que não envia e-mail (o .com que só redireciona para o .com.br): publique v=spf1 -all e v=DMARC1; p=reject; direto.

Como voltar atrás se algo sumir#

Se um e-mail legítimo parou depois da subida, volte a política um nível (de reject para quarantine, ou para p=none) e corrija a fonte. A mudança só vale para todos depois que o TTL do registro expira; por isso, um TTL curto no _dmarc (alguns minutos) ajuda na fase de subida. Mensagens já recusadas não voltam: o remetente precisa reenviar.

Onde o Couryo entra#

No Couryo, o DMARC de cada domínio começa em p=none com rua=mailto:reports@dmarc.couryo.com, e o Couryo lê cada relatório (XML, zip ou gzip). Na aba DMARC do domínio aparecem as fontes de envio, quantas mensagens cada uma mandou e se passaram no SPF, no DKIM e no DMARC, com o aviso "alguém está enviando em seu nome sem autenticar" quando uma fonte falha. O agente de entregabilidade só recomenda subir quando o domínio está há 30 dias com a política atual, pelo menos 99% das mensagens passaram no DMARC e nenhuma fonte falhou, e entrega o registro novo pronto para copiar. Quem troca o registro é você: o agente lê e recomenda, não muda o seu DNS. Veja Agente de entregabilidade e Domínios e DNS.

Perguntas frequentes#

Quanto tempo devo ficar em p=none?#

O Google sugere no mínimo uma semana de relatórios. Na prática, espere pelo menos um ciclo completo dos seus envios: se a cobrança ou a nota fiscal sai uma vez por mês, ela só aparece nos relatórios depois do primeiro envio. O agente do Couryo pede 30 dias limpos antes de recomendar a subida.

p=quarantine manda tudo para o spam?#

Não. Só as mensagens que falham no DMARC (sem SPF nem DKIM alinhados). Mensagens legítimas e autenticadas seguem o caminho normal. O risco está nas fontes legítimas que você ainda não configurou, e é por isso que os relatórios vêm antes.

Ainda posso usar pct=25 para subir aos poucos?#

Pode publicar, mas não conte com ele. O RFC 9989, de 2026, removeu o pct porque valores diferentes de 0 e 100 nunca foram aplicados de forma consistente. Para testar uma política sem aplicar de verdade, use t=y; para subir de fato, passe de um nível para o outro.

O DMARC sozinho evita que o meu e-mail caia no spam?#

Não. Ele prova que a mensagem é do seu domínio, o que os grandes provedores exigem e que ajuda na reputação. Mas reclamações, lista ruim e conteúdo com cara de golpe continuam levando ao spam. Veja E-mail caindo no spam.

Preciso de p=reject para cumprir as regras do Gmail e da Microsoft?#

Não. Gmail, Yahoo e Microsoft aceitam p=none para quem envia em volume. O p=reject é para proteger o seu domínio de falsificação, e vale a pena chegar lá com calma.