# DMARC p=none to p=reject: A Safe Rollout Plan

URL: https://email-validation.org/guides/dmarc-none-to-reject/
Updated: 2026-11-06

> Documentation index: https://email-validation.org/llms.txt

To move a domain from `p=none` to `p=reject` safely, publish `p=none` with a reporting address, read the aggregate
reports until every service that legitimately sends as your domain passes DMARC with alignment, then step up to
`p=quarantine` and only after that to `p=reject`. Gmail and Yahoo ask bulk senders for `p=none` at minimum, so
enforcement is not needed to meet their rules; it is what stops other people from sending mail in your domain's name.
The current DMARC standard, RFC 9989 (May 2026), suggests at least a month at `none` and an equally long period at
`quarantine` before `reject` for a domain whose users post to mailing lists, and warns that such domains should
usually not publish `reject` at all.

## What the three policies ask for

The `p` tag states what the domain owner wants done with mail that fails DMARC
([RFC 9989, section 4.7](https://www.rfc-editor.org/info/rfc9989/)):

| Policy | What it asks receivers | What you get |
|---|---|---|
| `p=none` | Nothing: no preference is expressed | Reports, with no change to delivery |
| `p=quarantine` | Treat failing mail as suspicious | At Gmail, failing mail goes to spam |
| `p=reject` | Treat failing mail as not valid | Failing mail can be refused during the SMTP session |

The policy is a request. RFC 9989, section 5.4, leaves the final handling to each receiver, and says a receiver
should not reject mail solely because of `p=reject`. A `p=none` policy must not change how mail is handled at all,
which is why it is safe to publish first.

RFC 9989 replaced [RFC 7489](https://www.rfc-editor.org/info/rfc7489/), the 2015 specification. The version tag is
still `v=DMARC1`, so existing records keep working. The changes that matter for a
rollout are covered below: the `pct` tag is gone, and `t` and `np` are new.

## What Gmail, Yahoo and Microsoft require

None of the three large mailbox providers requires enforcement:

- **Gmail:** senders of more than 5,000 messages a day must set up DMARC, and Google's
  [email sender guidelines](https://support.google.com/mail/answer/81126) say the policy can be `none`. Its
  [sender guidelines FAQ](https://support.google.com/a/answer/14229414) asks for the From: domain to align with the SPF
  or the DKIM domain, recommends aligning with both, and expects that both may become a requirement.
- **Yahoo:** its [sender best practices](https://senders.yahooinc.com/best-practices/) ask bulk senders for a valid
  policy of at least `p=none`, require DMARC to pass, accept relaxed alignment and strongly recommend a `rua`
  reporting address.
- **Microsoft:** the [Outlook.com postmaster policies](https://substrate.office.com/ip-domain-management-snds/postmaster/Policies)
  set `p=none` as the minimum and recommend `p=reject`.

The full rules are in [Gmail and Yahoo sender requirements](https://email-validation.org/guides/gmail-yahoo-sender-requirements/) and
[Outlook sender requirements](https://email-validation.org/guides/outlook-sender-requirements/). Note that "DMARC must pass" applies even at
`p=none`: the providers check alignment whatever your policy says.

## Stage 1: monitor with p=none

Set up SPF and DKIM first; Google's [Set up DMARC](https://knowledge.workspace.google.com/admin/security/set-up-dmarc)
page asks you to wait 48 hours after doing so. Create a mailbox or group only for reports, then publish a monitoring
record at `_dmarc.example.com`:

```text
_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
```

RFC 9989 calls this state Monitoring Mode. Google's
[recommended rollout](https://knowledge.workspace.google.com/admin/security/recommended-dmarc-rollout) suggests about
a week, which is usually enough for the daily reports to cover your mail streams. If some mail goes out only monthly,
such as invoices or statements, wait until you have seen it; RFC 9989, section 5.1.7, notes that reaching
confidence can take many months.

### Build an inventory of senders

Each aggregate report lists the IP addresses that sent mail with your domain in the From: header, with message
counts and SPF and DKIM results. Group them into three lists:

1. **Your own services that pass with alignment.** Nothing to do.
2. **Your own services that fail or pass unaligned.** A newsletter platform, CRM, help desk, billing system,
   website contact form or office printer that uses your domain. These must be fixed before enforcement.
3. **Sources you do not recognize.** Forgeries, or a service someone in your company signed up for. Ask before you
   decide it is abuse.

How to read the XML is covered in [DMARC aggregate reports](https://email-validation.org/guides/dmarc-aggregate-reports/).

## Stage 2: fix SPF and DKIM alignment

DMARC passes when SPF or DKIM passes for a domain that aligns with the From: domain. For SPF, only the envelope
sender (MAIL FROM, the bounce address) counts, not the HELO name; for DKIM it is the `d=` domain of a valid signature
(RFC 9989, section 4.4). Two modes exist, set separately with `aspf` and `adkim`:

| Mode | Tag value | Aligns when | Example with From: `news.example.com` |
|---|---|---|---|
| Relaxed (default) | `r` | Both share the same organizational domain | `d=mail.example.com` aligns |
| Strict | `s` | Both are identical | Only `d=news.example.com` aligns |

RFC 9989 says nearly all domain owners find relaxed alignment sufficient, and Google says the same. Google also
warns that strict alignment can send mail from your own subdomains to spam or get it rejected. Keep the defaults
unless you have a reason, such as subdomains run by other parties.

The usual fixes for a failing service:

- **DKIM:** let the platform sign with a key in your domain, often a CNAME or TXT record at a selector it gives you.
  Check it with the [DKIM checker](https://email-validation.org/tools/dkim-checker/); [DKIM selectors and key rotation](https://email-validation.org/guides/dkim-selectors-key-rotation/)
  covers the selector side.
- **SPF:** set a custom return-path (bounce) domain under your domain, and add the platform to that domain's SPF
  record. Each extra `include` counts toward SPF's limit of 10 DNS lookups
  ([RFC 7208, section 4.6.4](https://www.rfc-editor.org/info/rfc7208/)); see [the SPF lookup limit](https://email-validation.org/guides/spf-lookup-limit/)
  and the [SPF checker](https://email-validation.org/tools/spf-checker/).

Make DKIM the priority. Forwarding breaks SPF, while DKIM signatures generally survive it, and RFC 9989, section 7.4,
says a domain that publishes `p=reject` must not rely on SPF alone.

## Subdomains: sp and np

A record at your organizational domain also covers its subdomains unless you say otherwise
(RFC 9989, section 4.7):

- **`sp`** sets the policy for existing subdomains. Without it, `p` applies.
- **`np`**, new in RFC 9989, sets the policy for subdomains that do not exist in DNS, which forgers sometimes invent.
  Without it, `sp` applies, or `p`. A receiver built on RFC 7489 ignores the tag as unknown and falls back the same
  way.
- A subdomain can publish its own `_dmarc` record, which takes precedence for mail from that subdomain. An `sp` tag
  in a subdomain's own record is ignored.

This lets you stage subdomains separately, for example `p=quarantine; sp=none` while a marketing subdomain is still
being fixed. Look for each subdomain in the reports before you assume it sends nothing.

## Stage 3: quarantine, gradually

Under RFC 7489, the `pct` tag applied the policy to a share of failing mail, and Google's rollout guide still uses
it: start around 10% for a small organization or 1% for a large one, then raise the value to 100.

```text
_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@example.com"
```

RFC 9989 removed `pct` (Appendix A.6). Operational experience showed receivers rarely applied values other than 0
and 100 accurately. Its replacement is the test tag `t`: with `t=y`, a receiver applies the policy one level lower,
so `quarantine` is treated as `none` and `reject` as `quarantine`, while reports continue as usual.

Section 4.7 also says receivers must ignore tags they do not know, so a receiver that follows RFC 9989 ignores
`pct` and applies `p=quarantine; pct=10` to all failing mail, not to a tenth of it. Plan each step as
all-or-nothing at such receivers, use `t=y` where you want a test step, and judge each step by the reports, not by
the number. Stay at `pct=100` (or with no `pct` and no `t=y`) for a full reporting
cycle, and check that the only failing sources left are ones you do not recognize.

## Stage 4: reject

```text
_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"
```

Google's rollout guide calls `reject` optional and advises caution, because failing mail is refused and never
delivered. If you missed a source, its mail now bounces: Gmail answers with
[550 5.7.26](https://email-validation.org/bounce-codes/550-5-7-26/) and Microsoft with [5.7.509](https://email-validation.org/bounce-codes/5-7-509/). Keep reading the
reports after the switch; a new service added later fails the same way.

## What changes at enforcement

Mail that does not go straight from you to the recipient is where enforcement hurts legitimate mail
([RFC 7960](https://www.rfc-editor.org/info/rfc7960/), section 2):

- **Forwarding** (alumni addresses, aliases, rules that forward to another mailbox) arrives from the forwarder's IP,
  so SPF fails or no longer aligns. DKIM usually still passes, which is why it matters most.
- **Mailing lists** often add a subject tag or a footer, which invalidates DKIM (RFC 7960, section 3.2.3), so neither
  check survives. Many list
  programs now rewrite the From: address to the list's own to avoid this, as RFC 9989, section 7.4, notes.

ARC ([RFC 8617](https://www.rfc-editor.org/info/rfc8617/), experimental) lets each intermediary record the
authentication results it saw, so a later receiver can choose to trust them. Yahoo asks senders who forward mail to
implement it. RFC 9989 notes that, at its publication, no such method had become widely used, so do not count on it.

This is why RFC 9989 treats domains with ordinary users differently from domains used only for bulk or transactional
mail. If your staff post to mailing lists from the domain, consider enforcing on a separate sending subdomain or
stopping at `quarantine`.

## A staged checklist

1. SPF and DKIM set up for every service you know of; wait 48 hours.
2. Publish `p=none` with a `rua` address and a dedicated report mailbox. Check it with the
   [DMARC checker](https://email-validation.org/tools/dmarc-checker/) or write it with the [DMARC generator](https://email-validation.org/tools/dmarc-generator/).
3. Read reports for at least a week, longer if some mail is sent only monthly; a month if staff post to mailing
   lists.
4. Fix each legitimate source: aligned DKIM first, aligned SPF second.
5. Decide on `sp` and `np` for subdomains.
6. Move to `p=quarantine` (with `t=y` first if you want a test step; `pct` ramps only work at receivers that still
   follow RFC 7489) until it covers all failing mail.
7. Hold for a reporting cycle (a month if staff post to lists) and compare dispositions.
8. Move to `p=reject` if your mail flows allow it, and keep monitoring.

## Questions

### Is p=none enough for Gmail and Yahoo?

Yes. Both accept `p=none` from bulk senders, but the mail must still pass DMARC with alignment. Enforcement adds
protection against forgery; it is not a delivery requirement at either provider.

### Should I switch to strict alignment?

Usually not. RFC 9989 says nearly all domain owners find relaxed alignment sufficient, and strict alignment can make
your own subdomain mail fail.

### Does p=reject stop all phishing that uses my brand?

No. DMARC covers the domain in the From: address. Lookalike domains and a fake display name with someone else's
address are outside it; RFC 9989, section 11.4, places display name attacks out of scope.

### Can I go back to p=none if something breaks?

Yes, by changing the TXT record. Receivers notice the change at different times, so reports covering the switch may
mix the old and the new policy ([RFC 9990, section 3.3](https://www.rfc-editor.org/info/rfc9990/)).

## Try it

Look up your current record with the [DMARC checker](https://email-validation.org/tools/dmarc-checker/), and verify a list with
[bulk email verification](https://email-validation.org/bulk-email-verification/) before the first large send after a policy change.

## Related

- [Glossary: SPF, DKIM and DMARC](https://email-validation.org/glossary/#spf-dkim-dmarc).
- [DMARC generator](https://email-validation.org/tools/dmarc-generator/) for writing the record at each stage.
- Bounce codes for DMARC failures: [5.7.32](https://email-validation.org/bounce-codes/5-7-32/) (From: not aligned) and
  [550 5.7.26](https://email-validation.org/bounce-codes/550-5-7-26/).

## Related guides

- [How to read DMARC aggregate reports](https://email-validation.org/guides/dmarc-aggregate-reports/)
- [Gmail and Yahoo sender requirements](https://email-validation.org/guides/gmail-yahoo-sender-requirements/)
- [BIMI requirements explained](https://email-validation.org/guides/bimi-requirements/)
- [DKIM selectors and key rotation](https://email-validation.org/guides/dkim-selectors-key-rotation/)
- [The SPF 10-lookup limit explained](https://email-validation.org/guides/spf-lookup-limit/)
- [All guides](https://email-validation.org/guides/)

## Sources

- [RFC 9989, Domain-Based Message Authentication, Reporting, and Conformance (DMARC)](https://www.rfc-editor.org/info/rfc9989/)
  (May 2026): policy tags, alignment, domain owner steps, enforcement, indirect mail, removal of `pct`.
- [RFC 7489, DMARC](https://www.rfc-editor.org/info/rfc7489/) (March 2015): the original `pct` and `sp` definitions.
- [RFC 7208, Sender Policy Framework (SPF)](https://www.rfc-editor.org/info/rfc7208/): the 10-lookup limit.
- [RFC 9990, DMARC Aggregate Reporting](https://www.rfc-editor.org/info/rfc9990/): policy changes during a reporting
  period.
- [RFC 7960, Interoperability Issues between DMARC and Indirect Email Flows](https://www.rfc-editor.org/info/rfc7960/):
  how forwarding and mailing lists break SPF and DKIM.
- [RFC 8617, The Authenticated Received Chain (ARC) Protocol](https://www.rfc-editor.org/info/rfc8617/).
- [Google: Email sender guidelines](https://support.google.com/mail/answer/81126): DMARC for senders of more than
  5,000 messages a day.
- [Google: Email sender guidelines FAQ](https://support.google.com/a/answer/14229414): alignment requirements.
- [Google Workspace: Set up DMARC](https://knowledge.workspace.google.com/admin/security/set-up-dmarc): tags,
  alignment modes, the 48-hour wait.
- [Google Workspace: Recommended DMARC rollout](https://knowledge.workspace.google.com/admin/security/recommended-dmarc-rollout):
  stages, monitoring period and starting percentages.
- [Yahoo: Sender best practices](https://senders.yahooinc.com/best-practices/): DMARC for bulk senders, ARC for
  forwarders.
- [Outlook.com Postmaster: Policies, practices and guidelines](https://substrate.office.com/ip-domain-management-snds/postmaster/Policies):
  minimum and recommended policy.

## Get up to 500 free credits. No card needed.

New accounts get 500 free credits (100 when you sign up with a free email provider such as Gmail, Outlook or Yahoo, or another personal mailbox such as a paid one like Fastmail or one from your internet provider). Try it on your own list before you buy. [Create your account](https://email-validation.org/signin/?new=1) or [open the free email checker](https://email-validation.org/email-checker/).