DMARCbis and Mailing Lists: Is p=reject Still Right?

Yes, for domains that only send machine mail. For a domain where people have mailboxes and post to mailing lists, RFC 9989 now says in normative language that you SHOULD NOT publish p=reject. For most indie builders the fix is structural rather than a retreat: send product mail from a subdomain at p=reject, and keep the human-mailbox domain at a policy that fits how those humans use email.

This isn't a "don't enforce" post. p=quarantine is enforcement. The question is which policy goes on which name.

What RFC 9989 actually says

The guidance is in RFC 9989 §7.4 (Interoperability Considerations). It opens by naming the problem:

"the use of "p=reject" can be incompatible with and cause interoperability problems to indirect message flows such as "alumni forwarders", role-based email aliases, and mailing lists across the Internet."

Then it states the sender-side requirement:

"It is therefore critical that domains that publish "p=reject" MUST NOT rely solely on SPF to secure a DMARC pass and MUST apply valid DKIM signatures to their messages."

And the part that matters for human mailboxes:

"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". Any such domains wishing to publish "p=reject" SHOULD first take advantage of DMARC aggregate report data for their domain to determine the possible impact to their users, first by publishing "p=none" for at least a month, followed by publishing "p=quarantine" for an equally long period of time, and comparing the message disposition results. Domains that choose to publish "p=reject" SHOULD implement policies that their users not post to Internet mailing lists and/or inform their users that their participation in mailing lists may be hindered."

RFC 7489 was Informational. RFC 9989 is Standards Track, so this SHOULD NOT carries more weight than the old advice did.

Why indirect mail breaks

When a forwarder or list relays your message, it sends from its own IP. §7.4 spells out the SPF side: the message "will most likely fail SPF checks unless the RFC5321.MailFrom address is rewritten by the relaying MTA", while "DKIM signatures will generally remain valid in these relay situations."

Mailing lists are harder than plain forwarders because many of them modify the message. A [list-name] subject tag or an unsubscribe footer changes signed content, so your DKIM signature stops verifying too. With SPF and DKIM both failing, DMARC fails, and a p=reject from your domain asks every subscriber's provider to refuse your post.

The RFC also records how lists adapted. §7.4: "mailing list software has all adopted workarounds to make the From: header line DMARC aligned", either by using the list's own address or by rewriting yours into something like bob=example.com@user.somelist.example. So a well-maintained list today usually won't bounce your post. Forwarders, aliases, and older list setups are where p=reject still hurts. §7.4 names ARC as "a prominent example" of the technical fixes that avoid rewriting, and notes that "none of the methods have become widely used."

The receiver-side rule

RFC 9989 also puts a rule on receivers, in the same section:

"It is therefore critical that Mail Receivers MUST NOT reject incoming messages solely on the basis of a "p=reject" policy by the sending domain. Mail Receivers must use the DMARC policy as part of their disposition decision, along with other knowledge and analysis. [...] In the absence of other knowledge and analysis, Mail Receivers MUST treat such failing mail as if the policy were "p=quarantine" rather than "p=reject"."

Read the qualifiers carefully. It says "solely" and "in the absence of other knowledge and analysis". It does not say p=reject now means quarantine. Large receivers have plenty of other knowledge (reputation, content, history), and they are free to reject when that knowledge backs it up.

The RFC is also candid about how much this will change:

"In practice, despite this advice, few Mail Receivers apply any mitigation techniques when receiving indirect mail flows, few organizations consider the effect of DMARC policies on their users' indirect mail, and it is unlikely that any advice in this document will change that."

So don't publish p=reject on a human-mailbox domain expecting receivers to soften it for you. Pick the policy you actually want applied.

What to do as an indie builder

Split machine mail from human mail

The common setup is one domain doing everything: Google Workspace mailboxes on example.com, and Resend or Postmark sending receipts and password resets from hello@example.com. That puts two very different traffic types under one policy.

Move product mail to its own subdomain, and send from an address on it, for example noreply@send.example.com or hello@mail.example.com. The subdomain part is what matters. DMARC evaluates the domain in the From header, so a subdomain record only covers mail that is actually From that subdomain. A record on send.example.com does nothing for mail From example.com.

Then publish separate records:

_dmarc.example.com       "v=DMARC1; p=quarantine; sp=reject; np=reject; rua=mailto:you@your-rua-address"
_dmarc.send.example.com  "v=DMARC1; p=reject; rua=mailto:you@your-rua-address"

Where sp and np fit

When there's no record at the exact From domain, the receiver falls back to the organizational domain's record. RFC 9989 §4.10.1: the policy "is taken from the "sp" tag (if any) if the Author Domain exists or the "np" tag (if any) if the Author Domain does not exist."

In the example above:

• p=quarantine covers mail From example.com itself, where the humans are.
• sp=reject covers subdomains that exist but have no record of their own. Nobody posts to lists from billing.example.com, so reject is fine there.
• np=reject covers names that don't exist at all, like invoices-secure.example.com. Nothing legitimate can send from them, so reject has no downside.
• send.example.com has its own record, so its own p=reject applies directly.

Why p=reject is still right for sending-only subdomains

Everything in §7.4 about mailing lists is about "domains that host users who might post messages to mailing lists." A transactional subdomain hosts no users. Its mail goes straight from your ESP to the recipient's provider, so the indirect-flow problem mostly doesn't apply.

The one requirement §7.4 puts on every p=reject domain is DKIM. Developer ESPs like Resend, Postmark, and Amazon SES sign with a key you publish under your own domain, so aligned DKIM comes with finishing their domain verification. Confirm it in your reports before you tighten: every row for your ESP's IPs should show a DKIM pass for your domain, not for the ESP's shared domain.

The human-mailbox domain

For example.com itself, you have two reasonable options:

• Stay at p=quarantine. It still sends spoofed mail to spam. If you or your team post to open source lists, standards lists, or community Google Groups, this is the setting RFC 9989 points you to.
• Go to p=reject deliberately. If it's just you, your mailbox mostly sends direct mail, and you accept that an occasional list post or forwarded message may not arrive, reject is a defensible call. Follow the §7.4 sequence: a month at p=none, a month at p=quarantine, then compare dispositions in your reports before moving.

If you're still weighing the two, the p=reject vs p=quarantine decision covers the deliverability side in more detail.

Testing a policy change

To trial p=reject on the org domain without committing, RFC 9989 adds the t tag. t=y asks receivers to apply the policy one level lower (§4.7), so p=reject; t=y gets quarantine treatment. RFC 7489 receivers ignore t, so publish it with pct=0 during the transition:

v=DMARC1; p=reject; t=y; pct=0; rua=mailto:you@your-rua-address

What to look for in your reports

Aggregate reports can show indirect mail directly. RFC 9990 §3.1.6 defines override reasons that a receiver can attach to a row, including mailing_list ("Local heuristics determined that the message arrived via a mailing list") and trusted_forwarder. Rows from IPs you don't recognize that pass DKIM but fail SPF are another sign of forwarding.

Run a few weeks of reports through the DMARC XML Analyzer before moving your org domain to reject. If those rows show up for mail your people actually sent, that's the §7.4 impact the RFC tells you to measure first. You can check what each of your names publishes today with the DMARC Record Checker.

DMARCdrift is free for one domain. Point your rua= address at us and the first digest arrives within a week.

Get started free →