# From DMARC p=none to p=reject: a safe step-by-step path

> Stay at p=none for at least 2 to 4 weeks while you collect aggregate reports and fix every legitimate sender that fails. Then move to p=quarantine for a week or two, then to p=reject, and keep reading reports afterward. The move is safe when nearly all mail from your known senders passes SPF or DKIM with an aligned domain.

By the DNS Autopilot team. Published 2026-10-18.

Most domains that publish DMARC stop at `p=none`. It was the quickest way to meet the Google and Yahoo sender rules, and nothing broke. But `p=none` protects nothing: anyone can still send mail as your domain, and receivers will deliver it.

This guide shows how to get from `p=none` to `p=reject` without blocking your own invoices, newsletters, or password resets. Each step has a clear exit criterion, so you know when to move on.

## Why p=none is not enough

DMARC is defined in [RFC 7489](https://www.rfc-editor.org/rfc/rfc7489). It tells receiving mail servers what to do with a message that claims to be from your domain but fails authentication. The policy has three values.

| Policy | What receivers do with failing mail | Protects you from spoofing? |
| --- | --- | --- |
| `p=none` | Deliver it normally and send you reports | No |
| `p=quarantine` | Send it to the spam folder | Partly |
| `p=reject` | Refuse it | Yes |

Since February 2024, Google and Yahoo require bulk senders (more than 5,000 messages a day to their users) to have SPF and DKIM, a DMARC record of at least `p=none`, a From domain aligned with SPF or DKIM, one-click unsubscribe for marketing mail, and a low spam rate. Microsoft added similar requirements for Outlook.com, Hotmail, and Live addresses in 2025. `p=none` satisfies the DMARC part of those rules. It does not stop a criminal from sending a fake invoice that appears to come from you.

`p=quarantine` and `p=reject` are the policies that change that. The risk in getting there is real: if a legitimate service sends as your domain and fails DMARC, enforcement will send its mail to spam or refuse it. The steps below exist to find those services first.

## How DMARC decides pass or fail

A message passes DMARC when either of these is true:

- SPF passes, and the domain in the Return-Path (the envelope sender) is aligned with the From domain.
- DKIM passes, and the `d=` domain in the signature is aligned with the From domain.

One aligned pass is enough. Alignment is relaxed by default (`adkim=r` and `aspf=r`), which means the two domains only need the same organizational domain. A message signed with `d=mail.example.com` aligns with a From address at `example.com`. Strict alignment (`s`) requires an exact match.

Most failures come from a third-party service that sends as your domain but signs with its own domain. SPF and DKIM both pass for the service, but neither is aligned with you, so DMARC fails.

## The path at a glance

| Step | Policy | What you do | Move on when |
| --- | --- | --- | --- |
| 1 | `p=none` | Publish the record with a `rua` address | Reports arrive |
| 2 | `p=none` | Collect reports for 2 to 4 weeks | A full sending cycle has passed |
| 3 | `p=none` | Inventory and sort every source | Each source has a label |
| 4 | `p=none` | Fix legitimate senders that fail | Known senders pass nearly all the time |
| 5 | `p=none` | Set aside forwarding failures | You can tell forwarding from real problems |
| 6 | `p=quarantine` | Enforce, watch for 1 to 2 weeks | No legitimate mail lands in spam |
| 7 | `p=reject` | Enforce fully, keep reading reports | Ongoing |
| 8 | Subdomains | Set `sp` deliberately, lock non-sending domains | Every domain has a policy |

## Step 1: publish p=none with a report address

If you have no DMARC record yet, publish one. It is a TXT record at `_dmarc.example.com`:

```dns
_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
```

The tags that matter here:

- `p` is the policy: `none`, `quarantine`, or `reject`.
- `rua` is where aggregate reports go. This is the tag the whole process depends on.
- `sp` is the policy for subdomains. It defaults to the value of `p`.
- `ruf` is where failure reports go. Few providers send them, so do not count on them.
- `adkim` and `aspf` set DKIM and SPF alignment: `r` (relaxed, the default) or `s` (strict).

Do not send `rua` to your own inbox: a personal mailbox fills up with zipped XML files within days. Use a dedicated address or a service that reads them for you. DNS Autopilot can read your reports from Gmail (read-only, and only DMARC report mail) or give you a report address of the form `<token>@rua.dnsautopilot.com`. The [setup guide](https://dnsautopilot.com/docs/setup) covers both.

If the report address is on a different domain than the one you are protecting, that domain must authorize it. Publish a TXT record named `example.com._report._dmarc.<their domain>` containing `v=DMARC1`. Without it, receivers will not send reports there. For example, if reports go to `reports@monitor.example`:

```dns
example.com._report._dmarc.monitor.example.  3600  IN  TXT  "v=DMARC1"
```

**Exit criterion:** the record is live and your first reports have arrived, usually within 1 to 2 days. Check the record with the [free DMARC check](https://dnsautopilot.com/check) if you are unsure it is published correctly.

## Step 2: collect reports for at least 2 to 4 weeks

Do not shorten this step. Some senders are rare:

- A payroll provider that runs once a month.
- An invoicing tool that sends reminders on the 1st.
- A quarterly newsletter or a yearly renewal notice.

If you enforce before a monthly sender appears in your reports, you will learn about it when the mail bounces.

Aggregate reports are daily XML files, zipped or gzipped, from mailbox providers such as Google, Microsoft, and Yahoo. Each one lists the source IP addresses that sent mail as your domain, the message counts, the SPF and DKIM results, and what the receiver did with the mail. They are accurate, but they are hard to read raw. The IP addresses mean little until someone maps them to a service.

Reports also have a limit: they only reflect receivers that send them. Treat them as a strong sample, not a complete census.

**Exit criterion:** at least 2 weeks have passed, and a full cycle of your monthly senders has appeared in the data.

## Step 3: inventory every source

List every source that sends as your domain and sort each into one of four groups.

| Group | What it looks like | What to do |
| --- | --- | --- |
| Legitimate and passing | A known service, SPF or DKIM aligned | Nothing |
| Legitimate and failing | A known service, neither aligned | Fix it (step 4) |
| Forwarders | Mail relayed through someone else's server | Set aside (step 5) |
| Abuse | An unknown source sending as you | This is what enforcement blocks |

Start with the services you know about:

- Your mailbox provider (Google Workspace or Microsoft 365).
- Marketing email and newsletter tools.
- A CRM.
- A help desk.
- Billing and invoicing.
- Website forms and their notification plugins.
- Scanners, printers, and on-premises applications.

Then look at the reports. For each source IP address, find out who owns it (a reverse DNS lookup or an IP lookup usually names the provider) and match it to a service on your list. If nobody can explain a source that sends hundreds of messages, treat it as suspect.

DNS Autopilot does this matching for you: it reads the reports, groups them by sender, and shows which senders pass and which fail.

**Exit criterion:** every source with meaningful volume is in one of the four groups, and you know which legitimate senders fail.

## Step 4: fix each legitimate sender that fails

For each failing legitimate sender, make at least one of SPF or DKIM pass with a domain aligned to yours. You have three options, listed from most common to least.

### Sign with your own domain (DKIM)

Most sending services offer a setting called "domain authentication" or "custom DKIM". The service gives you one or more DNS records, usually CNAME or TXT, to publish under your domain. After you publish them, the service signs your mail with `d=example.com`, which aligns with your From address. This is the best fix: DKIM usually survives forwarding.

### Set a custom Return-Path (SPF alignment)

Some services let you use a custom Return-Path domain, such as `bounce.example.com`. SPF then passes for a domain that aligns with `example.com`. This works, but SPF breaks when mail is forwarded, so use it as a second layer rather than the only one. If you add services to your SPF record, watch the lookup count: an SPF record that goes over 10 DNS lookups fails outright. See [SPF and the 10 DNS lookup limit](https://dnsautopilot.com/blog/spf-10-dns-lookup-limit).

### Move the sender to a subdomain

If a service cannot sign with your domain, give it its own subdomain, such as `crm.example.com`, and send from that. Authenticate the subdomain with the service.

After each change, wait for a few days of new reports and confirm that the sender now passes.

**Exit criterion:** every legitimate sender you plan to keep passes DMARC in the reports. A sender you cannot fix should be replaced or retired before you enforce.

## Step 5: expect forwarding failures, and do not chase them

Some failures are not yours to fix. When someone forwards your mail to another address, the forwarding server sends it from its own IP address. SPF fails, because that IP is not in your record. DKIM usually survives, since the signature travels with the message, unless the forwarder changes the content. Mailing lists often do, with subject tags or footers.

Receivers use ARC (Authenticated Received Chain) to judge forwarded mail, so these messages are often delivered anyway. Mark these sources as forwarders and exclude them when you judge readiness. A small tail of forwarding failures is normal even on well-configured domains.

**Exit criterion:** you can tell forwarding failures apart from real sender problems, and the real problems are fixed.

## How do you know it is safe to enforce?

You need a test, not a feeling. Look at the share of mail from your known senders that passes, over a fixed period, after you leave out forwarders and anything you cannot verify.

Here is the rule DNS Autopilot uses. It counts only reports it can verify came from the reporting provider, and it leaves known forwarders out of the count. A domain is ready for `p=quarantine` when at least 98 percent of the mail from known senders passed for 14 days with no sender left to fix. It is ready for `p=reject` on the same test over 30 days. It also needs at least 500 messages from at least 2 reporters in that window, so a quiet domain does not get a green light from a handful of messages. Each result lists the reasons in plain sentences.

You can apply the same logic by hand. The habit matters more than the numbers: a fixed window, a pass-rate threshold, no unresolved legitimate senders, and enough volume to trust the sample.

## Step 6: move to p=quarantine

When the data supports it, change the record:

```dns
_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
```

Failing mail now goes to the spam folder instead of the inbox. A missed sender is recoverable: a customer can still find the message in spam.

Do not plan a gradual rollout with the `pct` tag. [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989), the revision of DMARC, removed `pct`, and receivers may ignore it. A receiver that ignores `pct=25` applies the policy to all of your mail, so a partial rollout can turn into full enforcement. Treat each policy change as a full switch.

Watch the reports for a week or two. Also ask the people who send mail (sales, finance, support) to tell you if customers say they did not get something.

**Exit criterion:** 1 to 2 weeks with no legitimate mail in spam, and the pass rate holds.

## Step 7: move to p=reject

Change the policy one more time:

```dns
_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
```

Failing mail is now refused.

Do not stop reading reports after this. Teams add new tools all the time, and a new service without domain authentication will have its mail refused. Keep reviewing your reports, and add "authenticate the sending domain" to the checklist for any new service that sends email.

If something breaks, you can step back to `p=quarantine` while you fix it.

## Step 8: set a policy for subdomains

The `sp` tag sets the policy for subdomains, and it defaults to `p`. A common mistake is enforcing on the organizational domain while `sp=none` leaves every subdomain open to spoofing.

Set `sp` on purpose. If subdomains such as `crm.example.com` send real mail, include them in your inventory before you enforce. A subdomain can also publish its own `_dmarc` record to override the parent.

Domains and subdomains that never send mail can go straight to full protection, with no monitoring period. Publish three records:

```dns
_dmarc.parked.example.com.  3600  IN  TXT  "v=DMARC1; p=reject;"
parked.example.com.         3600  IN  TXT  "v=spf1 -all"
parked.example.com.         3600  IN  MX   0 .
```

The DMARC record rejects any mail claiming to be from the domain. The SPF record `v=spf1 -all` says no server may send for it. The null MX record (`0 .`, defined in [RFC 7505](https://www.rfc-editor.org/rfc/rfc7505)) says the domain accepts no mail.

## FAQ

### How long should I stay at p=none?

Stay at `p=none` for at least 2 to 4 weeks, and longer if you have senders that run monthly or quarterly. Move on only when every legitimate sender is accounted for and passing.

### What is the difference between DMARC quarantine and reject?

With `p=quarantine`, receivers send failing mail to the spam folder. With `p=reject`, they refuse it, so it never reaches the recipient. Quarantine is the safer first step because a wrongly blocked message can still be found in spam, while a rejected one is gone.

### Is it safe to set DMARC to reject?

It is safe when you have an inventory of your senders and the reports show that legitimate mail passes. It is not safe if you jump straight from a new record to `p=reject`. Follow the steps above, and spend a week or two at `p=quarantine` before you reject.

### Can I roll out DMARC gradually with the pct tag?

No, not reliably. RFC 9989, the revision of DMARC, removed the `pct` tag, and receivers may ignore it, so a partial percentage may be applied as full enforcement. Use the two-step move from `none` to `quarantine` to `reject` instead, and fix senders before each step.

### Will DMARC reject break email forwarding?

It can affect some forwarded mail, because forwarding breaks SPF. DKIM usually survives unless a mailing list changes the message, and receivers use ARC to judge forwarded mail. Do not try to fix forwarders from your side, and leave them out when you judge whether your domain is ready.

### How do I know when my domain is ready for enforcement?

Look for a high pass rate from your known senders over a fixed window, with no legitimate sender left failing. DNS Autopilot uses 98 percent over 14 days for quarantine and over 30 days for reject, with at least 500 messages from at least 2 reporters. You can [check your domain's DMARC policy for free](https://dnsautopilot.com/check) to see where you stand today.

## Check your domain

DNS Autopilot's free check scores any domain from 0 to 100 across email authentication, mail servers, mail in transit, DNS security, and domain and web, and gives the exact record to publish for each fix: https://dnsautopilot.com/check. No sign-up. AI assistants and scripts can fetch https://dnsautopilot.com/check/{domain}.md for the same report as Markdown, for example https://dnsautopilot.com/check/example.com.md.

## Related guides

- [SPF's 10 DNS lookup limit: why SPF breaks and how to fix it](https://dnsautopilot.com/blog/spf-10-dns-lookup-limit)
- [MTA-STS and TLS-RPT: how to require TLS for mail to your domain](https://dnsautopilot.com/blog/mta-sts-and-tls-rpt)