What DMARC policy enforcement actually requires

DMARC policy enforcement means the policy is p=quarantine or p=reject rather than p=none for the Organizational Domain and every subdomain below it (RFC 9989 s3.2.9), so a record that leaves sp=none or np=none falls short. RFC 9989 section 4.7 defines three policy values: none (monitoring only), quarantine (send fakes to spam) and reject (refuse fakes). Only quarantine and reject ask a receiver to act on failing mail, which is what makes them enforcement and leaves none as observation.

Enforcement also depends on getting an aligned pass, not simply an SPF or DKIM pass on its own. A pass only counts towards DMARC when the authenticated domain matches the From domain: relaxed alignment, the default, accepts the same Organizational Domain, while strict alignment, set with adkim=s or aspf=s, demands an identical domain (RFC 9989 s3.2.10, s4.7, s5.3.5).

Publishing p=reject carries its own requirement on the sending side. RFC 9989 sections 7.4 and 8 state that a domain publishing p=reject must not rely on SPF alone and must sign its mail with valid DKIM, since mail relayed by a forwarding address or alias arrives from the forwarder's server, which the original sender's SPF record does not list, while a valid DKIM signature generally survives the relay.

NCSC's anti-spoofing guidance frames p=none as a deliberate first phase, a chance to see who sends mail on the domain's behalf before enforcement begins, not a step to rush past. The UK government turned that arc into a mandate rather than a suggestion.

From 1 October 2016, the Cabinet Office's Government Digital Service made p=reject the default DMARC policy for every service.gov.uk email service, one of the earliest examples of enforcement being required rather than merely advised. HMRC's head of cyber security at the time, Ed Tucker, said DKIM, SPF and DMARC:

represent the cornerstone of technical controls that senders can implement today to rebuild trust and retake the email channel. Source: dmarc.org

What DMARC policy enforcement does not require

DMARC policy enforcement does not require, or guarantee, that a receiver actually blocks spoofed mail. RFC 9989 section 7.4 says receivers must not reject mail purely because a record carries p=reject, and section 5.4 says they should not; without further analysis, they must treat it as quarantine. Enforcement is a request to receivers, not a guarantee of what happens next.

It does not cover lookalike domains either. Enforcement only applies to exact use of your own domain in the From address, so it does nothing against cousin domains, homograph domains or a display name that simply shows your organisation's name over a different address; those need separate detection, not a stricter DMARC policy.

It no longer involves a percentage ramp. RFC 9989 removed the pct= tag entirely (Appendix A.6, C.5.2, s9.3), so there is no ramp to plan and no reason to leave pct= in a record. A pct= value below 100 left over from an old record is still honoured by receivers running the older rules, and it applies the policy to only that share of failing mail, which is exactly why it should come out rather than stay as a safety margin.

It does not tolerate two records either. Publishing two DMARC records at the same name does not make receivers merge them or apply the stricter one: both are discarded as if neither existed, and receivers carry on up the DNS tree (RFC 9989 s4.10, s4.10.1), so the domain quietly falls back to a parent domain's record, if there is one, or to no DMARC processing at all.

And it is not a certification requirement. Cyber Essentials does not require DMARC, SPF or DKIM, so enforcement is not a box to tick for the scheme. See our Cyber Essentials and email security guide for what NCSC guidance actually asks of suppliers.

How enforcement maps to DNS and email controls

Enforcement maps onto one DNS record, and a handful of tags inside it. A domain's DMARC policy is a TXT record at _dmarc.example.com, and the record only counts if v=DMARC1 comes first, matched exactly and case-sensitively; get that wrong and the whole record is ignored (RFC 9989 s4.1, s4.5, s4.7).

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

Two further tags extend the policy to subdomains. sp= sets the policy receivers apply to existing subdomains and falls back to p= when it is absent; np= sets the policy for subdomains that do not exist at all, falling back to sp=, then p=, when absent (RFC 9989 s4.7).

Finding the record has also changed. Discovery walks up the DNS tree in at most eight queries rather than consulting the Public Suffix List that RFC 7489 used; psd=n now marks the Organizational Domain directly (RFC 9989 s4.10, C.3, s4.10.2).

