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. 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:
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
The tags that matter here:
pis the policy:none,quarantine, orreject.ruais where aggregate reports go. This is the tag the whole process depends on.spis the policy for subdomains. It defaults to the value ofp.rufis where failure reports go. Few providers send them, so do not count on them.adkimandaspfset DKIM and SPF alignment:r(relaxed, the default) ors(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 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:
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 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.
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:
_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, 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:
_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:
_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) 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 to see where you stand today.