The DMARC enforcement playbook: from p=none to p=reject

24 June 2026 · DMARC Engine · 13 min read

Reaching p=reject is the whole point of DMARC: it is the policy that actually stops criminals from sending mail that appears to come from your domain. Yet most organisations stall at p=none for months or years, either because they never look at the reports or because a botched jump to enforcement once bounced a payroll run and nobody wanted to try again. Neither outcome is necessary. With a disciplined, evidence-led process you can move from monitoring to full enforcement without losing a single legitimate message.

This playbook is the canonical, end-to-end procedure we use to take a domain from p=none to p=reject safely. It assumes you understand the basics of DMARC, SPF and DKIM; if you need a refresher on any single mechanism, the blog has granular explainers. Here we focus on the journey itself: how to monitor, how to read the data, how to fix each sending source, how to ramp policy with pct and sp, and how to recognise the failure modes before they cost you mail.

What "enforcement" actually means

DMARC, defined in RFC 7489, publishes a single TXT record at _dmarc.yourdomain.com that tells receiving mail servers what to do with messages that fail authentication. The policy lives in the p= tag and has exactly three values:

• p=none: monitor only. Receivers honour your reporting requests but take no action on failures. This is your observation deck, not a destination.
• p=quarantine: failing mail is treated as suspicious, typically delivered to the spam or junk folder.
• p=reject: failing mail is refused outright at the SMTP layer and never reaches the recipient.

"Enforcement" means p=quarantine or p=reject, any policy with teeth. The goal of this playbook is p=reject, because quarantine still lets a spoofed message land in a folder a user can fish out, and many mailbox providers treat quarantine inconsistently. Only reject delivers the unambiguous protection that, for example, the Google and Yahoo bulk-sender requirements introduced in February 2024 effectively expect of high-volume senders.

A message passes DMARC if it passes either SPF or DKIM, and that passing mechanism is aligned with the domain in the visible From: header. Alignment is the concept people most often miss, so it deserves its own moment.

Alignment is the thing you are really fixing

DMARC does not care that SPF or DKIM merely passed. It cares that the passing identifier matches the From: domain your recipients see.

• SPF alignment compares the From: header domain with the domain in the SMTP MAIL FROM (the Return-Path / envelope sender). In relaxed mode (the default) a match on the organisational domain is enough: mail.bounces.yourdomain.com aligns with yourdomain.com. In strict mode (aspf=s) the domains must be identical.
• DKIM alignment compares the From: header domain with the d= domain in the DKIM signature. Relaxed mode (default) allows organisational-domain matching; strict (adkim=s) demands an exact match.

This is why a SaaS platform sending "on your behalf" can pass plain SPF (its own envelope domain is authorised) yet fail DMARC: the authenticated domain is the vendor's, not yours. The fix is almost always to get aligned DKIM in place: a key you publish under your own domain that the vendor signs with. Keep this in mind throughout: when you "fix a source", you are usually fixing alignment, not raw SPF/DKIM.

Phase 0: Publish a monitoring record and turn on reporting

You cannot manage what you cannot see. Before changing anything, publish a p=none record that requests aggregate reports.

_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:reports@yourdomain.com; ruf=mailto:forensic@yourdomain.com; fo=1; adkim=r; aspf=r"

Tag by tag:

• v=DMARC1: version, must come first.
• p=none: observe only, for now.
• rua=: where aggregate reports go. These are the daily XML summaries that make the whole process possible. Point them at a mailbox or, far better, an analytics platform.
• ruf=: where forensic/failure reports go. Few providers send these now and they can contain message content, so treat them as optional and handle them carefully.
• fo=1: request a failure report if any underlying check fails (more useful than the default fo=0).
• adkim / aspf: alignment modes; start relaxed.

Raw XML from dozens of receivers is unreadable by hand. This is where a DMARC platform earns its place: DMARC Engine ingests rua reports and turns thousands of rows into a per-source view of who is sending as you, whether they align, and what would happen at each policy level. If you are doing this manually, expect to spend real time parsing.

Why not skip straight to quarantine? Because you do not yet know who sends mail as your domain. Marketing tools, the helpdesk system, the ERP, a forgotten print server, a payroll provider: most organisations underestimate their sender count by half. Enforcing before you have inventoried them guarantees breakage.

Leave p=none running for at least two to four weeks. You need enough data to capture monthly senders (invoicing, payroll, statements) that may not appear in a single week.

Phase 1: Read the reports and build a sender inventory

Aggregate reports answer one question per sending source: does mail from this IP, claiming to be from my domain, pass aligned SPF and/or aligned DKIM? Your job is to enumerate every source and sort it into one of three buckets.

For each source you see in the data, record:

