DMARC Is Now a Proposed Standard: RFC 9989 and the Ten-Minute Audit for Customer.io Senders

In the first week of April 1969, a UCLA graduate student named Steve Crocker needed to write up his team's design notes for the software that would link the first computers on the ARPANET. He worried that anything too official-sounding would read as a claim of authority he didn't have—he was, by his own account, drafting in a bathroom in the small hours so as not to wake his friends. So he gave the memo series a deliberately modest name: Request for Comments. RFC 1, "Host Software", went out on 7 April 1969.

The modest name turned out to be the clever part. Because nothing was ever declared a standard from on high, people just built things, wrote down what worked, and let agreement accumulate until it was undeniable. Fifty-seven years later, that memo series is still how the internet decides what counts as settled—usually long after everyone has already settled on it.

DMARC has just had that moment: the practice came first, and the paperwork has caught up.

In May 2026 the IETF published RFC 9989, which replaces the original DMARC specification and puts DMARC on the Standards Track for the first time in eleven years. If you send through Customer.io, you've likely had a vendor email or two treating this as a scramble. It mostly isn't. Here's what actually changed, what didn't, and the short audit worth running on your record this week.

What happened in May: three RFCs replaced one

Three documents now do the job the old one did alone. In May 2026 the IETF published RFC 9989, the core DMARC protocol, alongside RFC 9990 (aggregate reporting) and RFC 9991 (failure reporting), together replacing the 2015 specification, RFC 7489.

First, the term itself, because the rest of this only makes sense once it's clear. DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the DNS record that tells a receiving mail server what to do with a message that claims to come from your domain but fails authentication. The server can leave the message alone, send it to spam, or reject it outright. It has run the internet's anti-spoofing plumbing for over a decade. Until now, though, it lived in an Informational RFC. As Red Sift notes, the original spec was published as an Informational RFC in 2015, and "Informational" means what it sounds like: a description, not an agreed standard.

RFC 9989 changes the status. All three new documents sit on the Standards Track as Proposed Standards, the first rung on that ladder. The spec has been through community review, reached rough consensus, and is judged stable enough to build on. After eleven years, the thing your inbox placement leans on has one agreed definition rather than a dozen vendors' readings of one. RFC 9989 also folds in an older experiment, RFC 9091, which covered public-suffix domains, so the whole picture now sits in one place.

What changed in the record grammar

The visible changes to a DMARC record are small: three tags retired, one added for testing, two added for large domain estates, and one under-the-hood change to how receivers find your policy.

The retired tags are pct, rf and ri. The pct tag let you apply your policy to only a percentage of failing mail, a way to ease into enforcement by telling receivers to quarantine, say, 10% of failures for now. In practice it produced inconsistent enforcement across receivers, so it's gone. Its job moves to a new t tag, for test mode. t=y signals that you're still testing and want receivers to hold back on full enforcement, while t=n, the default, means apply the policy as written. The rf (report format) and ri (reporting interval) tags were rarely touched and have also been dropped.

Under the hood, the bigger shift is how a receiver works out which domain owns your policy. The old spec leaned on the Public Suffix List, a hand-maintained file of suffixes (.com, .co.uk, .github.io) that every receiver had to keep a current copy of. RFC 9989 replaces it with a DNS tree walk: the receiver climbs your domain's DNS one label at a time to find the policy, reading it live from DNS instead of a static list. Mailgun's write-up is blunt that this mostly affects large or complex domain structures such as some .edu, .gov, or public-suffix environments. For you as a sender, it changes nothing about the record you publish. It's a receiver-side mechanism.

Who actually needs the new tags

Almost certainly not you. The two new tags, psd and np, exist for a specific kind of operator.

psd (public suffix domain) is for the organisations that run public suffixes: a government registrar looking after thousands of .gov.uk subdomains, or a platform handing subdomains to its customers. It tells the tree walk where an organisational boundary sits. np (non-existent subdomain policy) lets those same estates set a policy for subdomains that don't exist at all, to shut down spoofing of made-up addresses.