Alignment strictness is also a tag, not a default you must accept. adkim and aspf set relaxed, the default, meaning the same Organizational Domain, or strict, meaning an identical domain, for DKIM and SPF alignment (RFC 9989 s4.7). Relaxed is what most domains with several sending subdomains need, and it is worth confirming SPF alignment against our SPF explainer before tightening it.

One tag exists purely to soften the p=, sp= and np= policies during testing. t=y drops enforcement one level, so reject acts as quarantine and quarantine acts as none, without changing p=none itself or switching off reporting (RFC 9989 s4.7). Receivers still running the older RFC 7489 rules ignore t= as an unknown tag, so at those receivers p=reject with t=y still means reject.

Meeting the requirement without breaking mail

Meeting the requirement without breaking mail means working through a sequence, not making a single DNS edit.

Check for duplicate records first, since two records at _dmarc mean neither is read, and receivers carry on up the DNS tree as if the domain had no record of its own (RFC 9989 s4.10, s4.10.1).
Publish p=none with a working rua= address, because a record with no valid p, or with an sp or np value that is not valid, is read as p=none only if it has a valid rua, and otherwise gets no DMARC processing at all (RFC 9989 s4.10.1). The same rule means a later typo in sp= or np= cancels even p=reject.
Fix SPF and DKIM for every legitimate sending source before moving the policy up; our DKIM setup guide by provider covers the provider steps rather than repeating them here.
Move p=none to p=quarantine, then to p=reject, once reports show every real source aligning; the full walk is in our p=none to p=reject guide, and the choice between the two later steps is in our quarantine versus reject guide.
For a domain that never sends mail, publish p=reject immediately, alongside SPF -all and, if it receives no mail either, the null MX set out in our parked domains guide, so receivers that honour DMARC keep mail using the domain out of the inbox.

Pro Tip: Before moving from quarantine to reject, filter your aggregate reports to failing rows only and confirm every remaining source is something you do not recognise, not a legitimate sender with a broken SPF include.

DMARC enforcement checklist

Confirm only one DMARC record exists at _dmarc for the domain
Fix SPF and DKIM alignment for every legitimate sending source
Publish p=none with a working rua= address and read the reports
Move to p=quarantine once every real source passes and aligns
Sign all outbound mail with DKIM before publishing p=reject
Remove any leftover pct= value below 100 rather than planning a ramp

Evidencing enforcement in reports

Evidence of DMARC enforcement comes from the aggregate reports a domain's policy asks for, not from the DNS record alone. Aggregate reports (rua=) are now specified by RFC 9990 and failure reports (ruf=) by RFC 9991, both published alongside RFC 9989 in May 2026, superseding the RFC 7489 Appendix C format that many older guides still describe.

The concrete evidence sits in what a report shows: the policy the receiver found published and, for each sending IP address, the message count, the disposition applied and the DMARC-aligned DKIM and SPF results. That combination shows whether receivers are applying the policy to failing mail while legitimate mail passes, and it is worth reading field by field rather than skimming a summary: see our guide to reading DMARC reports, and the free DMARC report viewer, which opens one uploaded report at a time.

Reports have real limits as evidence. They only ever arrive from receivers that choose to send them, only for days those receivers actually saw your mail, and they name only the last server that handled it before delivery. A quiet run of reports is not proof that nothing failed; it may only mean a large receiver did not send one. NCSC's guidance on monitoring and updating DNS records also treats the reports as repeated work, a few rounds of investigating, updating records and reviewing new reports, rather than a check to run once and file away.

Where ShieldMarc fits

ShieldMarc's part in enforcement is to monitor and evidence it, not to enforce it: enforcement itself always happens inside the receiver's mail system, driven by your DNS record. The free Domain Trust Check runs the same Security Grade scan as the dashboard, an outside-in check that includes p=reject, subdomain policy at reject and a check that no leftover pct sits below 100, among 16 checks in total, without needing an account.