• The sending IP or service (reports include the source IP; reverse-DNS and your platform usually identify the vendor).
• SPF result and SPF alignment.
• DKIM result and DKIM alignment.
• Approximate volume.

Then classify:

1. Legitimate and fully aligned: passes DMARC already. Leave it alone.
2. Legitimate but failing or unaligned: your real work. These are the sources you must fix before enforcing, or they will be rejected.
3. Illegitimate: spoofers, spam, and abuse. These are exactly what p=reject is meant to kill. You do nothing to "fix" them; you simply confirm they are not yours.

A common surprise in bucket 2 is forwarding. When a recipient auto-forwards your message, SPF breaks (the forwarding server is not in your SPF record) and DKIM may survive if the message is unmodified. Mailing lists frequently break both by rewriting the subject or body. You cannot "fix" the wider internet's forwarders, but you can ensure your mail carries a robust DKIM signature so it survives most forwarding, and you can rely on DMARC's pass-on-either logic.

Phase 2: Fix every legitimate source

Work bucket 2 down to zero. The fix depends on the source type.

Your own mail platform (Microsoft 365, Google Workspace)

These are the easiest. Ensure:

• The platform's sending hosts are in your SPF record (via the provider's include:).
• DKIM signing is enabled and the published keys (selectors) are live in DNS. Microsoft 365 uses selector1 and selector2 CNAMEs; Google publishes a google._domainkey TXT record. Both produce aligned DKIM because d= is your domain.

Verify with the DKIM checker that the public key resolves and matches the selector the platform actually signs with.

Third-party senders (CRM, marketing, helpdesk, billing)

The pattern is consistent across vendors:

1. Authorise SPF: add the vendor's include: to your SPF record, if their envelope domain needs to align (relaxed mode helps here).
2. Set up aligned DKIM: this is the durable fix. The vendor gives you a selector and a public key (usually as a CNAME or TXT under selector._domainkey.yourdomain.com). Once live, mail is signed with d=yourdomain.com and aligns regardless of envelope domain.
3. Set a custom Return-Path / bounce domain where the vendor supports it, to bring SPF into alignment too. Belt and braces.

Always prefer fixing DKIM alignment over piling more include: statements into SPF, for the reason in the next section.

Mind the SPF 10-lookup limit

RFC 7208 caps the number of DNS lookups an SPF evaluation may trigger at 10. Each include, a, mx, ptr and exists mechanism counts, and nested includes count cumulatively. Exceed it and the receiver returns permerror: your SPF is treated as broken, which can drag DMARC down with it.

Large organisations blow past 10 lookups alarmingly easily: Microsoft 365 plus a marketing tool plus a CRM plus a ticketing system can do it on its own. The remedy is SPF flattening: resolving those nested includes into a compact set of IP ranges that stays under the limit, and keeping it updated as vendors change their infrastructure. The free SPF checker is a read-only diagnostic that counts your lookups and shows what is over the limit; the automatic flattening that resolves includes into IP ranges and keeps the record updated as vendors change is the hosted SPF service, which monitors for drift on your behalf. This is also why aligned DKIM is your friend: DKIM has no lookup budget, so leaning on it reduces SPF pressure.

A healthy SPF record ends in -all (hardfail) once you are confident; ~all (softfail) is a reasonable interim. Never leave a record on ?all (neutral); it tells receivers nothing.

Transactional and infrastructure senders

Do not forget the quiet ones: application servers sending password resets, monitoring systems, scan-to-email devices, backup notifiers. They send low volume but they will appear in reports and will be rejected at enforcement if unaligned. Route them through an authenticated relay (your M365/Workspace SMTP, or a transactional provider with aligned DKIM) rather than letting them send direct-to-MX from a random IP.

Phase 3: Ramp the policy

Once your reports show all legitimate sources passing aligned DMARC, and only the spoofers failing, you escalate. Do it in graded steps, watching reports for several days at each stage before advancing. The mechanism for graded escalation is the pct tag.

Using pct correctly

The pct tag tells receivers to apply your policy to only a percentage of failing mail, leaving the remainder at the next-lower policy. So p=quarantine; pct=25 quarantines 25% of failures and treats the other 75% as none. It is a sampling dial that lets you test enforcement against a fraction of traffic and contain the blast radius if you have missed a source.

Important nuance: pct applies to the policy you have set. At p=reject; pct=10, the 10% sample is rejected and the other 90% falls back to quarantine, not to none. Plan your ramp with that in mind.

A conservative, battle-tested ladder:

1. p=none: baseline monitoring (Phase 0-2 complete).
2. p=quarantine; pct=25: hold for ~1 week, watch for unexpected failures.
3. p=quarantine; pct=50: hold.
4. p=quarantine; pct=100 (equivalently, drop the pct): hold ~1-2 weeks. This is the real proving ground: full quarantine surfaces any source you missed without bouncing it outright.
5. p=reject; pct=25: first taste of rejection.
6. p=reject; pct=50.
7. p=reject (pct=100): full enforcement. Done.

