How do I monitor DMARC after reaching p=reject?

24 June 2026 · DMARC Engine · 7 min read

Reaching p=reject is a milestone, not a finish line. Enforcement protects your domain only for as long as your published records keep matching how your mail is actually sent, and that changes constantly as marketing tools are added, providers rotate infrastructure, DKIM keys age and well-meaning colleagues edit DNS. This guide explains exactly what to watch after enforcement, how to set up the right alerts, and how to catch problems before they bounce a single legitimate message.

The short answer

Once you are at p=reject, keep enforcement healthy by doing four things continuously:

• Review aggregate (RUA) reports on a regular cadence so you can see every source sending as your domain and confirm it is aligned and authenticated.
• Alert on change, not just on failure: new sending sources, drops in pass rates, sudden volume spikes, and any edit to your DMARC, SPF or DKIM records.
• Detect drift: the slow divergence between what your DNS says and what your senders actually do (new IPs, SPF nearing the 10-lookup limit, a ~all that crept back in).
• Track DKIM key age and rotate on a schedule so a stale or compromised key never becomes a single point of failure.

The goal is simple: no legitimate stream should ever start failing without you knowing first.

Why monitoring matters more after reject, not less

In monitoring mode (p=none) a misconfiguration is invisible to your users: mail still flows. At p=reject the safety net is gone. A new SaaS tool that sends invoices, a provider that quietly adds a new sending region, or a DKIM key that expires will now cause hard rejections at the receiver. Recipients see nothing; your mail simply vanishes into the void with a DMARC failure.

That is the trade-off you accepted to stop spoofing, and it is the right one. It just means the discipline shifts from "did I get to reject?" to "is reject still safe today?"

Step 1: Keep aggregate reports flowing and reviewed

Your rua= tag is the telemetry that makes everything else possible. Confirm it is still present and pointing somewhere you actually read:

v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com; ruf=mailto:forensic@yourdomain.com; fo=1; pct=100

Things to verify on a recurring basis:

1. Reports are arriving from your major receivers (Google, Microsoft, Yahoo and others). A sudden gap is itself a signal, often a DNS or mailbox problem at the reporting address.
2. Pass rates per source are at or near 100% for every legitimate stream. Anything aligned-failing at reject is being rejected right now.
3. No unfamiliar sources are accumulating volume under your domain.

Reading raw XML by hand does not scale past a handful of reports a week. If you are still parsing files manually, see how to read a DMARC aggregate report for the field-by-field walkthrough, then let a platform aggregate them. Hosted DMARC ingests every RUA report into one dashboard so you review sources and trends instead of attachments.

Tip: keep fo=1 so you receive a failure sample whenever either SPF or DKIM fails, not only when both do. Forensic (RUF) reports are sparse (many receivers do not send them) so never rely on them as your primary signal.

Step 2: Set up the four alerts that matter

Scheduled review catches slow problems; alerts catch fast ones. Configure notifications for these four events.

New sending source detected

The single most valuable alert. The moment a previously unseen IP or provider sends mail claiming to be your domain, you want to know, whether it is a legitimate new tool that needs authorising or an attacker probing your domain. New-source alerts turn a future bounce into a five-minute SPF or DKIM fix.

Authentication pass-rate drop

A stream that was passing at 100% and falls to 80% means something broke: a rotated key not published, a provider IP change, an SPF edit. Alert on any meaningful drop in the aligned-pass percentage for a known source, not just on total failures.

Volume spike or anomaly

A sudden surge in mail attributed to your domain, especially failing mail from unfamiliar networks, can indicate a spoofing campaign abusing your brand. Even though p=reject blocks delivery, the spike tells you that you are being targeted and may need to warn customers.

Record-change alert

Set up monitoring that watches your published _dmarc, SPF and DKIM TXT records and pings you on any change. This is your defence against the most common real-world cause of an outage: a colleague editing DNS without realising the blast radius. A diff in your DMARC policy or SPF record should never be a surprise.

