# 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.

Fonte: https://couryo.com/blog/dmarc-p-none-ate-p-reject · Publicado em 2026-10-20

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](https://support.google.com/a/answer/81126)); a Microsoft pede pelo menos `p=none` no Outlook.com ([anúncio de 2025](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730)). Subir para `reject` é proteção, não exigência deles.

## As tags que importam

```text title="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](https://www.rfc-editor.org/rfc/rfc9989), 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](https://knowledge.workspace.google.com/admin/security/recommended-dmarc-rollout) 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](https://www.rfc-editor.org/rfc/rfc9990):

```text title="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.**

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

```text title="Quarentena valendo"
v=DMARC1; p=quarantine; rua=mailto:dmarc@exemplo.com.br
```

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

```text title="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](https://couryo.com/docs/deliverability.md#relatorios-dmarc) e [Domínios e DNS](https://couryo.com/docs/domains.md).

## 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](https://couryo.com/guias/email-caindo-no-spam.md).

### 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.