DMARCbis: every change (and how to get ready)

Status as of 29 October 2025. The DMARCbis corpus is almost finalized: the main document dmarcbis-41 and aggregate-reporting-32 are in the RFC Editor Queue (MISSREF), waiting for failure-reporting to close. Existing DMARC records remain in the v=DMARC1 format.

⚡TL;DR

TL;DR

• Policy discovery & organizational domain: the Public Suffix List (PSL) is replaced by a DNS Tree Walk and the new psd marker (y/n).
• New tags: psd, np (policy for non-existent domains), t (testing, replacing the useful pct=0 pattern).
• Removed tags: pct, ri, rf.
• Reporting: split into two normative documents (aggregate vs. failure); URI length limit removed; every listed URI MUST receive a report.
• Interoperability: DMARCbis advises against p=reject on general-purpose domains (lists, aliases, forwarding) and recommends p=quarantine until you fully control the authentication chain; keep p=reject only when you own every intermediary. MTAs must not reject solely on the presence of p=reject.
• Compatibility: existing DMARC records keep working; plan your migration toward the new tags and practices.

👉 A glossary at the end of the article recaps the key notions: Public Suffix Domain, Organizational Domain, and DNS Tree Walk.

1) Timeline & status

• 17 March 2025: Aggregate Reporting v**–32** → RFC Editor Queue (MISSREF).
• 4 April 2025: DMARCbis v**–41** → RFC Editor Queue (MISSREF).
• 9 October 2025: Failure Reporting v**–17** enters WG Last Call.
• Target publication in 2025 if outstanding references clear.
• Immediate impact: no version change (v=DMARC1); nonetheless, operators must prepare for the new algorithms and tags.

2) Policy discovery & Organizational Domain: the DNS Tree Walk

DMARCbis replaces the dependency on the PSL with a walk up the DNS tree that:

1. Discovers the policy in scope (Policy Discovery), and
2. Finds the Organizational Domain used for alignment.

Key principles:

• First look for "_dmarc." + AuthorDomain. If absent, walk upward label by label (max 8 queries) to find an Organizational Domain or a PSD.
• The psd tag guides the decision:
  • psd=n ⇒ the domain that published the record is an Organizational Domain.
  • psd=y (higher up) ⇒ the Organizational Domain is one label below.
• When a policy is inherited from a parent (Org or PSD), apply sp to existing subdomains and np if the subdomain does not exist.
• If no record is found, DMARC does not apply to the message.

3) Tags: additions, removals, unchanged

Added

• psd: flags a domain as a Public Suffix Domain (y/n) to guide the Tree Walk.
• np: policy for non-existent domains (lessons learned from PSD pilots).
• t: testing mode (y/n) — replaces the useful pct=0 pattern (see below).

Removed

• pct: partial rollout was inconsistent across implementations; keep the binary 0/100 rollout via t.
• ri: aggregate report interval (now handled by the Aggregate Reporting document and operator practice).
• rf: failure report format (clarified in the Failure Reporting document).

Unchanged (examples)

v, p, sp, adkim, aspf, fo, rua, ruf, pct (removed — plan to phase out).

4) psd: Public Suffix Domain marker

The psd tag states whether the domain that publishes the DMARC record must be treated as a Public Suffix Domain by the Tree Walk algorithm:

• psd=y: the domain is considered a PSD. The published policy covers the suffix you operate, while registrable domains beneath it remain responsible for their own DMARC.
• psd=n: the domain is an Organizational Domain and anchors policy discovery for its subdomains.

Reserve psd=y for suffix operators (TLDs, sector registries, large organizations delegating subdomains). Otherwise omit the tag or explicitly set psd=n to show the zone is a “regular” sending domain.

5) np: policy for non-existent domains

The np tag extends DMARC to non-existent subdomains discovered during the Tree Walk:

• It only applies when no dedicated _dmarc record is found for the target subdomain (NXDOMAIN).
• Allowed values (none, quarantine, reject) follow the same semantics as p/sp.
• If np is missing, the p (or inherited sp) value is used instead.

Publish np=reject at your Organizational Domain (or PSD) to block spoofing attempts on “empty” subdomains without adding individual DMARC records.

6) t = testing: the practical successor to pct=0

The t=y tag does not disable reporting, but requests a softer application of the policy:

