How to Move from DMARC p=none to p=reject (Step by Step)

What does the DMARC p tag actually do at each stage?

DMARC has three enforcement levels, set by the p= (policy) tag. The original specification, RFC 7489 §6.3, describes the policy tag as the “Requested Mail Receiver policy” and defines its three values. In May 2026 DMARCbis was published as a Standards-Track set of RFCs that obsolete RFC 7489: the core document is RFC 9989, with companion documents for aggregate reporting (RFC 9990) and failure reporting (RFC 9991). The three policy values are unchanged.

The p= tag is required for any policy record. If you are new to the mechanism, read what DMARC is and how it works and how SPF, DKIM and DMARC fit together before you publish anything. DMARC only passes when a message aligns through SPF or DKIM, so those two layers have to be sound first.

What DMARC record should I publish to start at p=none?

The journey begins with a monitoring record. Publish p=none with an rua= address so receivers start sending you aggregate reports. The rua= tag, defined in RFC 7489 §6.3, is a comma-separated list of addresses to which aggregate feedback is sent. Without it, you are flying blind and can never safely advance.

_dmarc.example.com.   IN  TXT  "v=DMARC1; p=none; rua=mailto:reports@your-monitor.example;"

Point rua= at an address that feeds a parser. Raw aggregate reports arrive as gzipped XML attachments, several per day per domain, and reading them by hand does not scale past a single domain. ShieldMarc gives you a verified ingestion address per domain when you add it, so the reports land already parsed in your dashboard. You can also paste a single report into the free DMARC Report Viewer to see what the XML contains before you commit to a workflow.

Note that the optional ruf= tag (message-specific failure, sometimes called forensic, reports) is also defined in RFC 7489 §6.3. It is useful where receivers support it, but the aggregate rua= stream is the one that actually drives this migration. You can generate a correct starting record with the free DMARC record generator and confirm it is live with the DMARC checker.

How do I read the aggregate reports to find my senders?

This is the part most rollouts skip, and it is the only part that matters. Aggregate reports tell you, per source IP, how much mail claimed to be from your domain, and whether it passed SPF, passed DKIM and aligned. Your job during the monitoring phase is to turn that into a complete inventory of every system that legitimately sends as your domain.

Work the report inbox until you can name every sending source. A typical inventory for a single UK organisation looks like this:

• The main mail platform (for example Microsoft 365 or Google Workspace), which usually aligns through DKIM.
• Marketing and newsletter platforms sending on a subdomain.
• Helpdesk, CRM, invoicing and recruitment tools that send transactional mail on your behalf.
• Internal application or appliance relays sending alerts and monitoring notifications.

For a walkthrough of exactly what each XML field means, see understanding DMARC aggregate reports. In ShieldMarc the report stream is grouped per sender so you can see, for each source, its SPF and DKIM pass rates as badges rather than reading raw XML. That per-sender view is what lets a small team carry the migration across many domains without drowning in attachments.

How do I tell a misconfigured sender from real spoofing?

The reports will show failures, and not all failures are equal. Some are your own legitimate senders that are simply not aligned yet. Some are forwarders. Some are genuine spoofing attempts. You cannot advance to enforcement until you can separate the three, because moving to p=reject while a real sender is still failing means that sender's mail disappears.

ShieldMarc applies threat scoring to each unfamiliar source so the report view tells you, in plain language, whether a failing IP looks like a misconfigured sender you have simply not authorised yet or a source with no plausible relationship to your domain. A cluster of failures from a known SaaS vendor's IP range with a consistent envelope-from is almost always an alignment gap you need to fix. A burst of failures from unrelated, geographically scattered consumer IPs with no DKIM signature is far more likely to be abuse. The threat feed also surfaces volume spikes from sources you previously marked as benign, so a relay that suddenly triples its traffic resurfaces for a fresh look.