Paid monitoring adds continuous watching once enforcement is in place. The DMARC health monitor re-reads the record every five minutes and emails only when the effective p= changes, catching a silent regression to quarantine or none. Report data is kept 365 days on every plan, Starter included; Professional (£70 a month, or £50 a month billed annually) covers 25 domains, and MSP (£130 a month, or £100 a month billed annually) covers 100 domain slots. Both paid plans add Dynamic SPF, refreshed hourly at minute 17 to keep SPF under the 10-lookup limit alignment depends on; it excludes the Trial.

A domain sending from one or two well-known providers, with someone happy to check its own DNS occasionally, may not need a paid plan to reach enforcement: the free checkers cover the DNS side, and Starter keeps a year of report data on one domain. Said plainly, ShieldMarc has no hosted BIMI, no SOC 2 or ISO 27001 today and no partner or PSA integrations, so it evidences and monitors enforcement rather than standing in for a certification audit. Full plan details and the 30-day trial are on the pricing page.

My own view: the DNS side of enforcement is the easy part. What actually takes time is confirming every legitimate sender is accounted for before tightening the policy, and that only shows up by reading reports, not by checking the record once.

Start today

Start today by checking where a domain's policy already stands, then close the gaps before moving it up. Our DMARC checker validates a domain's DMARC record against RFC 9989, so you can see whether its policy sits at none, quarantine or reject before you change anything.

Before changing p=, run the free SPF checker and DKIM checker to confirm the SPF record stays within 10 lookups and your senders' DKIM selectors publish keys; the aggregate reports are what show a source that is not yet aligned. Enforcement magnifies whatever is not authenticated, rather than creating a new problem, so this step matters more as the policy gets stricter.

Our 30-day trial, no card required, adds monitoring and reports while moving through the policy levels, and subscribing before it ends keeps its remaining days. Whichever plan is used, put a recurring weekly slot in the calendar to read aggregate reports while at p=none or p=quarantine, before advancing to p=reject.

Frequently asked questions

Does p=reject guarantee that spoofed email is blocked?

No. RFC 9989 says receivers must not reject mail solely because a record carries p=reject, and without further analysis must treat that mail as if the policy were quarantine (s5.4, s7.4). The RFC leaves final handling to each receiver's local policy, so whether failing mail is rejected is the receiver's own decision, not a promise. Enforcement also only covers exact use of your own domain in the From address, not lookalike domains or a spoofed display name.

Is a pct= ramp still needed now that RFC 9989 has removed the tag?

No. RFC 9989 removed the pct= tag entirely, so there is no percentage left to ramp. A pct= value below 100 left in an existing record is still honoured by receivers running the older rules, applying the policy to only that share of failing mail, which is why it should be removed rather than kept.

t=y is the current way to soften a policy during testing: it drops enforcement one level, so reject acts as quarantine and quarantine acts as none, without touching p=none or reporting. Receivers still running the older RFC 7489 rules ignore t= as an unknown tag, so at those receivers p=reject with t=y still means reject.

Does Cyber Essentials require DMARC enforcement?

No. Cyber Essentials does not require DMARC, SPF or DKIM. Our Cyber Essentials and email security guide sets out what NCSC guidance actually asks suppliers to do.

How long does it take to reach DMARC policy enforcement?

RFC 9989 sets no deadline, and it suggests a minimum only for some domains. It says a domain whose users might post to mailing lists should not publish p=reject, and that any such domain still wanting it should first spend at least a month at p=none, then as long again at p=quarantine, using aggregate reports to judge the impact on its users (s7.4). NCSC's guidance frames p=none as a deliberate monitoring phase, to be moved on from only once every legitimate sender has been identified and aligned.

The DNS side is one change: publishing or editing the _dmarc TXT record takes effect as soon as it propagates, with aggregate reports typically arriving in 24 to 48 hours. The slow part is fixing alignment for every real sending source first, not the record change itself.

What happens to subdomains when the parent domain enforces DMARC?

sp= sets the policy receivers apply to existing subdomains, falling back to whatever p= is set to when sp= is absent. np= sets the policy for subdomains that do not exist at all, falling back to sp=, then p=, when absent. A subdomain that publishes its own DMARC record follows that record's p= instead of the parent's policy (RFC 9989 s4.10.1), so one left at p=none falls short of enforcement; check it with the same free DMARC checker used for the parent domain.

What DMARC policy enforcement actually requires