DMARC's New Rulebook: What RFC 9989 Changes for Senders

For roughly a decade, every DMARC record you have ever published was written against a specification the IETF classified as informational — a document describing what the industry had already agreed to do, not a standard anyone was obliged to follow. That ended in May 2026. The IETF published RFC 9989, RFC 9990 and RFC 9991, which together obsolete RFC 7489 and move DMARC to Proposed Standard status. The draft that spent years being called DMARCbis is now simply DMARC.

The name change matters less than the timing. Mailbox providers have spent two years tightening bulk sender rules, and this refresh lands on top of records that most senders configured once and never touched again. Some of the tags sitting in those records no longer exist in the specification. Nothing broke overnight, and nothing will. But if your DMARC record still reads like it was written in 2019, it now contains instructions the standard has retired.

What actually happened in May 2026

One RFC became three. RFC 9989 carries the core protocol: how domain owners publish policy, how receivers evaluate messages against it, and what happens on failure. RFC 9990 covers aggregate reporting — the daily XML files that show which IPs sent mail as your domain. RFC 9991 covers failure reporting, the near-real-time per-message notices.

Splitting the spec is not cosmetic. Reporting and policy were tangled together in RFC 7489, which made it hard for a receiver to implement one without the other. Separating them lets vendors build to a smaller, clearer target. For senders, the practical effect is that your DMARC record and your report handling are now governed by different documents, and you can reason about them separately.

The three RFCs remain compatible with RFC 7489. A record published in 2018 still validates. This is a clarification of practice rather than a break with it.

What changed in the spec

Three things are worth your attention.

Three tags were removed. The pct tag, which let you apply your policy to a percentage of mail, is gone. So are rf (report format) and ri (report interval). Receivers are expected to ignore tags they do not recognise, so a record still carrying pct=100 will not fail — it will simply be skipped. The pct removal is the one with real consequences for how people work: staged rollouts from p=none to p=quarantine to p=reject were commonly done by ratcheting pct upward from 10 to 50 to 100. That path is no longer in the standard, and the recommended approach is to move policy in whole steps and use aggregate reports to decide when you are ready.

Three tags were added. The np tag sets policy for non-existent subdomains, which is a real gap — attackers spoof subdomains that were never registered, and sp alone did not cleanly cover them. The psd tag flags a domain as a public suffix domain, which matters to registry operators and almost nobody else. The t tag replaces the informal habit of signalling test mode through other means.

The Public Suffix List is out; a DNS tree walk is in. Under RFC 7489, receivers determined your organisational domain by consulting the Public Suffix List — a community-maintained file that was always going to be incomplete and always going to lag reality. RFC 9989 replaces it with an algorithm that walks up the DNS hierarchy looking for a policy record. This is a receiver-side change, so you do not implement it. It mostly affects organisations with deep or unusual subdomain structures, and some .edu and .gov environments where the PSL never described the real hierarchy accurately.

What did not change

The evaluation model is untouched, and this is the part people get wrong when they skim the news coverage.

DMARC still passes when the visible From domain aligns with either an authenticated SPF identifier or an authenticated DKIM signature. Not both. It never required both. Alignment is still strict (exact match) or relaxed (same organisational domain, so mg.example.com and example.com align under relaxed). Passing DMARC still proves authorised use of your domain and nothing more — it does not buy you inbox placement, which reputation, engagement and content still decide.

The bulk sender requirements from Gmail, Yahoo and Microsoft also did not move. If you send 5,000 or more messages a day to Gmail addresses, you still need SPF, DKIM, DMARC, alignment, a complaint rate under 0.30% and one-click unsubscribe. Those thresholds live in provider policy, not in the RFC.

Auditing your DMARC record: five steps

You need DNS access for every domain you send from, and an hour. Work through these in order.

1. Inventory every sending domain. List each domain and subdomain that sends mail as you, and note which stream uses it: marketing, transactional, invoicing, help desk, calendar invites, CRM. Most organisations discover at least one forgotten sender at this step. Any domain still carrying a permissive record but no longer sending should be tightened to p=reject with no rua, or retired.

2. Pull your current record and read it. Query _dmarc.yourdomain.com and look at what is actually published rather than what you think is published. If you see pct, rf or ri, they are now retired syntax.

