RFC 9989 landed in May and retired RFC 7489. It tightens what domain owners must prove, and — for the first time — tells mailbox providers explicitly that a reject policy is not on its own a reason to destroy a message.
In May 2026, DMARC stopped being a convention that everyone agreed to follow and became an actual internet standard. RFC 9989 replaced RFC 7489, which had governed the protocol since 2015, and it also absorbed the reporting extensions that had been living separately. If you send mail at any scale, the document now describes your obligations in language a lawyer could hold you to.
The part worth your attention is not the tightening. It is a sentence aimed at the receiving side.
RFC 9989 is unusually direct about what full participation means. A domain owner who wants to claim it now must satisfy all of the following, and these are normative requirements rather than suggestions:
That last requirement is the quiet one. Teams often reach for SPF first because it is the easiest record to write, and then discover — usually somewhere between a forwarding chain and a mailing list — that SPF is the authentication method most likely to break in transit. DKIM survives forwarding because it signs the message; SPF breaks because it validates a path that no longer exists. A reject policy built on SPF is a reject policy built on the weakest link you have.
The standard also states what mailbox providers must not do. Among the conformance requirements for receivers: they must not reject messages solely on the basis of a p=reject policy for the author domain.
A reject policy tells the world what you would like to happen. It was never a guarantee that it would.
RFC 9989, Section 8Read carefully, this is a statement about what p=reject has always meant. It is a declared preference about mail that fails authentication — not an instruction that overrides every other signal a receiver holds. In practice that was already true; mailbox providers have always balanced policy against reputation, prior behaviour, and their own thresholds. What changed is that the balance is now written into the standard rather than left to each provider's judgement.
For a sender this is mostly reassuring, and slightly humbling. Your policy record is one input among several. It does not exempt you from the work of being a sender that people engage with, and it never did.
The standard asks receivers to send aggregate reports at least daily. For years, aggregate reports were the thing teams enabled and then never opened — a weekly XML dump into a mailbox nobody owned. That is exactly the pattern the standard now rules out, because it explicitly requires a human-adjacent process at the other end: a mailbox that receives them, and a domain owner who collects and analyses the content.
Pull your aggregate reports for the last thirty days and answer three questions. Which sending sources are failing alignment? Which of them are sources you have forgotten about — an old ESP, a ticketing tool, a marketing platform someone piloted in 2023? And is your policy published at the organizational domain as well as the subdomain you happen to send from?
Most teams find at least one forgotten sender, and a policy that only exists at a subdomain. Both are cheaper to fix now than after an incident.
Every one of these requirements is boring, and boring is the point. Authentication is not a growth lever; it is the floor. What RFC 9989 really does is remove the last excuse for treating the floor as optional, and it removes a specific comfort blanket — the belief that declaring p=reject was itself a form of protection.
The team that benefits most is not the one with the most sophisticated DMARC setup. It is the one that knows, today, every system that sends mail on its behalf. That inventory is the actual deliverable, and it has been for years. The RFC simply wrote down the reason why.
Written by the team at LMR — a senior lifecycle marketing studio working in Iterable, Braze, Klaviyo and the tools you already run.
Start a project ↗