DMARC monitoring after p=reject — why you're not done

Getting a domain to p=reject takes weeks of evidence and cleanup, so it feels like a finish line. It isn't. Enforcement changes what a DMARC mistake costs: before reject, a misconfiguration meant some spoofed mail slipped through; at reject, a misconfiguration means your own legitimate mail is destroyed — silently, at the receiver, with no bounce landing anywhere you look. The stakes went up, not down. Monitoring is how you keep the guarantee you just earned.

(Still on the way to enforcement? Start with why monitor DMARC reports — the pre-reject half of this story. This page is about what happens after.)

Five things that still go wrong at enforcement, and how each one shows up in the aggregate (RUA) reports if anyone is reading them:

1. New senders start broken — and now broken means rejected

Someone in marketing connects a new email tool. Sales adds a CRM that sends "from" your domain. IT stands up a notification service. Every new sending source starts life unaligned — its DKIM key isn't set up yet, it isn't authorized to send for you — and at p=reject its mail doesn't land in spam, it disappears. The sender usually finds out from a customer ("we never got the invoice"), days later.

In the reports, a new source shows up on day one as a new IP sending unaligned volume. That's the difference between a quiet configuration task and an incident.

2. Alignment drifts, silently

The things that made your mail pass DMARC are living configuration, and all of them decay without anyone deciding anything:

• An SPF record edited past the 10-lookup limit stops evaluating — and every sender that relied on SPF for alignment starts failing.
• A DKIM selector gets dropped during a DNS migration, or a provider rotates keys and the CNAME nobody remembers adding isn't there to follow.
• A provider changes its sending infrastructure, and mail that aligned yesterday doesn't today.

None of these announce themselves. At p=none they cost you nothing, so nobody built the habit of watching for them; at p=reject each one deletes real mail until someone notices the pattern — or reads the report that showed it immediately.

3. The record itself is one edit away from gone

DNS migrations, registrar moves, a well-meaning cleanup of "old TXT records" — DMARC policies get weakened and deleted by accident far more often than by attack. A domain that spent a month earning p=reject can be back at no-policy in one afternoon, and nothing visibly breaks: mail keeps flowing, spoofing quietly works again. Only a re-check of the published record catches it the day it happens.

4. Spoofing doesn't stop — you just stop seeing the cost

At enforcement, spoofed mail gets rejected, which is the point. But the reports still show the attempts: unaligned volume from infrastructure you don't recognize is a live feed of who is trying to send as you. Two reasons to keep reading it — a sudden spike tells you you're being targeted (often alongside phishing against your customers), and a compromised machine inside your own fleet sending as your domain looks exactly the same and needs to be found fast.

5. Forwarding keeps eroding the edges

Mailing lists and forwarders have always broken SPF and sometimes DKIM; at p=reject that mail is refused. The aggregate reports are the only way to see how much legitimate volume falls into that hole and whether it's growing — before you conclude that "a few lost messages" is actually a department's worth of forwarded mail.

The decay is measurable

None of this is hypothetical. Across nearly six hundred real, registered domains scanned through DNS Doctor — large organizations and everyday small-business domains alike — the pattern of "temporary" configuration that quietly became permanent shows up everywhere:

• Half of all domains never finished the journey. 23% publish no DMARC record at all, and another 27% sit at p=none — monitoring mode, indefinitely.
• Of the domains where DKIM keys were found at common selectors, roughly a third (31%) still use 1024-bit keys. The two most common cases are the google selector and Microsoft's selector1, nearly tied — a Workspace or 365 key generated at setup and never rotated since.
• Two in five SPF records (40%) end in ~all — the softfail qualifier that was meant to be a transition step toward -all and instead became the destination.
• Fifteen domains sit at 9 or 10 DNS lookups in SPF — one more include away from the limit where SPF stops evaluating — and three are already over it, returning permerror on every check while their owners presumably believe SPF is protecting them.

Every one of these started as a reasonable temporary state. Nothing forced anyone to come back to it, so nobody did. That is the case for alerting on change rather than relying on intentions — the subject of the rest of this page.

What monitoring actually means here

Reading XML attachments from forty mailbox providers isn't a habit anyone keeps. In practice, staying safe at enforcement means automating exactly three things:

1. Ingest the aggregate reports and turn them into per-source alignment you can read at a glance.
2. Alert on change — a new sending source, an alignment regression, a weakened or deleted record — rather than on a schedule someone has to remember. At p=reject the new-source half is deliberately quieter: unaligned mail from a source you have never seen is already being rejected on your behalf, so it belongs in a log you read, not an email you answer at 2am. It should still reach your inbox if it persists.
3. Re-check the published records daily, so a broken edit is a same-day fix instead of a quarter-end discovery.

That is what DNS Doctor's monitoring does for the domains you put on it — daily re-scans of the records, DMARC report ingestion with per-source alignment, and alerts when something changes. If you're not sure where a domain stands today, start with the free scan: it reads the current records and tells you what's published, what's aligned, and what to fix first.