Step 3: Watch for configuration drift

Drift is the gap between your published policy and reality, and it widens silently.

• SPF DNS-lookup creep. RFC 7208 caps SPF evaluation at 10 DNS lookups; exceed it and receivers return a permerror, which DMARC treats as an SPF failure. Every new include: (a new CRM, a new ticketing tool) eats into that budget. Monitor your live lookup count and flatten before you hit the ceiling: the SPF checker counts lookups and shows what to flatten.
• The ~all regression. A clean record ends in -all (hard fail). It is alarmingly common for a provider's setup wizard to rewrite SPF ending in ~all (soft fail). Alert if your qualifier weakens.
• New aligned-failing IPs. A known provider adding sending IPs it did not tell you about shows up in aggregate data as the same provider failing alignment. Catch it before it becomes routine.
• Subdomain sprawl. A sp= policy or subdomain record may differ from your organisational policy. Confirm subdomains inherit or explicitly set p=reject.

Step 4: Track DKIM key age and rotate on schedule

DKIM keys do not expire on their own, but a key that has signed your mail for years is a growing liability and a longer-lived target. RFC 6376 best practice is to rotate selectors periodically.

1. Stagger selectors. Publish the next key under a new selector (e.g. selector2) before retiring the old one, so signing never stops.
2. Rotate roughly twice a year for most organisations, more often if a key may have been exposed.
3. Use 2048-bit RSA keys. If a legacy 1024-bit key is still in use, treat rotation as the moment to upgrade.
4. Alert on key age so a "we will rotate later" never becomes a three-year-old key.

For the mechanics of publishing and validating selectors, see set up DKIM for my domain.

Worked example

You are at p=reject; pct=100 and reports are clean. On a Tuesday you receive a new-source alert: 40 messages from a provider you do not recognise, all failing DMARC.

1. You open the aggregate view and see the source is a transactional-email service: the reverse DNS matches a tool your finance team signed up for to send invoices.
2. Because they are failing, those invoices are currently being rejected at recipients. The alert reached you before finance noticed.
3. You authorise the stream properly: add the provider's DKIM selector (preferred, because it survives forwarding) and, if needed, its include: to SPF, first checking the SPF checker so the new include: does not push you past 10 lookups.
4. Within a reporting cycle the new source shows 100% aligned pass. Enforcement held; one new tool was onboarded without an outage.

That is the whole monitoring loop in miniature: alert, diagnose from aggregate data, authorise, verify.

How to verify enforcement is still healthy

• Run a live policy check to confirm p=reject is published and unchanged: the DMARC checker shows your current record in seconds.
• Confirm SPF resolves under 10 lookups and ends in -all.
• Confirm each active DKIM selector resolves and uses a 2048-bit key.
• Confirm aggregate reports for the last cycle show every legitimate source at or near 100% aligned pass, with no unexplained sources.

Common problems

• Reports suddenly stop. Usually the RUA mailbox or its DNS broke, not your senders. Verify the rua= address still receives mail. See why DMARC reports are empty.
• A legitimate service fails only at reject. It was passing on raw auth but not aligned. Alignment is stricter than authentication; see a service is not aligned at reject.
• Forwarded mail fails SPF. Expected: SPF breaks on forwarding. This is exactly why DKIM alignment matters, and why you should never rely on SPF alone at reject.
• A DNS edit broke a record overnight. This is what record-change alerts exist to prevent. If you do not have them, add them today.

Next steps

Treat p=reject as a steady state you maintain, not a project you finished. Put aggregate-report review on a recurring schedule, switch on the four alerts (new source, pass-rate drop, volume spike, record change), monitor SPF lookup count and DKIM key age, and verify with the DMARC checker after any change. If you would rather not run this watch yourself, hosted DMARC continuously ingests your reports, flags new sources and drift, and tracks key age so enforcement stays safe as your sending estate evolves.