DMARCbis: what changed and what to do with your record

If your DMARC record is v=DMARC1; p=reject; rua=mailto:dmarc@example.com, DMARCbis changes nothing for you. The specification that replaced the original informational DMARC document (RFC 7489) is now standards-track, published as RFC 9989, with companion documents covering aggregate and failure reporting. Four practical changes matter: the Public Suffix List is gone, pct is gone, np and t are new, and the guidance on p=reject for domains with human mailboxes is more explicit.

Why it matters even though little changed

The original DMARC was informational — a description of what several large companies had agreed to do. That was always an awkward footing for something mailbox providers enforce and auditors ask about. Standards-track status means there is now a specification a receiver, an auditor or a vendor can point to, and that the ambiguities senders used to argue about have answers.

For cold-email and outbound senders in particular, two of those ambiguities cost real placement: how a receiver determines your organisational domain, and what happens to subdomains you never intended to send from.

The DNS tree walk replaces the Public Suffix List

Under the old model, a receiver determined your organisational domain by consulting the Public Suffix List — a community-maintained file of suffixes like com, co.uk and github.io. It worked, but it was a static file outside DNS, with no authority behind it and update lag measured in weeks.

DMARCbis replaces it with a tree walk: starting at the From domain, the receiver queries _dmarc records up the DNS tree, up to a bounded number of labels, until it finds a policy. Consequences worth knowing:

• Your organisational boundary is now determined by *your own DNS*, not by an external list. Publishing a record at the right level is how you control inheritance.
• Deeply nested sending hostnames resolve more predictably. mail.eu.send.example.com finds example.com's policy through the walk.
• Public suffix operators have a defined way to declare themselves, via the psd tag.

What to do: nothing, if you publish a policy at your organisational domain. If you relied on PSL quirks to keep a subdomain outside a policy, that assumption is gone — publish an explicit subdomain policy instead.

Tags removed: pct, rf and ri

• `pct` is removed. It was used to apply a policy to a percentage of mail — p=quarantine; pct=25 — as a ramping aid. In practice it was implemented inconsistently and produced confusing partial enforcement. If your record contains pct=, plan to remove it. A record with pct=100 means exactly what p= alone means, so removing it is safe today.
• `rf` (report format) is removed. There was only ever one format in practice.
• `ri` (report interval) is removed. Receivers sent daily aggregate reports regardless of what you asked for.

Removing a tag that receivers ignored costs nothing, and leaving a removed tag in place is tolerated — unknown tags are skipped. Clean it up anyway, so the record reflects reality.

Tags added: np, psd and t

np is the genuinely useful addition, and it is free protection. t=y is the replacement for ramping: publish the policy you intend with t=y, read your reports, then remove the flag.

Guidance on p=reject for mailbox domains

DMARCbis is more explicit that p=reject on a domain whose users participate in mailing lists and discussion forums causes collateral damage: traditional mailing lists rewrite or re-send messages in ways that break both SPF and the DKIM signature, so the list's forwarded copies fail DMARC and get rejected. That is a known cost, not a bug in your configuration.

The practical shape most organisations should land on:

• Sending-only subdomains (mail.example.com, t.example.com): p=reject, no humans, no mailing lists, no downside.
• The organisational domain with human mailboxes: p=reject is still the right destination for most businesses, but get there deliberately, after checking whether your people post to lists from their work addresses.
• Non-existent subdomains: np=reject always.

A five-point record audit

Run this in ten minutes:

dig txt _dmarc.example.com +short
dig txt _dmarc.mail.example.com +short

1. Exactly one DMARC record per name. Two v=DMARC1 TXT records at the same name is a configuration error and receivers may ignore both.
2. `rua` present and monitored. A policy you do not have reports for is a policy you cannot safely tighten. Confirm someone actually reads them, or that a tool parses them.
3. `pct` removed. Replace a ramp with t=y if you still need one.
4. `np=reject` added at the organisational domain.
5. Alignment mode checked. adkim=s; aspf=s is strict; relaxed is the default and is correct for most senders using an ESP whose bounce domain is a subdomain. Rely on DKIM alignment as the primary mechanism, because DKIM survives forwarding and SPF does not.

A reasonable modern record:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; np=reject; rua=mailto:dmarc@example.com; adkim=r; aspf=r"

Do you need to redo your setup?

No. If SPF and DKIM pass with alignment, you publish a policy, and you read your reports, you are compliant with the new specification as written. The work is a tidy-up: drop pct, add np, confirm one record per name, and stop relying on the Public Suffix List for your organisational boundary.

What not to do

• Do not jump to p=reject before your aggregate reports show every legitimate source authenticating.
• Do not use t=y as a permanent state; it is a migration flag.
• Do not publish psd unless you operate a public suffix.
• Do not treat DMARC as a deliverability feature. It stops exact-domain spoofing and satisfies a provider requirement. It does not improve placement for mail that was already authenticating.
• Do not remove SPF because you have DKIM. Google and Yahoo expect both.

MailPilot checks SPF, DKIM and DMARC against your mail as delivered — including alignment on the From domain, which is the part DNS checkers miss — alongside warm-up and per-provider inbox placement measurement.