A practical rule: every source you can attribute to a real business system gets fixed (authorised and aligned). Everything you cannot attribute is exactly the mail you want p=reject to block, so it is a reason to advance, not a reason to wait.

How do I authorise every legitimate sender before enforcing?

For each legitimate source the reports surfaced, you make it align. DMARC passes when a message aligns through SPF or DKIM, so you have two levers. DKIM alignment is the more durable of the two because it survives forwarding, so prefer it wherever the sending platform supports signing with your domain.

• SPF:add the sender's sending hosts or include mechanism to your SPF record so the envelope-from domain authorises that source. Watch the ten DNS-lookup limit; if you are close to it, see how to fix SPF too many DNS lookups.
• DKIM:publish the platform's DKIM selector record so it signs with your domain. Our DKIM setup by provider guide covers the common platforms.

The adkim= and aspf= alignment-mode tags control how strictly the signing or envelope-from domain must match the visible From domain. Both accept r (relaxed) and s (strict), and both default to relaxed (RFC 7489 §6.3). Leave them at the relaxed default while you are still authorising senders, because strict mode rejects an organisational subdomain match that relaxed mode would accept, and during a rollout that is one more way to break legitimate mail. To build the records correctly use the SPF, DKIM and DMARC record guide. You are ready to advance when the reports show every named sender passing alignment and the only remaining failures are sources you cannot attribute.

When is it safe to move from p=none to p=quarantine?

You advance to quarantine when the data says it is safe, not when a number of weeks have passed. The readiness gate is simple: every legitimate sender you inventoried is now passing DMARC through aligned SPF or DKIM, and you have read enough days of reports to be confident the inventory is complete (low-frequency senders such as a monthly billing run or an annual mailshot have appeared at least once).

ShieldMarc surfaces this as a readiness indicator per domain. When it is green, the parsed reports show no aligned-sender failures and the picture has been stable across recent reporting windows. That green gate, not the calendar, is the signal to change the record:

_dmarc.example.com.   IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:reports@your-monitor.example;"

Keep rua= in place. The reports do not stop being useful when you start enforcing, and you will rely on them to confirm the change did no harm.

Why not just ramp the pct tag from 10 to 100?

Several third-party guides tell you to enforce gradually by ramping the pct= tag (pct=10, then 25, then 50, then 100). ShieldMarc does not recommend pct ramping, and we want to be explicit about why.

Under the original spec the pct= tag (default 100) tells receivers what percentage of failing messages to subject to the policy. Per RFC 7489 §6.6.4 (Message Sampling), a message not selected for reject is treated as though quarantine applies, and a message not selected for quarantine gets normal local classification. So pct=50 with p=reject means roughly half of failing mail is rejected and the other half is quarantined. That is the whole problem with ramping: it is a coin flip applied to mail that is already failing. If a legitimate sender is still misaligned, pct=10 does not protect that sender, it just makes the breakage intermittent and far harder to diagnose from the reports. If every legitimate sender is aligned, you do not need a percentage at all, you are simply ready.

There is now a second, decisive reason. DMARCbis (RFC 9989, the current standard) removes the pct= tag entirely (Appendix A.6, “Removal of the pct Tag”). In its place it defines a binary t= (testing) tag with values y or n (default n). With t=y the domain owner is signalling that it is testing its policy and expects receivers to apply the level one below the stated policy (so p=reject; t=y is handled like quarantine). Any guide that still recommends ramping a percentage is writing against an obsolete tag. The report-driven gate described here was always the better practice, and it now matches the standard.

When do I advance from quarantine to reject?

Exactly the same gate, read a second time. After moving to quarantine you keep reading the reports. Quarantine is the safety net: if a sender you missed during monitoring exists, its mail now lands in junk rather than vanishing, and it shows up as a fresh aligned-sender failure in the reports. You fix it, the failure clears, and once the readiness indicator is green again and stable across recent reporting windows, you advance to reject.

