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

• 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.