Every outbound team has a domain spreadsheet. Twenty, forty, sometimes a hundred and fifty sending domains, each with the same three DNS records pasted in at provisioning time and never looked at again. That paste dates from whenever the team first set up, and it encodes assumptions from a specification the IETF retired this year. The records still resolve. Mail still flows. Nothing has broken loudly, which is exactly why nobody has checked.
Cold Email DMARC Was Written Against A Spec That Is Gone
The document set published in May is worth naming precisely, because the vendor coverage has been loose about it. RFC 9989 is the core protocol, published as a Standards Track document and obsoleting both RFC 7489 and RFC 9091. RFC 9990 covers aggregate reporting. RFC 9991 covers failure reporting. Together they are what practitioners have been calling DMARCbis for roughly six years, and the long gestation is part of why the publication landed so quietly. People stopped waiting for it.
The quiet matters more for outbound than for anyone else, because outbound owns more DNS than anyone else. A brand team manages one authenticated domain and maybe a subdomain for its ESP. An outbound programme manages a fleet: lookalike domains, redirect domains, a warm-up pool, and whatever was inherited from the last agency. Every one of those carries a DMARC record that somebody wrote once, and the fleet is large enough that nobody re-reads it. We have made the argument before that outbound teams pick the wrong threshold to measure their sending domains against. This is the same failure in a different register: the configuration is not wrong on its own terms, it is answering a question the standard no longer asks.
Two of those numbers come from Valimail's annual study, published in February 2026 across data from more than 100,000 companies. Valimail sells DMARC management, so read the framing with that in mind. The raw split is still useful: adoption at 78%, enforcement at 42%, a 36-point gap between having a record and having a record that does anything. That gap is the population this change is aimed at, and outbound fleets live disproportionately inside it.
The Tree Walk Changes Which Record Governs Your Sending Domains
Under the old specification, a receiver deciding which DMARC policy applied to a message had to work out the Organizational Domain, and it did that by consulting the Public Suffix List. The PSL is a community-maintained text file. RFC 9989 is candid about the consequence, noting that the previous version mandated no requirement for a specific list and acknowledged the possibility of interoperability issues caused by receivers choosing different ones. Two receivers, two copies of the list, two different answers about whose policy governs your mail.
The replacement is a procedure RFC 9989 calls the DNS Tree Walk. Instead of looking your domain up in a list, the receiver queries upward through the name itself, one level at a time, until it finds a policy record. The spec caps the work: author domains with more than eight labels do not result in more than eight DNS queries. The effect is that policy discovery becomes a DNS question with a DNS answer, and the authority moves from a file somebody else maintains to records you publish.
For a single corporate domain this is a tidying-up exercise. For an outbound fleet it is a structural change, and it cuts both ways. The good half: a subdomain architecture is now genuinely governable, because you can publish a record at the sending subdomain and know it will be found, rather than hoping the receiver's copy of a list agrees with your intent. The bad half: a permissive record sitting at the parent now reliably governs every sending subdomain beneath it that lacks one of its own. Under the old arrangement that inheritance was probable. Under the tree walk it is deterministic, and determinism cuts against you when the inherited record says p=none.
That is the part worth acting on this quarter, because it quietly reprices the long-running argument about lookalike domains versus subdomains. A fleet of unrelated lookalike domains means a fleet of independent policy records, each needing its own audit. A subdomain architecture under one parent means one record governs the lot, discoverable by query, with per-subdomain overrides where you want them. The deliverability case for lookalikes has always rested on reputation isolation. The governance case just moved against them, and governance is what gets audited when a receiver decides your programme looks like a spoofing surface.
Losing pct Removed The Half Measure Everyone Quietly Relied On
The pct tag let a domain owner publish a strict policy while asking receivers to apply it to only a percentage of failing mail. It was the standard on-ramp: publish reject at pct=10, watch the reports, walk it up. RFC 9989 removes it, and Red Sift's Faisal Misle, writing the day the documents landed, put the practical reading plainly in his note on the new standard: audit out any reliance on pct, because enforcement now applies to all traffic or none of it. The replacement for the ramp use case is the t tag, a test-mode signal that asks receivers to apply one step below your stated policy while you validate.
| TAG | STATUS UNDER RFC 9989 | WHAT IT WAS DOING FOR OUTBOUND | THE MOVE NOW |
|---|---|---|---|
| pct | Removed | Let a fleet publish a strict-looking policy while enforcing on a slice of failing mail, usually during ramp | Strip it from every record. A leftover pct is not a safety net, it is a comment. Your published policy is already fully live |
| t | New | Nothing, it did not exist | Use t=y for a genuine validation window. It requests handling one level below the stated policy rather than a percentage of it |
| np | Policy tag for non-existent subdomains | Nothing. Invented subdomains under your sending domains were governed by whatever the parent happened to say | Set np=reject wherever you send. A subdomain that does not exist has no legitimate mail and no ramp to protect |
| sp | Clarified scope | Ambiguous. Teams assumed it covered everything below the domain | Read it as covering existing subdomains of the Organizational Domain, not the domain itself. Confirm your sending subdomain inherits what you intended |
| rf and ri | Removed | Report format and interval knobs nobody tuned and most parsers ignored | Delete them. They add noise to a record you now want short enough to audit at a glance |
| psd | Formalised, defaults to u | Not applicable to normal senders | Leave at the default and let the tree walk resolve it, unless you actually operate a public suffix |
The np tag is the one outbound teams should be most interested in, and it is the one getting the least attention. RFC 9989 defines it as the assessment policy for non-existent subdomains, applying only to those and not to existing subdomains or the domain itself. Think about where impersonation of an outbound programme actually happens. Not at your sending subdomain, which has records and reputation. At invented ones, which have neither, and which previously fell back to whatever the parent said. If the parent said p=none, they were unguarded. np=reject closes that specific hole without touching a single live sender, which makes it the rarest thing in deliverability work: a change with upside and no ramp risk.
Cold Email DMARC Enforcement Is Now The Stated Direction
There is a reasonable objection to all of this, and it deserves a straight answer rather than a dismissal. Nothing in RFC 9989 breaks an existing record. A domain at p=none today will be at p=none tomorrow, receivers will keep accepting mail, and no deadline forces a change. On the letter of it, the objection is correct.
It is still the wrong read, for a reason that has nothing to do with the document and everything to do with who follows it. Receiver policy has moved in one direction for three years: Google and Yahoo's bulk sender requirements, then Microsoft's, each tightening what unauthenticated or loosely authenticated mail is worth. When the standards body those receivers participate in publishes a Standards Track document that deletes partial enforcement and frames monitoring mode as a stage rather than a destination, it is describing where enforcement is going next. The teams that got caught out by Microsoft's reporting changes were not caught by a rule. They were caught by a direction they had decided not to read.
DMARC adoption against actual enforcement. Figures from Valimail's 2026 State of DMARC report, February 2026, drawn from data across more than 100,000 companies. Valimail sells DMARC management, so treat the framing as interested and the split as directional.
Seven percentage points of enforcement growth across a year is not a stampede. It is a slow tide, and slow tides are the ones that catch people, because there is never a week when moving becomes urgent. The outbound-specific version of the risk is worse than the corporate one: a brand domain at p=none that gets spoofed generates a support ticket, while a sending domain at p=none that gets spoofed generates complaints against a reputation you are actively trying to build, on a domain whose only job is to be trusted by strangers.
Worth separating two things that get conflated here. Authentication posture is not a compliance posture. A domain at p=reject with immaculate alignment can still be sending mail that breaks the rules in the recipient's country, which is a different audit with a different decision tree. Fixing your records does not fix your consent basis, and nobody should walk out of this thinking it does.
Audit The Records Before A Receiver Does It For You
The work here is small and boring, which is the only reason it does not get done. For most fleets it is an afternoon with a DNS export and a script.
One caveat on scope. None of this is a deliverability lever in the sense that outbound teams usually mean. Fixing a DMARC record will not lift your reply rate, and anyone selling it that way is overselling. Authentication is a gate, not a dial: it decides whether you are eligible to be judged on your content, and nothing beyond that. The actual reply-rate work stays where it was, in list quality, targeting and the warm-up discipline behind your sending pool. We make the same point to every outbound engagement we run, and it applies with particular force to B2B SaaS teams who have already automated everything downstream of the send and are looking for one more knob.
Do this next. Export the DMARC record for every domain in your sending fleet into one column of a spreadsheet, then add a second column for the parent that a tree walk would resolve to. Two things will fall out within the hour. You will find records carrying pct, which are no longer doing what whoever wrote them believed, and you will find sending subdomains whose governing policy lives somewhere nobody on the team has thought about in a year. Neither will be breaking anything today. That is precisely the window you have, and windows like this close when a receiver decides they should, not when you are ready.
See where you are cited today
A free snapshot audit of your rankings and AI citations before we ever talk.
Josh leads work at the intersection of SEO and generative engines at Something Inc., helping B2B brands get ranked and cited across every major AI engine.