What to check before you publish p=reject

A statement that never arrived

The standard explains the DKIM requirement with a bank, and the example is worth walking through because it is exactly what happens to small companies.

A bank sends a statement to a customer at an alumni address, something like [email protected]. The alumni association does not run mailboxes; it forwards everything to the address the graduate gave them years ago. The same happens with a role address such as [email protected], which forwards to whoever holds the job this year.

When the forwarder passes the statement along, the receiving server sees a connection from the forwarder's IP address, not the bank's. SPF is the DNS list of servers allowed to send as the bank's domain. The receiver checks that IP against the list, and the forwarder is not on it, so SPF fails. Nothing was wrong with the bank's SPF record. Forwarding just moved the message to a server the record does not cover.

DKIM behaves differently. It is a signature the bank's server adds to the message itself, checked against a key in the bank's DNS. The forwarder does not touch it, so the signature still verifies at the final destination. If the bank signed the statement, it passes DMARC on DKIM and arrives. If the bank relied on SPF alone, the statement fails DMARC, and at p=reject the receiver bounces it. The customer never sees the statement. The bank's aggregate reports can show a pattern of failures from the forwarder, but not which message was lost.

That is the whole argument. Forwarding breaks SPF and leaves DKIM alone, and forwarding is everywhere: alumni addresses, role addresses, people who forward their work mail to a personal account. RFC 7960 describes the common ones.

The requirement

So RFC 9989 makes it a rule. A domain that publishes p=reject must not rely on SPF alone for its DMARC pass and must sign its mail with DKIM. In RFC language that is a MUST, the standard's firmest requirement, and it appears twice: in the section on interoperability and again in the list of requirements for full participation. Section 4.5 recommends SPF and DKIM for every domain, and Section 8 lists both as requirements for full participation. At reject the standard adds a separate rule that SPF alone is never enough.

In a small company the stream that fails this test is usually a platform that was added to the SPF record when it was set up and never configured to sign with the company's domain. It signs with its own domain instead, or not at all. In the aggregate reports it shows up as a source that passes SPF and has no aligned DKIM, where aligned means the signing domain is the From domain or shares its organizational domain. Every message that platform sends is one forward away from a bounce. That stream is not ready for reject, and until it signs, neither is the domain.

The mailing list warning

RFC 9989 carries a second warning about reject, and it is worth knowing what it is worth. The standard says a domain whose users post to mailing lists should not publish p=reject. The reason is the same forwarding problem in a different shape: a list resends your message to every subscriber from the list's own server. Where the standard uses should not rather than must not, it means you may proceed once you understand the cost.

The standard is candid about that cost. In the ten years since the large consumer mailbox providers started publishing p=reject, mailing list software has adopted workarounds that rewrite the From address on relayed messages so they pass DMARC under the list's own domain. The RFC calls those workarounds far from ideal and firmly established. ARC, a newer mechanism meant to let lists stop rewriting, had not caught on at publication.

So for most lists, a person posting from a reject domain is fine, because the list repairs the message before it goes out. What remains is the list that never adopted rewriting. There, the receiver rejects the relayed post, the list software reads the rejection as a dead address, and the subscriber is quietly dropped from the list. That is a real cost. For most companies it is also a small one, and most look at their reports, decide the occasional lost list post is acceptable, and publish reject. That is a fair reading of the standard, not a violation of it.

Plan as if reject means reject

The standard also tells receivers not to reject a message solely because the sender's policy says reject, and to treat failing mail as quarantine when they have nothing else to go on. Then it admits, in the same section, that few receivers do any of that, and that mail relayed through lists without a rewritten From is frequently rejected under p=reject. Take the admission at face value. Receivers are not going to soften your policy for you.

The one place you will see a receiver deviate is the aggregate report itself, which has a field for it, PolicyOverride. If a receiver decides to deliver mail your policy says to reject, that is where it tells you.

Why many domains skip quarantine

Under DMARC, quarantine and reject both keep failing mail out of the inbox at receivers that honor your policy. The difference is where the mail goes instead. Quarantine sends it to the spam folder, where the recipient can still open it and be fooled by it. Reject refuses the message during delivery, so the receiver never sends a bounce of its own to a forged address. For forwarded mail, the forwarder's server usually returns the bounce, and the failure shows up in your aggregate reports as mail from the forwarder's IP address. For a domain that exists to be trusted, a bank, a payroll provider, a store sending order confirmations, that difference is the point of DMARC, and reject is the destination.

The standard prescribes a quarantine stage on the way there, so you can see what receivers do with failing mail before you go to reject. In my experience most domains skip it. They remediate at p=none until the reports are clean, then publish reject, and that works because the aggregate reports at none already show, for every source, whether it passed on DKIM or only on SPF. Once every source that belongs to you shows aligned DKIM, the quarantine stage has little left to tell you.

Quarantine earns its place in one situation: a domain with a stream that cannot be signed yet. Reject is off the table for that domain by the standard's own rule, and quarantine is as far as it can go until the stream is fixed. A domain sitting there is not finished. It is blocked on one sender.

Which policy for which domain

When a domain is ready

List every domain and subdomain that sends mail and give each its own DMARC record. For each one, readiness is two questions. Does every source in the reports that belongs to you show an aligned DKIM pass, not just an SPF pass? And has the list of sources stopped changing?

The second question is the one that takes time. The standard says the process can take many months depending on how often a domain sends, and it often takes longer than that, because a system that sends once a quarter does not appear in the reports until it sends. Waiting costs nothing. The standard requires receivers to leave mail handling unchanged under p=none, and the bulk sender rules at Google, Yahoo and Microsoft require a DMARC record but accept p=none. Nothing about inbox placement forces the move to reject. The reports tell you when.

The guides are right that reject is where a domain should end up. They leave out the condition the standard now attaches to it. A domain at p=reject with a stream on SPF alone is not finished. It risks losing mail whenever a message is forwarded to a receiver that enforces the policy, and the standard says it should not be there.

Where this comes from

RFC 9989, Section 7.4, has the bank example, the DKIM requirement, the mailing list warning, the staging advice, and the admission about receivers. Section 8 repeats the DKIM requirement and the receiver rule as conformance requirements. Section 5.4 covers what receivers do with p=none and the PolicyOverride field. Section 4.5 recommends SPF and DKIM together. Section 5.1.7 says enforcement may take many months. Section 3.2.9 defines enforcement and Section 7.2 explains why rejecting during delivery beats bouncing. RFC 7960 catalogs indirect mail flows, RFC 7505 defines the null MX, and RFC 8617 defines ARC.