Mailgun: DMARCbis is dead

Mailgun: DMARCbis is dead. Long live DMARC. 

The updated DMARC standard is here. Here’s what changed, what didn’t, and what it means when you send through Mailgun. 

Just when you were getting comfortable with new DMARC policies…
In May 2026, the IETF published a new DMARC RFC set that replaces RFC 7489: RFC 9989 (core DMARC), RFC 9990 (aggregate reporting), and RFC 9991 (failure reporting). DMARCbis, previously known as the draft “next version of DMARC”, is now the published DMARC standard. 

Why does this matter?
This change matters because mailbox providers increasingly expect authenticated, aligned mail as baseline sender behavior. The updated DMARC RFCs do not radically change those expectations, but they clarify and formalize practices that many senders and ESPs are already operating under today. 

For Mailgun senders, this is worth understanding, but it’s not a “tear out your DNS by Friday” moment. The fundamentals are the same: authenticate your mail, keep identifiers aligned, monitor your reports, and fix streams that don’t line up. 

The updated standard is cleaner, more explicit, and better aligned with how large-scale email authentication is operated in production. 

The updated spec mostly refactors and clarifies; it doesn’t change DMARC’s core “aligned SPF or aligned DKIM” rule. 

• Three RFCs instead of one: RFC 9989 covers policy and alignment, RFC 9990 covers aggregate reports, and RFC 9991 covers failure reports. 

• DNS Tree Walk for policy discovery: receivers can walk up the DNS hierarchy instead of leaning on a static public‑suffix list, which is especially helpful for complex domain trees and public suffix operators. 

• Tag changes: new tags like np (non‑existent subdomain policy) and psd (public suffix domain) are added; obsolete tags like pct, rf, and ri are removed; a new t tag better describes testing behavior. 

If you maintain DMARC records, you’ll eventually want to remove the retired tags and consider whether np and psd make sense for your domain portfolio. 

The part Mailgun customers should keep top‑of‑mind: 

DMARC still passes when the visible From domain aligns with either SPF or DKIM, not only when both align. 

DMARC still evaluates whether the Author Domain (visible From) aligns with an authenticated identifier from: 

• SPF (MAIL FROM / Return‑Path domain) 

• DKIM (d= signing domain) 

Alignment remains strict (exact match) or relaxed (same organizational domain, such as mg.example.com and example.com). 

It’s also worth separating domain alignment from IP reputation. Shared versus dedicated IPs affect reputation management, warmup, and troubleshooting visibility, but they do not fundamentally change how DMARC alignment works. Whether you send on shared or dedicated infrastructure, DMARC still evaluates whether your visible From domain aligns with authenticated SPF or DKIM identifiers. 

DMARC continues to rely on “SPF or DKIM with alignment,” not “SPF and DKIM and DMARC all passing independently.” Passing DMARC still doesn’t guarantee inbox placement; it proves authorized use of the domain, while reputation, engagement, and content still decide where the message lands. 

This is where the spec meets what you do in the Mailgun control panel. 

How Mailgun uses your authenticated domains 

When you add a sending domain (often a subdomain like mg.example.com) in Mailgun: 

• Mailgun gives you SPF and DKIM TXT records to publish on that domain, along with MX and optional tracking CNAME records. 

• The domain must verify before you can send; Mailgun’s standard authenticated-domain flow expects a valid DKIM key in DNS before the domain is treated as fully authenticated. 

Once that’s done: 

• Mailgun signs outgoing mail with DKIM using your sending domain in the d= value, for example d=mg.example.com. 

• The MAIL FROM / Return-Path is typically based on your Mailgun sending domain 

Mailgun is capable of sending fully SPF‑aligned mail using your authenticated subdomains, and not just MAIL‑FROMs on a provider‑owned domain by default. 

In other words, in the standard authenticated‑domain flow, Mailgun authenticates mail on your domains, so alignment lives on your side of the house. 

If you’re using the conventional Mailgun pattern of dedicated sending subdomains, Mailgun‑provided SPF and DKIM on those domains, and a matching From domain, then both SPF alignment and DKIM alignment are achievable without special workarounds. 

Automatic Sender Security (ASS) doesn’t change that story: it automates key generation and rotation for your domain’s selectors, but the signing still uses your domain in d=. 

You can keep your current architecture. But, you need to make sure it matches what DMARC now describes more clearly. 

1. Inventory Mailgun domains and usage 
   • List all Mailgun‑verified domains and which streams (transactional, marketing, app notifications) use each. 
   • Retire or tighten DMARC on domains that are no longer actively used, especially if they still have permissive records. 
2. Verify aligned SPF and DKIM, not just “pass” 
   • Confirm SPF is correctly published on each Mailgun sending domain and that those domains share an organizational domain with the visible From. 
   • Use a header analyzer to confirm that d= in the DKIM signature matches your Mailgun sending domain (or a subdomain under your org), not some unrelated hostname. 
3. Clean up your DMARC records 
   • Remove pct, rf, and ri tags, which the new spec drops. 
   • Consider whether np and psd are relevant for your domain structure. 
   • Confirm your sp= behavior for subdomains is intentional. 

4. Treat aggregate reports as an early‑warning system 
   • Use DMARC aggregate reports to spot new Mailgun domains, forgotten legacy streams, or misaligned third‑party senders using your domain. 
   • If you’re at p=none, treat that as active monitoring, not “we’ll look someday.” 

5. Keep DMARC and DKIM2 mentally separate 
   • You’ll hear more about DKIM2, but that’s a separate protocol effort focused on signing models and replay protections. 
   • The DMARC RFC refresh doesn’t turn DKIM2 into a new requirement; DMARC still evaluates aligned SPF or aligned DKIM, just with better‑documented rules. 

DMARCbis is dead. Long live DMARC. For Mailgun customers, that means the spec has finally caught up with how authenticated domains and aligned identifiers are already supposed to work when you use the platform the way it was designed. 

Author: Alison Gootee