_dmarc.example.com.   IN  TXT  "v=DMARC1; p=reject; sp=reject; adkim=r; aspf=r; rua=mailto:reports@your-monitor.example;"

This staged advance is the standard recommended progression on every authoritative source. dmarc.org describes it as publishing none to gather reports, then modifying the policy from none to quarantine to reject as you gain experience. The NCSC is equally direct: “Having a DMARC policy of reject on all of your domains is the best way to prevent spoofing of your email”, and “as soon as you are confident DKIM and SPF are continuing to work correctly, you should move to a DMARC policy of reject”. NCSC notes that many organisations move from quarantine to reject after about three months, and recommends closely monitoring reports for at least a two-week period after the change to reject. Treat that two-week watch as a floor, not a calendar countdown: the gate is still the data.

The detailed difference between the two enforcement levels, and why reject is the real goal rather than a permanent home at quarantine, is covered in DMARC quarantine vs reject.

What about subdomains when I reach p=reject?

The sp= (subdomain policy) tag controls what happens to mail from subdomains. Per RFC 7489 §6.3, if sp= is absent the policy from the p= tag is applied to subdomains. So p=reject alone already covers them. We still recommend writing sp=reject explicitly: it documents intent, it survives anyone copying the record into a tool that splits the tags, and ShieldMarc's scoring flags any record where sp= is weaker than p= as a separate control failure.

DMARCbis tightens this further. RFC 9989 adds an np= tag for non-existent subdomains (falling back to sp= and then p= when absent), and it replaces the Public Suffix List with a DNS tree walk to work out the organisational domain. The adkim= and aspf= alignment tags and the three p= values are unchanged. If you run parked or non-sending subdomains, see DMARC for parked domains for the lock-down configuration, which can go straight to reject because there is no legitimate mail to break.

Do I keep rua reporting on after I reach p=reject?

Yes, indefinitely. rua= is not scaffolding you remove once the building is up. Your sending estate changes: a new marketing platform is onboarded, a vendor rotates its sending IPs, an internal relay is rebuilt. Each of those can introduce a new unaligned source, and at p=reject that source's mail is rejected immediately. The aggregate reports are how you catch it, ideally before anyone notices the missing mail.

M3AAWG's email authentication best practices treat p=reject (or p=quarantine where reject is not yet possible) as the destination, and view p=none, sp=none and partial percentages as transitional states to be removed as quickly as possible. The reporting stream, by contrast, is permanent: it is what lets you stay at reject safely rather than drifting back into breakage. Keep an eye on the overall posture with the Security Grade check, which scores the live DMARC, SPF and DKIM records together.

How does this scale across dozens of domains at once?

The single-domain version of this journey is manageable by hand. The version a UK MSP or a multi-domain IT team actually faces, forty, eighty, two hundred domains each at a different stage, is not. That is the gap ShieldMarc is built for, and it is why the first paid tier starts at 25 domains rather than one. A tool priced for a single small business does not solve the problem we solve.

ShieldMarc keeps a per-domain readiness indicator so you can see at a glance which domains are clean enough to advance and which still have an aligned-sender failure to clear. The Professional plan (£49/month billed annually, £69 month-to-month) covers 25 domains, 5 team members and 1,000,000 DMARC messages a month. The MSP plan (£99/month billed annually, £129 month-to-month) covers 100 domain slots with brand-domain grouping, so the .com, .co.uk and .org variants of one brand count as a single slot, plus unlimited team members and 5,000,000 messages a month. You can add a further 50 domain slots for £39.99/month. Full numbers are on the pricing page.

If you only need to take one domain to reject and want a free evaluator, the ShieldMarc Starter tier is free for a single DMARC domain with up to 10,000 messages a month and 365-day retention. It is a freemium evaluation tier, not a multi-domain plan. For a genuinely free single-domain monitor from a third party, EasyDMARC's free plan and dmarcian's free Personal plan are both honest options. ShieldMarc's value shows once you are running the same migration across an estate.