• p=reject + t=y ⇒ treat fails as quarantine.
• p=quarantine + t=y ⇒ treat fails as none.
• p=none ⇒ unchanged.

Goal: enable a safe ramp-up without the interoperability headaches that pct caused.

7) Reporting: separation, deliverability & security

• Split into two RFCs: aggregate reports (XML) and failure reports (message-by-message).
• URI length limit removed.
• Multiple URIs in rua/ruf: every URI MUST receive its own report.
• External destinations (rua/ruf pointing to another domain): authorization mechanism stays the same (records published by the report recipient).
• Privacy: enable failure reports carefully; most operators still prioritize aggregate reports.

8) Interoperability & policies

• DMARCbis explicitly states that for general-purpose messaging domains (mailing lists, aliases, forwarding) operators should not publish p=reject; instead, prefer p=quarantine until the end-to-end authentication chain is under control, and keep p=reject only where every hop is under your authority.
• Receivers should not reject a message solely because a p=reject policy is published; they need to correlate other signals (mailing list behavior, header rewriting, ARC, reputation, etc.).
• To avoid relaxed-alignment bypasses, publish DMARC records as close as possible to actual sending domains (and consider adkim=s/aspf=s where it makes sense).

9) Compatibility & transition

• v=DMARC1 stays: existing records remain valid.
• Phase out: pct, ri, rf.
• Introduce: psd where relevant (PSOs / TLDs or special registrable domains), np to control non-existent domains, t to steer rollouts.

Sample records

Organizational policy + controlled ramp-up

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; sp=reject; adkim=s; aspf=r; 
  rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-fail@example.com; fo=1; t=y"

PSD marking by a suffix operator

_dmarc.bank.example. 3600 IN TXT "v=DMARC1; p=reject; psd=y; rua=mailto:psd-agg@pso.example"

Policy for non-existent domains

_dmarc.example.net. 3600 IN TXT "v=DMARC1; p=quarantine; np=reject; rua=mailto:agg@example.net"

10) CaptainDNS playbook (practical checklist)

1. Inventory

   List real Author Domains and active subdomains; spot zones without DMARC.

2. DNS trees

   Verify the Tree Walk outcome (where does the Organizational Domain land?) and publish records as close as possible to real senders.

3. Policies

   Start with p=quarantine + t=y; monitor aggregate reports for 2–4 weeks; move to t=n, then tighten if false positives are under control.

4. Alignment

   Aim for adkim=s first (DKIM signing on the From); keep aspf=r unless you truly need strict SPF.

5. PSD / `np`

   If you operate a root or “family” domain, use np to block non-existent domains; only publish psd if you are a PSO/PSD.

6. Reporting

   Keep dedicated rua/ruf mailboxes, encrypted in transit; validate external authorizations if a third party receives the reports.

7. Lists / intermediaries

   Anticipate From: rewrites; ARC can help preserve reputation while avoiding unnecessary rejects.

8. Cleanup

   Remove pct, ri, rf; track aggregates to spot interoperability quirks.

11) FAQ

Do we need to change `v=DMARC1` to `v=DMARC2`?

No — the tag stays DMARC1.

Is `pct` still honored?

It has been removed from the spec; some receivers may ignore it. Use t instead.

Is the PSL gone for good?

Yes for DMARCbis: discovery now relies on the DNS Tree Walk.

Can I publish `p=reject` everywhere?

Only if you fully control the authentication chain; for general-purpose messaging (lists, aliases, forwarding) DMARCbis recommends staying on p=quarantine.

12) Glossary

• Public Suffix List (PSL): list of public suffixes historically maintained by Mozilla; DMARCbis replaces it with the DNS Tree Walk.
• Public Suffix Domain (PSD): domain suffix operated by an entity that delegates subdomains to others (e.g. TLDs, sectoral registries) and can publish a DMARC policy covering the entire suffix.
• Public Suffix Operator (PSO): entity that manages a public suffix (PSD) and may publish a reference DMARC policy for attached domains.
• DNS Tree Walk: DMARCbis procedure that walks the DNS tree label by label to find a _dmarc record, detect a PSD, and, if needed, apply inherited policy (p, sp, np).
• Organizational Domain: an organisation’s primary domain, identified by the Tree Walk, which governs the DMARC policy for aligned subdomains.
• Author Domain: the domain in the visible From: header; it is the basis for DMARC alignment calculations.

---

Artwork: home-made SVG diagrams for CaptainDNS.