Deliverability · Authentication

How to Enforce DMARC: Moving from p=none to p=reject Without Breaking Mail

DMARC only protects your domain from spoofing once it’s enforced — a record sitting at p=none gives you visibility but stops nothing, which is why only a minority of domains with DMARC ever reach full enforcement. But advancing too fast is the fastest way to block your own legitimate mail and trigger a panicked rollback. This guide walks the enforcement journey deliberately: understanding what DMARC actually checks, the staged progression through the three policies, reading reports to know when to advance, and the 2026 changes to how the rollout is done.

What does DMARC actually check?

Before enforcing anything, it’s essential to understand precisely what a DMARC policy acts on, because the policy is consulted only at the very end of a decision chain. DMARC builds on SPF and DKIM, and the rule is that a message passes DMARC if either an aligned SPF check or an aligned DKIM check passes — it fails only when both fail. The receiver evaluates SPF and DKIM, checks whether the passing domain aligns with the visible From-header domain, and only if neither produces an aligned pass does it look at your policy tag.

That word “aligned” is where most confusion lives. SPF and DKIM can each pass on their own terms while DMARC still fails, because the domain they authenticated doesn’t match the From domain the recipient sees. Alignment can be relaxed, the sensible default, which allows subdomain matches, or strict, which demands an exact match. The practical consequence is that enforcing DMARC isn’t really about choosing a policy — it’s about making sure every legitimate sender produces an aligned SPF or DKIM pass for your From domain first, which is the groundwork our SPF, DKIM, and DMARC setup guide lays down.

The stakes of enforcement

It’s worth being clear-eyed about why this effort is worthwhile, because a published-but-unenforced DMARC record is a surprisingly common dead end. A domain sitting at p=none receives reports about spoofing but does nothing to stop it — attackers can still freely impersonate the domain, and the reports merely document the abuse. Only a minority of domains with DMARC have actually reached p=reject, which means most of the rest are providing zero anti-spoofing protection despite having “DMARC” in place. The reports without enforcement are visibility without defence.

Two forces make enforcement increasingly non-negotiable. The first is protection: organisations enforcing DMARC report markedly fewer domain-spoofing incidents and often a noticeable lift in legitimate inbox placement, since receivers trust an enforced domain more. The second is compliance, which now drives much of the adoption — the major mailbox providers’ bulk-sender requirements, payment-industry standards, and BIMI all expect or require enforcement, and BIMI in particular won’t display your logo without at least quarantine. Increasingly, cyber-insurance questionnaires and vendor security reviews ask about it too. Enforcement has shifted from a security nicety to a baseline expectation, which is why finishing the journey rather than stalling at monitoring matters.

The three policies: none, quarantine, reject

Enforcement is a journey through three policy values, each a stronger statement than the last, and the diagram shows the progression every domain should follow.

The starting policy, p=none, is monitoring only: all mail is delivered regardless of authentication, while receivers send you aggregate reports — “see everything, block nothing.” Quarantine is the safety-net step, routing failing mail to the spam folder where a recipient could still find it. Reject is the goal, instructing receivers to refuse failing mail at the SMTP level so it’s never delivered and the sender gets a bounce. Reject is the strongest possible public statement against exact-domain spoofing, and it’s also a prerequisite for adjacent controls — BIMI, for instance, requires enforcement at quarantine or reject, never none. The table compares them.

Why must you start at monitoring?

The single most important rule of DMARC enforcement is to start at p=none and stay there long enough, because this monitoring phase is where you discover your own email infrastructure. When you publish p=none with a valid reporting address, all mail keeps flowing while receivers begin sending you aggregate reports showing every source sending from your domain — and almost every organisation discovers senders they’d forgotten: the marketing platform, the invoicing tool, the support desk, the automated notification service that some team set up years ago. Jumping straight to reject before finding these blocks them all.

The discipline of this phase is to classify every sending source as approved, unauthorised, or obsolete, and to bring every approved one into aligned authentication. You watch particularly for the things that commonly break alignment: forwarded mail that changes SPF results, mailing lists and services that modify message headers, and subdomains that need their own SPF and DKIM. You hold p=none until you’ve observed at least one full business cycle of mail — including the monthly invoices and quarterly newsletters — and your reports show consistent aligned passing across all legitimate sources, generally above 95 percent over at least 30 days. Only with that evidence in hand is the domain ready to advance, a staged discipline our DMARC enforcement rollout guide details further.

Reading aggregate reports

Aggregate reports are the evidence base for every decision in this process, so knowing how to use them is central. These reports, requested via the rua tag, arrive as periodic XML summaries listing which source IPs and services are sending as your domain and whether each is passing or failing SPF, DKIM, and alignment. The raw XML isn’t readable by hand, so you feed it into a DMARC report analyzer or dashboard that turns it into sources and outcomes you can act on.

What you’re looking for shifts as you progress. Early on, you’re inventorying senders and hunting for legitimate sources that fail — then fixing the root cause, whether that’s a missing IP in your SPF record, DKIM signing that was never set up for a third-party service, or an alignment problem. A frequent culprit is the SPF ten-DNS-lookup limit: route mail through enough third-party platforms and you breach it, causing SPF to fail and cascading into DMARC failures for legitimate mail. As you move toward enforcement, the reports tell you whether it’s safe to advance — you want to see legitimate mail passing, failing mail confined to sources you don’t authorise, and no sudden rise in complaints about missing messages. They also surface the spoofing attempts your enforcement is stopping, which is the whole point, much as feedback loops surface complaints in our feedback loop guide.