If you send from one domain and a Customer.io sending subdomain, neither applies. Mailgun says it plainly: most senders are unlikely to need psd, and np matters only for organisations managing large or complex subdomain structures. Adding either because a blog post told you to is how you end up debugging a problem you invented.

What did not change

The part that decides whether your mail passes is untouched. DMARC still passes when your visible From domain aligns with either an authenticated SPF result or an authenticated DKIM signature. Not both. Either. Alignment is still strict (an exact domain match) or relaxed (the same organisational domain, so email.yourdomain.com lines up with yourdomain.com). If you want the ground-up version of how SPF, DKIM and DMARC fit together, our complete email deliverability guide walks through it.

Your policy tags work exactly as before. p=none, p=quarantine and p=reject mean what they always meant, your sp= subdomain policy still applies, and your rua= reporting address keeps collecting reports. RFC 9989 doesn't break existing records and doesn't require you to republish anything. If your DMARC was set up and enforcing on the day before the RFC published, it was still valid the day after.

One more reassurance, because you'll see it claimed otherwise: receivers are not rejecting records that still carry pct, rf or ri. The spec expects receivers to ignore obsolete tags, not trip over them. Clearing them out is housekeeping, not a fire drill.

The ten-minute audit for a Customer.io sender

Here's the whole to-do list. It comes to about ten minutes, and most of it is looking rather than changing.

Pull your current record first. Query the TXT record at _dmarc.yourdomain.com. That's where your policy lives, on your root domain, not on the Customer.io sending subdomain. Then work through four checks:

1. Look for retired tags. If pct, rf or ri appear in the record, delete them. If they don't, and most records built in the last few years won't have them, you've just finished the only edit this whole change asks of you.
2. Confirm alignment on your sending subdomain. When you authenticate your domain with Customer.io, you add SPF and DKIM records on a sending subdomain, plus an MX record that gives that subdomain its own Return-Path. Both identifiers then align with your From domain under relaxed alignment. Send yourself a campaign and check the headers show a DMARC pass, or read it off a recent aggregate report.
3. Check your sp= is deliberate. If you publish a subdomain policy, make sure it says what you mean. If you don't, subdomains inherit your p= policy, which is fine for most senders and worth knowing for the rest.
4. Keep reading your aggregate reports. Your rua= reports are the early-warning system for a new sending source or a stream that's drifted out of alignment. RFC 9990 standardises their format now, but your habit shouldn't change: skim them, don't just archive them.

That's the audit. If you were hoping for something you could bill an afternoon to, this isn't it, and that's the point.

The real message: p=none was meant to be temporary

The most useful thing in RFC 9989 isn't a tag at all. It's the posture. The standard treats monitoring mode as a starting line, not a place to live.

p=none tells receivers to enforce nothing and simply send you reports. It's the right first move: you watch your aggregate reports, find every legitimate sending source, get them aligned, and only then turn on enforcement. It was never meant to be the destination. Plenty of domains have parked at p=none for years, collecting reports nobody opens.

The mailbox providers already made that stance awkward. Gmail and Yahoo began requiring a DMARC record from bulk senders in 2024, and Microsoft now rejects unauthenticated Outlook mail from high-volume senders, on top of holding everyone to a tighter Gmail spam-rate ceiling. RFC 9989 adds the protocol's own voice to that pressure. Red Sift's read is that senders sitting in monitoring mode indefinitely are increasingly out of step with where the industry is heading, and that's the honest summary.

So the audit has an unofficial fifth step, and it has little to do with the new RFC. If you're at p=none and you've been there a year, the standard is now saying quietly what Gmail said out loud in 2024. Once your reports are clean, move to quarantine, then reject. Knowing when a standards change is worth reacting to is its own skill. You probably don't need a VMC for BIMI yet, and you probably do need to leave p=none eventually. RFC 9989 is the second kind of nudge, not the first.

