From monitoring to p=reject: how to actually roll out DMARC enforcement

The reports are the road: aggregate versus forensic

Everything in a DMARC rollout runs on the reports receivers send back, so it’s worth knowing exactly what the two kinds contain. Aggregate reports, configured with the rua tag, are daily gzipped XML summaries that count how many messages claiming your domain passed or failed SPF and DKIM, grouped by sending IP — they contain no message content and are the workhorse of any rollout, the thing you read to confirm every legitimate source aligns before tightening policy (ShowMyIP, 2026). Every provider that supports DMARC, including Gmail, Microsoft and Yahoo, sends them daily, each covering a 24-hour window.

Forensic reports, configured with ruf, are different: per-message samples of individual failures that can include the actual email headers and sometimes a redacted body (ShieldMarc, 2026). In theory they’re useful for debugging, but in practice most major providers — Google, Microsoft and Yahoo — rarely or never send them because of privacy concerns, and because they can carry message content, many organizations leave ruf unset entirely (ShieldMarc, 2026). The practical consequence is simple: you build your whole rollout on aggregate data, and you don’t wait for forensic reports that mostly never arrive.

How to actually read an aggregate report

Raw aggregate XML is hard on the eyes, but the fields that matter are few, and understanding them lets you make better decisions than a dashboard alone. Each report opens with the policy you published, then lists one record per sending source. The fields to read are these:

Field	What it tells you
source_ip	The IP that sent mail claiming to be your domain — you map this to a known sender
count	How many messages that source sent in the window
header_from	The visible From domain; it should always be yours
spf / dkim result	Whether each check passed or failed for this source
disposition	What the receiver did: none (delivered), quarantine (spam), or reject (blocked)

The work is a loop: extract each source IP, match it to a known service — your mail platform, CRM, marketing tool, helpdesk, invoicing system — and confirm whether it passes SPF or DKIM with alignment (DMARC Report, 2026). A legitimate sender showing failures is one you must fix before enforcement, and an unrecognized source sending in volume is either a forgotten service or a spoofer. Because parsing XML by hand across dozens of senders is tedious, most teams feed reports into an analytics platform — but the fields above are what those platforms are showing you, and knowing them keeps you in control of the decisions (DuoCircle, 2026).

The monitoring phase: a full quarter, minimum

The single most important discipline of the rollout is patience at the start. You hold at p=none for at least 90 days — one full quarter — and this isn’t arbitrary: you need enough report data to catch monthly senders like invoicing systems and newsletters and quarterly senders like seasonal campaigns and quarterly reports before you start blocking anything (DMARC Report, 2026). Complex environments with dozens of third-party services may warrant six months. What you’re really producing during this phase is an inventory of every source sending as your domain, many of which you’ll have forgotten you use.

As you inventory, you fix. For every misaligned legitimate sender, add the missing SPF include, enable DKIM signing on that platform, or move the sender onto an aligned subdomain (ShieldMarc, 2026). Two categories need special attention because they routinely break alignment: forwarded mail and mailing lists, along with any service that modifies message headers, all of which need specific handling before you tighten (DMARC Report, 2026). Watch your SPF record too, since sending through enough third-party platforms can breach the 10-lookup limit and cascade into DMARC failures for legitimate mail — a trap our guide on SPF, DKIM and DMARC covers in detail.

Ramping enforcement with the pct tag

Once your reports show consistent alignment across all legitimate sources, you move to quarantine — but gradually, using the pct tag rather than switching all traffic at once. The pct value controls what percentage of failing messages receive the enforcement action; everything outside that percentage is treated as if the policy were p=none (DMARC Report, 2026). A typical ramp looks like this:

Stage	Record	Duration	What to check
pct=10	p=quarantine; pct=10	~2 weeks	Initial test — any legitimate mail quarantined?
pct=25	p=quarantine; pct=25	~3 weeks	Watch for newly affected senders
pct=50	p=quarantine; pct=50	~3 weeks	Most issues surface by now
pct=100	p=quarantine; pct=100	30+ days clean	Alignment stable above 95%
Reject	p=reject	Permanent	Continue monitoring

After each increase, review your reports: if no legitimate mail is being quarantined and alignment stays above 95%, raise the percentage; if a legitimate sender starts failing, pause the ramp, fix the alignment issue, and wait at least two weeks before resuming (DMARC Report, 2026). The goal is zero legitimate-mail impact at every step, and the promotion criterion to reject is holding quarantine at pct=100 cleanly — under about 1% unknown or unauthenticated traffic — for at least 30 days (DuoCircle, 2026).

Don’t forget the subdomains

A gap people leave open, even after doing everything else right, is the subdomain policy. Without an sp tag, your subdomains simply inherit the parent domain’s policy — which means that if you enforce p=reject on your main domain but never address subdomains, an attacker can spoof a subdomain instead and sail straight past your protection (DMARC Report, 2026). Setting sp= explicitly closes that door.

It also gives you a staging tool. You can enforce reject on the apex domain while holding sp=quarantine on subdomains that are still stabilizing, then tighten to sp=reject once their alignment is consistent (DuoCircle, 2026). And the most overlooked case is the domain that sends no mail at all — a parked domain or an unused subdomain should publish p=reject outright, declaring that nothing legitimate ever originates from it, because unprotected non-sending domains are exactly what attackers look for.

The two mistakes that bracket the whole thing

Almost every DMARC failure is one of two opposite errors. The first is rushing: jumping straight to p=reject before your reports confirm that every legitimate sender aligns, which silently blocks real mail from services you forgot you had (DMARC Report, 2026). The fix for a rollback is never to drop the whole policy — instead reduce the pct value or step back to quarantine, find the specific failing sender in your reports, correct their SPF or DKIM, and scale back up.

The second error is the more common and, ultimately, the more costly: parking at p=none forever. Monitoring without enforcement provides no protection at all — spoofed mail still lands in inboxes, because you’ve told receivers to take no action on failures (DMARC Report, 2026). The confusion is a compliance one: Gmail and Yahoo’s bulk-sender rules ask only for a published DMARC record at p=none, so plenty of senders reach that bar and stop, believing they’re finished when they’re compliant but fully exposed (Email Industries, 2026). Visibility is not protection; p=none is the starting line, and the value lives entirely in the enforcement it’s meant to lead to.

Evidence, not guesswork

Step back and the DMARC rollout is a small masterclass in the philosophy that runs through this whole library: you earn enforcement with evidence rather than declaring it by fiat. The reports turn a security project into an inventory — a complete, sometimes startling, list of every system sending mail in your name — and the discipline is to act only on what the data shows, ramping with pct, staging with sp, and never advancing past a failing sender. It’s the same shape as reading analytics you actually act on, rather than admiring a dashboard while nothing changes.

That’s also where it fits what we do. Running a rollout to reject — reading the aggregate reports, chasing down the forgotten senders, staging the pct ramp and the subdomain policy, and holding monitoring in place afterward — is exactly the kind of ongoing work we handle as part of the email infrastructure we run, and we advance a domain to enforcement on the evidence in its reports rather than on a guess. Reaching p=reject is what unlocks the rest: it’s the prerequisite for the verified logo of BIMI, and it’s the point at which the authentication our pillar on reaching the inbox describes stops being a monitoring exercise and starts actually defending your domain.