The new DMARC standard says: don’t jump to p=reject

For a decade, the standard advice on DMARC has been a ladder with an obvious top rung: get to p=reject as fast as you can, because anything less means spoofed mail still reaches inboxes. Security checklists score it. Compliance frameworks require it. Vendors sell the climb.

So it's worth sitting with this sentence from RFC 9989 — the Standards Track revision of DMARC published in 2026 — about domains with human users:

"It is therefore critical that domains that host users who might post messages to mailing lists SHOULD NOT publish Domain Owner Assessment Policies of "p=reject"."

That's the standard itself, in IETF normative language, telling a large class of domains not to use DMARC's strongest setting. Not "be careful." SHOULD NOT. Here's what's behind it, who it applies to, and the rollout path the spec now prescribes instead — which, fair warning, is more work than flipping a switch, because it involves actually reading your reports.

Why the strongest policy can hurt you

DMARC's core check is alignment: mail claiming to be from your domain must carry authentication (SPF or DKIM) that ties back to your domain. Forgeries fail this. The problem is that some perfectly legitimate mail fails it too, and the classic case is the one the spec calls out: mailing lists.

When one of your users posts to a discussion list, the list re-sends their message to every subscriber — from the list's servers (so your SPF doesn't cover it), often with a modified subject or footer (so your DKIM signature breaks). To every receiving mailbox provider, that message is now indistinguishable from a forgery of your domain. At p=reject, you've asked those providers to refuse it.

The damage lands on other people first, which is what makes it insidious. Subscribers stop receiving the list. The list software sees bounces and unsubscribes other members. Your user gets quietly dropped from conversations. RFC 7960 documented this whole class of interoperability wreckage back in 2016; DMARCbis is the first time the core spec has drawn the operational conclusion in normative language.

Mailing lists are the sharpest example, but the same shape applies to anything that re-sends mail on your users' behalf: forwarding services, some ticketing systems, "share this article" features, alumni address forwarding. If humans use mailboxes on your domain, some of your legitimate mail takes indirect paths you haven't mapped.

Who this does and doesn't apply to

Read the qualifier carefully: domains that host users who might post to mailing lists. The SHOULD NOT is about general-purpose domains — companies whose employees have mailboxes, universities, anywhere people send mail by hand.

It is not an argument against p=reject in general:

• Domains that send no mail at all should go straight to reject (with v=spf1 -all and an empty DKIM story to match). There's no legitimate mail to lose.
• Pure transactional/marketing sending domains — the email.example.com your ESP sends from — have no human users posting to lists. Reject is appropriate once reports confirm the mail stream is clean.
• Parked domains, defensive registrations, lookalike domains — reject, always.
• And even for general-purpose domains, the spec's position isn't "never." It's "not until you've done the work" — and it spells out the work.

The ramp the standard actually prescribes

RFC 9989's prescription for a general-purpose domain that wants enforcement:

1. Publish p=none with reporting (rua=) and read the aggregate reports for at least a month. This is Monitoring Mode — the spec now defines it as a first-class concept. You're building an inventory: every service that legitimately sends as your domain, and every path your mail takes that breaks authentication.
2. Fix what the reports surface. The SaaS tools sending unauthenticated, the SPF include someone never added, the DKIM key nobody rotated. This is where the actual security improvement happens — enforcement only locks in whatever state you've reached.
3. Move to p=quarantine for an equally long period. Failures now go to spam folders instead of vanishing, which is recoverable — a user can find a quarantined message, and your reports show you what enforcement would have rejected.
4. Compare the two periods. If quarantine didn't hurt anything the reports can see, and your users' mailing-list participation survived, you have an evidence-based case for reject. If you can't tell — because nobody's reading the reports — you don't.
5. If you do publish p=reject, the spec adds a startlingly practical note: consider telling your users that their mailing-list participation may suffer, or set policy that they use a different domain for it.

The month-long clocks aren't bureaucracy. DMARC aggregate reports arrive daily and describe yesterday; rare-but-legitimate senders — the quarterly invoicing run, the annual conference tool — only show up if you watch long enough. A week of clean reports mostly proves you had a quiet week. (New to reports? Here's what's actually inside one.)

The uncomfortable corollary: enforcement without reports is flying blind

Notice what every step of that ramp depends on: someone receiving and reading the aggregate reports. That's the part the checkbox version of DMARC skips. We see domains publish p=reject with no rua at all — enforcement with the instruments removed. The spec's ramp is impossible from that position: you can't compare periods you never observed, and when something breaks — and with indirect mail flows, something eventually does — there is no record of what or when.

If you take one operational rule from DMARCbis, make it this: reporting first, policy second. The reports are how you find out what you'd break before you break it, and afterward they're how you find out what you did break while it's still one vendor's misconfiguration and not a week of lost invoices.

There's also a quiet sweetener in the new spec for cautious domains: the np tag lets you set np=reject for subdomains that don't exist in DNS — forged invoices.yourdomain.com-style names — even while your apex sits at p=none gathering data. Non-existent subdomains have no legitimate mail by definition, so that one really is a free switch to flip. More on it in our DMARCbis overview.

Where this leaves the ladder

The ladder is still real — p=none genuinely stops nothing, and a domain that monitors forever gets the reporting without the protection. What RFC 9989 changed is the shape of the top: enforcement isn't a checkbox you race to; it's a state you earn with evidence, and for some domains the honest evidence-based answer will be quarantine indefinitely, with reject reserved for the subdomains and no-mail domains where it's unambiguous.

If you want to know where your domain sits on that ladder right now — policy, coverage, whether your reporting is actually wired to anything — the free check reads your live DNS and grades the whole setup in plain language. And if the reports themselves are the missing piece, that's specifically what we do.