In May 2026, the IETF quietly did something that email administrators have been waiting on for years: they published RFC 9989, RFC 9990, and RFC 9991 — collectively known as DMARCbis. These three documents replace RFC 7489, which has been the authoritative reference for DMARC since 2015.

The headline change isn’t technical; it’s procedural. The original RFC 7489 was published as an Informational document, meaning it described what the industry was already doing, not what it was required to do. DMARCbis arrives as a Proposed Standard on the IETF Standards Track — the first formal step toward becoming an Internet Standard. In plain terms: DMARC just graduated from “strong industry recommendation” to “official protocol.”

What the Three RFCs Cover

The work has been split cleanly across three documents:

  • RFC 9989 is the core spec. It defines how senders publish DMARC policy in DNS, how receiving mail servers evaluate messages against it, and what to do when authentication fails.
  • RFC 9990 standardizes aggregate reporting — the daily XML digests that inbox providers send back to domain owners, showing which IP addresses sent mail on their behalf and how it fared against SPF, DKIM, and DMARC checks.
  • RFC 9991 covers failure reporting — per-message, near-real-time reports triggered when a specific message fails authentication. These come via the ruf tag in your DMARC record.

What Actually Changed

The good news first: existing DMARC records remain valid. The protocol identifier is still v=DMARC1, and you don’t need to touch anything to stay compliant with the new spec.

That said, several things did change.

Tags removed. Three tags have been deprecated: pct, rf, and ri. The pct tag was always a footgun — it let senders apply their DMARC policy to only a percentage of failing mail, which led to inconsistent enforcement across receivers. The new spec introduces a t tag (testing mode) as a cleaner replacement for that use case.

Public Suffix List replaced by DNS Tree Walk. Previously, receivers used the Public Suffix List — a manually maintained external list — to determine a message’s Organizational Domain for alignment checks. DMARCbis replaces this with a DNS Tree Walk algorithm, where the public suffix operator controls their own entry directly in DNS. This improves accuracy and eliminates the lag between list updates and receiver adoption.

Better PSD support. Public Suffix Domains (.bank, .gov, country-code structures) can now formally participate in DMARC enforcement via the new psd tag and DNS Tree Walk mechanism.

Mailing lists are still a mess. One thing the new spec doesn’t fully solve is the mailing list and email forwarding problem. RFC 9989 acknowledges this openly and now discourages aggressive p=reject policies in environments where significant mailing list traffic is expected. If you run a domain that participates in a lot of list traffic, that’s worth noting.

The Reporting Side Got Tidier

RFC 9990 standardizes the aggregate XML format more strictly than before, which means report parsers and DMARC monitoring tools will have clearer conformance targets. If you’ve ever wondered why your DMARC reports from different providers look slightly different, this is part of why — the original spec was vague enough to allow divergence.

RFC 9991’s tightening of failure reports comes with an explicit privacy note: these reports can include full message headers and body content, which may contain personal data. If you’re using ruf URIs and collecting failure reports, make sure your handling of that data aligns with your privacy obligations.

What This Means for kalfaoglu.net Customers

Nothing changes urgently for domains hosted with us. If your DMARC is already at p=quarantine or p=reject, you’re in good shape and can carry on without touching anything.

There are two things worth doing if you haven’t already:

First, if your DMARC record includes a pct tag, remove it. It was always a transitional workaround and is now formally deprecated. Finish the move to full enforcement or use the new t tag if you genuinely need testing mode.

Second, if you’re sitting at p=none indefinitely — monitoring without enforcement — the new spec signals that the industry is moving away from that posture. Major inbox providers are already enforcing this for bulk senders. Moving to at least p=quarantine is worth putting on the roadmap.

The Bigger Picture

The IETF publishing DMARCbis doesn’t change your inbox delivery tomorrow. But it signals something important: DMARC is no longer just “what the big providers agreed to do.” It is now a formally standardized protocol with a clear roadmap toward Internet Standard status. That carries weight with regulators, auditors (PCI DSS v4.0 already references DMARC), and increasingly, with enterprise mail systems evaluating sender reputation.

If you’d like a check on your current DMARC, SPF, and DKIM setup, open a support ticket — it takes about ten minutes to audit and costs nothing.