3. Remove the retired tags. Delete pct, rf and ri. This is a cleanliness fix, not an urgent one — receivers ignore them either way. The exception: if you were mid-rollout and relying on pct to apply a policy partially, understand that behaviour is no longer described by the standard and receiver support for it will erode. Decide on your real policy and publish it whole.

4. Decide whether np earns a place. If you run a flat domain structure with two or three subdomains, sp already covers you and np adds noise. If you run dozens of subdomains, or you have seen spoofing attempts against subdomains that do not exist, np=reject closes a gap that sp does not. Also confirm your sp behaviour is deliberate rather than inherited — plenty of records set a strict root policy and leave subdomains wide open by accident.

5. Read your aggregate reports before you tighten anything. The reports exist to tell you which of your own senders are failing alignment. If you are at p=none and have never opened one, you are not monitoring — you are collecting. Moving to p=reject without reading them is how organisations block their own invoices.

Where people go wrong

• Treating the RFC as a deadline. There isn’t one. The urgency in vendor blog posts is marketing, not standards.
• Publishing p=reject because the news made it sound mandatory. Policy strictness has nothing to do with which RFC you are reading. If your sources are not aligned, p=reject breaks your mail exactly as fast today as it did in 2024.
• Assuming SPF and DKIM must both pass. Still false. Either one, aligned, is a DMARC pass.
• Authenticating the root domain while sending from a subdomain. The most common alignment failure, and the RFC refresh changes nothing about it.
• Forgetting that pct removal changes your rollout playbook. If your runbook says “raise pct to 25% and watch”, that runbook is now describing behaviour outside the standard.

Which platforms make the audit less painful

Authentication depends on your DNS records far more than on your platform. But the tool decides how visible your alignment actually is, and that is what determines whether an audit takes an hour or a week.

Postmark gives you the clearest view of what is happening to your mail. Its setup flow is precise about which records go where, it publishes its own deliverability data openly, and it sells DMARC monitoring as an add-on at $14 a month if you would rather not parse XML yourself. The free Developer plan covers 100 emails a month and paid plans start at $15 a month for 10,000 emails. The catch is that Postmark is deliberately narrow: it bans cold outreach, enforces tight content rules to keep its shared IPs clean, and is not a marketing platform, so you will run something else alongside it.

Mailgun takes the other approach — it signs with your domain in the d= value on its standard authenticated-domain flow, so both SPF and DKIM alignment sit on your side without workarounds. Its free tier allows 100 emails a day, and Basic starts at $15 a month for 10,000 emails. The weak spot is cost at the edges: overages run $1.80 per 1,000 on Basic, additional dedicated IPs are $59 each per month, and Basic keeps only short log retention, which is exactly the data you want when you are chasing an alignment failure.

For marketing rather than transactional mail, MailerLite verifies your SPF and DKIM records for you and reports problems in plain language, which spares you a round trip through a header analyser. Its free plan covers 250 subscribers and 2,500 emails a month, and the Comfort plan starts at $12 a month for 500 subscribers. The trade-off is thinner automation than ActiveCampaign offers and no phone support — chat and email only.

What a finished audit looks like

Three things are true when you are done. Your published record contains no retired tags and a policy you chose deliberately rather than inherited. Your aggregate reports show only senders you recognise, all aligned. And a test message to Gmail, opened with “Show original”, reports SPF, DKIM and DMARC passing on the exact From domain you send from.

At that point the RFC refresh has cost you an hour and bought you a record that matches the standard your receivers are now implementing against. That is the whole story. DMARCbis is dead because it got promoted, and for most senders already authenticating properly, the new documents describe what you were doing anyway. If you are not already there, our SPF, DKIM and DMARC setup guide covers the records from scratch, the deliverability guide covers the reputation work authentication cannot fix, and the best deliverability tools roundup ranks platforms on inbox placement rather than feature count.

Pricing verified 16 July 2026: Postmark, Mailgun and MailerLite list prices and add-ons at their entry tiers. Vendor prices change — confirm on the provider’s own pricing page before you budget.

Sources

1. IETF — RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) — accessed 2026-07-16
2. Mailgun — DMARCbis is dead — accessed 2026-07-16
3. dmarcian — DMARC RFC Guide: Updates You Need to Know — accessed 2026-07-16
4. Google — Email sender guidelines — accessed 2026-07-16