Each rung should be data-gated, not calendar-gated: do not advance while you still see a legitimate source failing. If a new failure appears, pause, fix the source, confirm it passes, then resume. DMARC Engine automates exactly this ramp, recommending the next safe step and flagging any newly-failing legitimate source before you advance, which is the difference between a two-month confident rollout and an indefinite stall at p=none. See the enforcement journey for how the guided ramp works.

Don't forget subdomains: the sp tag

By default a DMARC policy on the organisational domain applies to all subdomains that do not publish their own _dmarc record. The sp (subdomain policy) tag lets you set a different policy for subdomains.

This matters in two directions:

• Protect unused subdomains immediately. Attackers love spoofing news.yourdomain.com or invoices.yourdomain.com precisely because admins forget them. Setting sp=reject while the top-level domain is still ramping (p=quarantine; sp=reject) locks down subdomains that send no legitimate mail, with zero risk.
• Avoid surprising a busy subdomain. If marketing.yourdomain.com is a heavy sender via a tool you have not yet aligned, an inherited p=reject could bounce it the moment you enforce the parent. Either align it first, or give it its own gentler _dmarc.marketing record during the ramp.

A mature record at full enforcement often looks like:

_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:reports@yourdomain.com; adkim=s; aspf=s; fo=1"

Tightening adkim and aspf to strict (s) is the final hardening step, sensible only once you have confirmed every legitimate source aligns exactly (not just on the organisational domain). For most organisations relaxed alignment is perfectly secure; move to strict deliberately, not reflexively.

Phase 4: Operate and maintain

Enforcement is not "set and forget". DMARC is a living control because your sending estate keeps changing.

• Keep reading aggregate reports. New SaaS tools, marketing campaigns and acquired domains introduce new senders that will be rejected the moment they go live unaligned. Catching them in reports beats a help-desk flood.
• Rotate DKIM keys. RFC 6376 keys should be rotated periodically (a 2048-bit key rotated every 6-12 months is a common posture). Rotation is not automatic: DMARC Engine sends monthly "rotation due" reminders for selectors older than around 180 days and supports overlapping selectors so the changeover is clean. Publish the new selector, let it propagate, switch signing, then retire the old key after a grace period so in-flight mail still verifies.
• Watch SPF for drift. Vendors change their IP ranges. A flattened record needs monitoring so it never silently goes stale or creeps back over 10 lookups.
• Layer the rest of the stack. With DMARC enforced, you have the prerequisite for BIMI, which requires an enforced DMARC policy (quarantine with pct=100, or reject) before your verified logo and VMC can display. Add MTA-STS and TLS-RPT to protect the transport layer too.

Common failure modes (and how to avoid them)

Jumping straight to reject

The cardinal sin. Without an inventory you will reject legitimate mail. Always ramp through quarantine first.

Treating an SPF or DKIM pass as a DMARC pass

A source can pass SPF and still fail DMARC because the authenticated domain is not aligned with From:. Always check the alignment columns in your reports, not just the raw auth results.

The SPF 10-lookup ceiling

Quietly catastrophic: one too many includes flips your SPF to permerror and can sink otherwise-fine mail. Flatten and monitor; favour DKIM where you can.

Ignoring subdomains

A parent p=none leaves every subdomain spoofable. A parent p=reject with an unaligned busy subdomain bounces real mail. Use sp deliberately.

Forwarding and mailing lists

Expect a residue of "failures" from forwarders and lists even at steady state. Robust DKIM lets most forwarded mail survive on the DKIM leg. Do not panic-revert because of a handful of list failures; confirm they are forwarding artefacts, not a broken source, before reacting.

One mailbox drowning in XML

Pointing rua at a human inbox guarantees the reports get ignored within a week. Use a parser or platform, or you are flying blind.

Forgetting transactional and IoT senders

The scan-to-email printer and the monitoring alerter are easy to miss in a week of data and brutal to discover via a rejected password-reset email. Inventory the quiet senders too.

Next steps

The path is always the same shape: observe, inventory, fix alignment for every legitimate source, ramp with pct, protect subdomains with sp, then maintain. Done with discipline, p=reject is reachable in weeks and breaks nothing.

To start: run a free DMARC checker to see your current record, then publish a p=none monitoring record and let reports accumulate. If you would rather have the ramp managed for you, with automated report parsing, per-source readiness verdicts, guided pct/sp recommendations, hosted SPF flattening with drift monitoring, and DKIM rotation reminders with overlapping-selector support, that is precisely what hosted DMARC from DMARC Engine does, and the enforcement journey walks you through every step to full p=reject.