What breaks DMARC alignment?

Since enforcement comes down to getting every legitimate sender aligned, it helps to know the handful of things that most commonly break alignment, because you’ll meet them during monitoring. The most frequent is the SPF ten-DNS-lookup limit: SPF records are capped at ten DNS lookups, and routing mail through several third-party platforms — each adding its own include — quietly breaches that cap, producing an SPF permerror that cascades into DMARC failure for otherwise legitimate mail. Trimming and flattening your SPF record to stay under the limit is often the single highest-value fix.

Two more patterns cause repeated trouble. Forwarding changes the path a message takes and frequently breaks SPF, while mailing lists and any service that modifies a message in transit — rewriting headers or adding footers — can break DKIM and therefore alignment. The mitigation here is ARC: identifying trusted ARC sealers lets a receiver honour the authentication a forwarding service vouched for, preventing modified-but-legitimate mail from failing automatically. Finally, subdomains are a common blind spot — each subdomain that sends mail needs its own aligned SPF and DKIM, and a parked subdomain inherits the organisational policy unless you set otherwise. Spotting these in your reports and fixing them before you tighten policy is exactly the work the monitoring phase is for.

How do you advance safely?

Advancing from one policy to the next is a controlled release with checkpoints, not a single DNS edit, and the goal at every step is zero impact on legitimate mail. Historically, the mechanism for this was the pct tag, which applied the enforcement action to only a percentage of failing messages while treating the rest as p=none — you’d ramp from 10 to 25 to 50 to 100 over several weeks, watching reports after each increase. An important 2026 change is worth flagging here: RFC 9989 has made the pct tag historic. The newer approach for testing a policy is the t=y flag, a dry-run mode that asks receivers to apply the next-lower policy while you observe, letting you validate quarantine or reject behaviour without yet committing to it.

However you ramp, the rhythm is the same: make a change, watch the aggregate reports, and only advance if alignment stays high and no legitimate mail is being caught. If you see a legitimate sender start failing — almost always one missed during monitoring — you pause, drop back to a safer setting, find that sender in the reports, fix its SPF or DKIM, confirm it passes consistently, then resume. The whole journey from none to reject typically takes nine to eighteen months done correctly, with each phase holding for at least 90 days, and the patience is what prevents the emergency rollbacks that come from rushing. Crucially, you always know the exact DNS change that returns the domain to monitoring if something breaks.

Parked domains and subdomains

Two categories of domain deserve specific attention because they’re easy to overlook and represent real spoofing exposure. The first is parked or unused domains — registered domains that send no email at all. These are attractive targets for spoofing precisely because no one is watching them, so the right move is to publish an explicit p=reject record stating that no legitimate mail should ever originate from them. This is one of the few cases where you can safely go straight to reject without a monitoring period, since there’s no legitimate mail to break.

The second is subdomains, which behave differently from your organisational domain. A DMARC policy at your main domain can specify a separate subdomain policy through the sp tag, letting you, for instance, enforce reject on the organisational domain while holding subdomains at a gentler policy you’re still validating. Each subdomain that actually sends mail needs its own aligned SPF and DKIM, and any subdomain you don’t use for email should be locked down the same way as a parked domain. Treating subdomains deliberately — rather than assuming they inherit safe behaviour automatically — closes a gap that attackers genuinely exploit, since a spoofed subdomain can look convincingly like your brand.

Verifying and maintaining your record

Once you’ve made a policy change, you verify it took effect and then keep watching, because DMARC is never truly “done.” The terminal shows the records and the verification.

# The three policy records (TXT at _dmarc.example.com)
v=DMARC1; p=none;       rua=mailto:dmarc@example.com
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
v=DMARC1; p=reject;     rua=mailto:dmarc@example.com
# Dry-run a stricter policy (RFC 9989, replaces pct ramp)
v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com
# Verify after a DNS change — wait one TTL, check multiple resolvers
$ dig TXT _dmarc.example.com @1.1.1.1 +short
$ dig TXT _dmarc.example.com @8.8.8.8 +short
# Confirm exactly ONE v=DMARC1 record with the intended p= value.

After any change, wait at least one TTL for propagation and query a couple of public resolvers directly to confirm exactly one valid record appears with the policy you intended, then run it through a DMARC checker. Reaching p=reject isn’t the end, though — it’s the start of ongoing maintenance, because new senders, IP changes, and vendor updates can break authentication at any time. You keep reviewing aggregate reports to catch new legitimate sources before they’re blocked, rotate DKIM keys periodically, and prune stale SPF includes you no longer use, since over-authentication is frowned on by receivers. One more easy win: publish p=reject on parked and unused domains, since no legitimate mail should ever come from them. For teams running their own sending infrastructure where alignment is fully in your control, our PowerMTA server hosting gives you the authentication control that makes reaching reject straightforward — while the report-driven, staged approach is what gets you there without breaking a single legitimate message.