RFC 9989 is good news reported badly. The protocol your deliverability rests on finally has a real definition, and the price of admission for most Customer.io senders is a ten-minute look and, at most, deleting a tag you probably don't carry. Ignore the countdown timers. Read your reports, leave p=none when the reports say you can, and get on with your week.

Frequently asked questions

Do I need to change my DMARC record because of RFC 9989?

For most senders, no. RFC 9989 doesn't break existing records or require republishing. The only concrete edit is cleanup: if your record still carries pct, rf or ri, delete them. If it doesn't, you have nothing to publish.

Is the pct tag still valid in DMARC?

No, pct is retired in RFC 9989. Receivers are expected to ignore it rather than reject a record that still has it, so nothing breaks overnight, but its function is gone. If you were using it to phase in enforcement, the new t=y test-mode tag is the replacement.

What is the DNS tree walk in the new DMARC?

The DNS tree walk is how a receiver now finds your DMARC policy: it climbs your domain's DNS one label at a time, reading the policy straight from DNS. It replaces the Public Suffix List, a static file receivers used to maintain. It's a receiver-side mechanism and changes nothing about the record you publish.

Does the new DMARC standard affect my Customer.io sending domain?

No. Your DMARC record stays at _dmarc.yourdomain.com on your root domain. Customer.io keeps authenticating on a sending subdomain with SPF and DKIM, and those identifiers still align with your From domain under relaxed alignment exactly as they did before.

What is the difference between RFC 7489 and RFC 9989?

RFC 7489, from 2015, was an Informational RFC, meaning a description of DMARC rather than an agreed standard. RFC 9989, from May 2026, is a Standards-Track Proposed Standard that replaces it and folds in the older public-suffix-domain extension, RFC 9091. The core mechanics are the same; the status and the clarity are new.

Is p=none still acceptable in 2026?

As a starting point, yes. As a permanent setting, increasingly not. p=none is monitoring mode, meant for the period while you find and align your sending sources. Red Sift's read of the new standard is that indefinite monitoring is out of step with where enforcement is heading, so treat p=none as a phase, not a home.

What are the np and psd tags for?

They're for large or complex domain estates. psd (public suffix domain) is for operators who run public suffixes, like a registrar managing many subdomains. np sets a policy for non-existent subdomains. Mailgun notes most senders are unlikely to need psd, and np matters only for organisations managing large subdomain structures. A single-domain Customer.io sender needs neither.

Do I need to do anything about RFC 9990 and RFC 9991?

No action is required. RFC 9990 standardises the format of aggregate reports (the rua data you already receive), and RFC 9991 does the same for failure reports. Keep reading your aggregate reports as usual. Their delivery and format are now better defined, but you don't publish anything new to get them.

Should I turn on failure reports (ruf) now?

Not without understanding the trade-off. RFC 9991 states that failure reports can include full message headers and body content, which may contain personally identifiable information. That has privacy implications for you and your recipients, so enable ruf deliberately, if at all, rather than by default.

Will my p=quarantine or p=reject policy still work?

Yes. Policy tags are unchanged in RFC 9989. p=none, p=quarantine and p=reject behave exactly as they did under RFC 7489, and so does your sp= subdomain policy. Nothing about your enforcement level needs republishing.

Is DKIM2 part of this change?

No. DKIM2 is a separate protocol effort, and Mailgun is explicit that it remains separate and unsettled for now. RFC 9989 doesn't require it, and today's DMARC still evaluates SPF and DKIM as before. Treat anything you read about DKIM2 as a different, future conversation.

Sources

• RFC 1: Host Software. S. Crocker, IETF / RFC Editor, 7 April 1969.
• How the Internet Got Its Rules. Stephen D. Crocker, The New York Times, 6 April 2009.
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC). IETF / RFC Editor, May 2026.
• DMARC is now a Proposed Standard: What it means for you. Red Sift, 21 May 2026.
• Mailgun: DMARCbis is dead. Long live DMARC. Mailgun, 27 May 2026.
• Domain Authentication. Customer.io Docs.