The New DMARC Is Here: What DMARCbis (RFC 9989) Changes for Senders

For more than a decade, DMARC has been the quiet backbone of email authentication. It sits on top of SPF and DKIM and tells receiving servers what to do when a message fails both checks: nothing, quarantine it, or reject it. The strange part is that the specification everyone relied on, RFC 7489, was never actually a standard. It was an Informational document that described what the industry happened to be doing. That changed in 2026 with DMARCbis.

What DMARCbis actually is

DMARCbis is the revision that finally makes DMARC a real Standards Track protocol. It obsoletes RFC 7489 and splits the specification into three documents: the core protocol (RFC 9989), aggregate reporting (RFC 9990), and failure reporting (RFC 9991). None of your existing records break overnight. But several things change in ways worth understanding, especially if deliverability is part of your job.

The biggest change: the DNS tree walk

The most consequential change is how receivers find your policy. The old DMARC leaned on the Public Suffix List, a community-maintained file that tries to encode where registrable domains begin, so that example.co.uk is treated as one organization and not as all of co.uk. It worked, but it was a single crowd-sourced list bolted onto a security protocol, and it was frequently out of date.

DMARCbis replaces it with a DNS tree walk. Instead of consulting an external list, a receiver walks up the DNS hierarchy from the From domain, querying for a _dmarc record at each level until it finds one. The walk is bounded to a maximum of eight DNS lookups. Policy discovery is now decided by DNS itself, which is more predictable, and domain owners can declare their own organizational boundaries instead of waiting for a list to be updated.

New tags, and one important removal

The tree walk brings a few new tags, and DMARCbis drops some old ones that caused more confusion than value.

• •np (new): a policy specifically for non-existent subdomains. Attackers love spoofing subdomains that were never real, like invoices.yourdomain.com, because those have no SPF or DKIM to fail against. np=reject closes that door. Its values are none, quarantine, and reject, just like the main p tag.
• •psd (new): flags whether a name is a public suffix domain. y means it is a PSD, n means it is not but is its own organizational domain, and u (the default) means let the tree walk decide.
• •t (new): a clean testing flag. t=y tells receivers you are still monitoring and not to enforce your policy yet. It replaces the messy way people used to abuse pct for staged rollouts.
• •pct (removed): the percentage tag is gone. You can no longer tell receivers to apply your policy to only 50% of mail. Fractional enforcement produced inconsistent, hard-to-debug behavior, so it was cut. If you still have pct in a record, remove it.
• •rf and ri (removed): the report-format and report-interval tags are gone. Aggregate reports are standardized now, and senders no longer control their timing or format.
• •sp (clarified): the subdomain-policy tag is only meaningful on your organizational domain, not on individual subdomain records.

A real record, before and after

Here is a typical pre-DMARCbis record that many teams are still running:

; old-style record
_dmarc.example.com.  TXT  "v=DMARC1; p=none; pct=100; rua=mailto:dmarc@example.com"

And here is a cleaned-up version that reflects the new guidance: drop pct, and add np=reject to protect subdomains that do not exist.

; DMARCbis-friendly record
_dmarc.example.com.  TXT  "v=DMARC1; p=reject; np=reject; rua=mailto:dmarc@example.com"

If you are not ready to enforce, start at p=none to collect reports, move to p=quarantine once your legitimate mail is passing, and only then go to p=reject. Do not jump straight to reject on a domain you have not been monitoring, or you will bounce your own mail.

Why this matters right now

DMARCbis did not arrive in a vacuum. In February 2024, Google and Yahoo began requiring bulk senders (roughly 5,000 messages a day or more) to authenticate with SPF and DKIM, publish a DMARC record, keep their domains aligned, and support one-click unsubscribe, all while holding spam complaints under 0.3%. Microsoft announced similar requirements for Outlook.com and Hotmail that took effect in 2025.

In other words, DMARC quietly went from best practice to table stakes. If you send at any real volume without a valid, aligned DMARC setup, your mail is already at risk of the spam folder or outright rejection. DMARCbis is the standard catching up to a world where the mailbox providers already treat DMARC as mandatory.

What you should actually do

• •Check that you have a DMARC record at all. If _dmarc.yourdomain.com returns nothing, that is the first fix.
• •Remove any pct tag. It no longer does anything useful and is being deprecated.
• •Add np=reject once you are confident your real subdomains are authenticated, to block spoofing of the ones that do not exist.
• •Make sure SPF or DKIM actually aligns with your From domain. DMARC only passes when at least one of them is both authenticated and aligned.
• •Watch your aggregate (rua) reports before tightening your policy. They show you who is sending as you, legitimately or not.
• •Progress none, then quarantine, then reject. Never skip straight to reject on an unmonitored domain.

Where Posthawk fits

When you add and verify a domain in Posthawk, it configures SPF and DKIM aligned to that domain, which is exactly the foundation DMARC checks against. Your transactional mail passes DMARC under your own domain rather than a shared one, so the sending reputation attached to it stays yours. DMARC itself is a DNS record you own and publish, and the new tree-walk model makes that ownership even more direct.

The short version: nothing breaks today, but the direction is settled. Authentication is no longer optional, the guesswork of the Public Suffix List is gone, and the cleanest thing you can do this week is publish a proper DMARC record, drop pct, and add np=reject.