DMARCbis: the complete guide to understanding and migrating to the new DMARC standard

⚡TL;DR

• DMARCbis replaces DMARC (RFC 7489) and becomes an IETF Proposed Standard. All three documents are queued at the RFC Editor, with publication expected in 2026.
• The DNS Tree Walk replaces the Public Suffix List: organizational domain discovery is done through successive DNS queries (max 8), with no dependency on an external list.
• Three tags added: psd (Public Suffix Domain marker), np (policy for non-existent subdomains), t (binary testing mode).
• Three tags removed: pct (replaced by t), ri and rf (moved to the reporting documents).
• Your current DMARC records remain valid (v=DMARC1). Migration consists of removing obsolete tags and gradually adopting the new ones.

DMARC has been protecting domains against email spoofing since 2015. But RFC 7489 had structural weaknesses: dependency on an external list (the Public Suffix List), a pct tag that was poorly understood and poorly implemented, and no mechanism for non-existent subdomains.

DMARCbis fixes these issues. It is not a minor update: it is a rewrite that elevates DMARC to IETF Proposed Standard, the first normative status for the protocol. All three documents (base, aggregate reports, failure reports) have been queued at the RFC Editor since late 2025. Publication is imminent.

This guide is for system administrators, email managers and security engineers who need to understand the changes and prepare for migration. You will find a detailed explanation of the DNS Tree Walk, a comprehensive tag comparison, a migration plan and compliance implications (PCI DSS 4.0, Google, Yahoo, Microsoft).

A glossary at the end of the article defines the technical terms: PSL, PSD, PSO, Tree Walk, Organizational Domain, Author Domain.

What is DMARCbis?

DMARCbis is the successor to DMARC as defined by RFC 7489. The "bis" suffix follows the IETF convention for the second iteration of a protocol. In concrete terms, DMARCbis consists of three normative documents:

• draft-ietf-dmarc-dmarcbis: the base document (policy discovery, alignment, tags)
• draft-ietf-dmarc-aggregate-reporting: XML aggregate reports
• draft-ietf-dmarc-failure-reporting: failure reports (per-message)

Why this overhaul?

RFC 7489, published in 2015, carried the "Informational" status. This means DMARC was not an Internet standard in the strict sense. DMARCbis corrects this by becoming a Proposed Standard, which gives it normative weight within the IETF ecosystem.

The technical motivations are specific:

1. The Public Suffix List is fragile. Maintained manually by Mozilla, non-standardized, updated out-of-band. A forgotten registry or an unlisted new TLD causes false negatives.
2. The pct tag was useless. In practice, only the values 0 and 100 were used. Implementations varied between receivers, making behavior unpredictable.
3. Non-existent subdomains were unprotected. An attacker could send from fake.subdomain.captaindns.com without DMARC applying.
4. PSD DMARC (RFC 9091) remained experimental. DMARCbis integrates and replaces this extension by unifying the model through the psd tag and the Tree Walk.

IETF timeline

Date	Event
2015	RFC 7489 published (Informational)
2021	RFC 9091 PSD DMARC (Experimental)
2024-2025	Iterative DMARCbis drafts within the DMARC WG
Q4 2025	All three drafts enter the RFC Editor queue (EDIT state)
Q1/Q2 2026	Publication expected as Proposed Standard

Key point: the DNS record version remains v=DMARC1. There is no v=DMARC2. Existing records continue to work.

The DNS Tree Walk: the end of the PSL

The most structural change in DMARCbis is replacing the Public Suffix List with a purely DNS-based discovery algorithm: the Tree Walk.

The PSL problem

With DMARC v1, to determine the Organizational Domain, the receiver consulted the Public Suffix List. This list, maintained by Mozilla, catalogs public suffixes (co.uk, com.au, gouv.fr). The receiver subtracted the public suffix from the domain to identify the organization.

The limitations were well known:

• The list must be downloaded and updated regularly (potential lag)
• New TLDs or unlisted suffixes cause errors
• The mechanism is not standardized: each implementation handles the list differently
• No DNS authority validates the accuracy of the list

How does the Tree Walk work?

The Tree Walk queries the DNS directly to discover the applicable DMARC policy. The algorithm works as follows:

Input: the domain from the From: header (Author Domain)

Steps:

1. Query _dmarc.<AuthorDomain>. If a DMARC record is found with psd=n (or without a psd tag), this domain is the Organizational Domain. Done.
2. If no record is found, remove the leftmost label and try again.
3. If a record is found with psd=y, the Organizational Domain is one label below the current domain.
4. If a record is found with psd=u, continue walking up.
5. Repeat until a result is found or the limit of 8 DNS queries is reached.

Output: the Organizational Domain and the applicable policy (or "no DMARC" if nothing is found).

Concrete examples

Case 1: simple domain

For newsletter.captaindns.com:

Query 1: _dmarc.newsletter.captaindns.com → no record
Query 2: _dmarc.captaindns.com → "v=DMARC1; p=reject; psd=n"

Result: psd=n confirms that captaindns.com is the Organizational Domain. 2 DNS queries.

Case 2: Public Suffix Domain

For contact.banque.co.uk:

Query 1: _dmarc.contact.banque.co.uk → no record
Query 2: _dmarc.banque.co.uk → no record
Query 3: _dmarc.co.uk → "v=DMARC1; p=reject; psd=y"

Result: psd=y indicates that co.uk is a PSD. The Organizational Domain is banque.co.uk (one label below the PSD). 3 DNS queries.

Case 3: deep domain

For a domain with more than 8 labels, the algorithm jumps directly to 7 labels after the first query, then walks up label by label. The 8-query limit ensures the process terminates.

PSL vs Tree Walk comparison

Aspect	PSL (RFC 7489)	DNS Tree Walk (DMARCbis)
Source of truth	Static list (Mozilla)	The DNS itself
Updates	Periodic download	Real-time via DNS queries
Coverage	Manual, potentially incomplete	Any domain publishing a _dmarc record
PSD detection	Lookup in the list	psd=y tag in the DNS record
Standardization	Community project, non-normative	IETF Standards Track

Tree Walk performance

For a typical 3-label domain (like newsletter.captaindns.com), the Tree Walk adds at most 1 extra DNS query compared to DMARC v1. The 8-query limit ensures that deep domains do not cause overload.

DNS caching mitigates the impact in practice. The _dmarc records for the Organizational Domain are cached after the first query. NXDOMAIN responses are also cached according to the MINIMUM field TTL from the SOA. A domain receiving thousands of messages per hour will generate only a handful of effective Tree Walk queries.

By comparison, the PSL approach generated no DNS queries for discovery. But it required periodically downloading a list of about 250 KB and maintaining it in memory.

TTL recommendation: publish your _dmarc records with a TTL of at least 3600 s. A TTL of 86400 s further reduces DNS load. This is especially useful for records with psd=n or psd=y, which serve as Tree Walk anchor points.

What changes in DMARC tags

DMARCbis adds three tags, removes three, and modifies the behavior of two existing ones. The version tag (v=DMARC1) and the core tags (p, sp, adkim, aspf, fo) remain unchanged.

Added tags

The psd tag: public suffix marker

The psd tag indicates whether the domain publishing the record is a Public Suffix Domain.

Value	Meaning
y	This domain is a PSD (e.g., co.uk, gouv.fr). The Organizational Domain is one label below.
n	This domain is a regular Organizational Domain.
u	Undetermined. The Tree Walk continues walking up.

Default value: u (undetermined).

Who should use it? Only public suffix operators (TLD registries, sector registries). For a standard domain, leave psd absent or set psd=n.

Example for a registry:

_dmarc.co.uk. 3600 IN TXT "v=DMARC1; p=reject; psd=y; rua=mailto:dmarc-agg@registry.co.uk"

The np tag: policy for non-existent subdomains

The np tag fills a blind spot in DMARC v1: subdomains that do not exist in DNS. An attacker could send from fake.captaindns.com without any applicable policy if no _dmarc record existed at that level.

With np, the Organizational Domain can declare a specific policy for these cases. The values are the same as p: none, quarantine, reject.

The fallback chain is: np (if present) then sp (if present) then p.

The receiver checks whether the subdomain exists via DNS. If DNS returns NXDOMAIN, the np policy applies.

Example:

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=quarantine; np=reject; rua=mailto:dmarc-agg@captaindns.com"

Result: existing subdomains inherit p=quarantine. Non-existent subdomains are blocked by np=reject.

The t tag: testing mode

The t tag replaces the use of pct=0 for testing mode. The semantics are binary:

• t=y: the policy is downgraded by one level (reject becomes quarantine, quarantine becomes none)
• t=n: the policy applies normally (default value)

Testing mode does not affect reporting: aggregate reports are sent normally, which lets you monitor results before enforcing the strict policy.

Critical point for the transition: DMARC v1 receivers ignore unknown tags. If you publish p=reject; t=y, a receiver that has not yet implemented DMARCbis will apply reject without considering t=y. This behavior is by design: it ensures the strictest policy applies by default.

Removed tags

Tag	Reason for removal	Replacement
pct	In practice, only the values 0 and 100 were used. Behavior varied between implementations.	t=y for testing mode, removal for the rest
ri	The reporting interval was de facto standardized at 24 h. Receivers ignored other values.	Handled by the Aggregate Reporting document
rf	Only one format existed (afrf). No alternative was ever deployed.	Handled by the Failure Reporting document

If your DMARC records still contain pct, ri or rf, they will continue to work (receivers will ignore them). But removing them is recommended to avoid any ambiguity.

Modified tags

rua (aggregate reports): the size limit syntax (!10m) is removed. External destination verification is strengthened: if the rua address domain differs from the DMARC domain, an authorization record _dmarc-report._report.<rua-domain> must exist.

ruf (failure reports): defined in a separate RFC document (Failure Reporting). Same external destination verification as rua.

Summary table: v1 vs DMARCbis

Tag	DMARC v1	DMARCbis	Status
v	DMARC1	DMARC1	Unchanged
p	none / quarantine / reject	Identical	Unchanged
sp	Subdomain policy	Identical	Unchanged
adkim	r / s	Identical	Unchanged
aspf	r / s	Identical	Unchanged
fo	0 / 1 / d / s	Identical	Unchanged
rua	URIs with size limit	URIs without limit, strengthened external verification	Modified
ruf	URIs	Defined in separate RFC	Modified
pct	0-100	Removed	Removed
ri	Seconds	Removed	Removed
rf	afrf	Removed	Removed
np	N/A	none / quarantine / reject	New
psd	N/A	y / n / u	New
t	N/A	y / n	New

Reporting splits into three documents

DMARC v1 bundled everything into RFC 7489: policy, aggregate reports and failure reports. DMARCbis separates these responsibilities into three distinct normative documents.

Aggregate reports

Aggregate reports remain in XML format, but the schema evolves. Key changes:

• New XML namespace: urn:ietf:params:xml:ns:dmarc-2.0
• New <testing> field: indicates whether the domain was in testing mode (t=y)
• New <np> field: policy for non-existent subdomains
• New <discovery_method> field: how the policy was discovered (Tree Walk vs direct)
• New pass disposition: added to the possible dispositions
• Removal of sampled_out: this override reason disappears along with pct

Each URI listed in rua receives its own report. This is no longer optional: receivers MUST send a separate report to each address.

Failure reports

Failure reports are now covered by a separate document. This change reflects reality: most major providers were not sending failure reports, for privacy and volume reasons.

The document clarifies privacy requirements and the cases where sending is appropriate.

Other notable changes

• SPF restricted to MAIL FROM: DMARCbis eliminates SPF verification based on HELO/EHLO. Only the MAIL FROM domain is evaluated for alignment.
• Strengthened guidance on p=reject: domains with p=reject should use DKIM (not just SPF). Receivers should not reject solely based on p=reject without evaluating DKIM/SPF. Domains whose users post to mailing lists should not publish p=reject.

DMARCbis and mailing lists

Mailing lists have been the most problematic use case for DMARC since 2015. DMARCbis does not solve the problem, but formally documents it and strengthens the recommendations.

Why do mailing lists break alignment?

A mailing list modifies the message in transit. The SMTP envelope changes (new MAIL FROM), which breaks SPF alignment. The content is often modified (subject prefix added, unsubscribe footer), which invalidates the DKIM signature. The result: systematic DMARC failure for domains using p=reject.

DMARCbis formally strengthens the recommendation: domains whose users participate in mailing lists should not publish p=reject. The p=quarantine policy is preferable in this case.

ARC as a fallback mechanism

ARC (Authenticated Received Chain, RFC 8617) allows intermediaries to preserve an authentication chain. DMARCbis references ARC as a mechanism that receivers MAY use to recover original authentication results. But DMARCbis does not make ARC mandatory. It is an option, not a guarantee.

Override types in aggregate reports

DMARCbis recognizes the following override types in aggregate reports:

• forwarded: message forwarded by a third party
• mailing_list: message originating from a mailing list
• trusted_forwarder: trusted forwarder identified by the receiver
• local_policy: receiver's local policy (allowlist, reputation)
• policy_test_mode: new type, replaces sampled_out (removed with pct)

These types help understand why a receiver chose not to apply the published policy.

Practical advice

Modern mailing list software (Mailman 3, Sympa) includes built-in DMARC mitigations. The most common: rewriting the From: to use the list address instead of the original address. If your domain is used by mailing lists, verify that these mitigations are enabled. And prefer p=quarantine over p=reject.

DMARCbis and Email Service Providers (ESPs)

No major ESP (SendGrid, Mailgun, Amazon SES, Postmark, Brevo) has announced specific DMARCbis support as of March 2026. This is normal and expected: DMARCbis is a receiver-side change, not a sender-side one. ESPs do not need to modify their infrastructure.

DKIM alignment: the critical issue

The main concern for ESPs remains DKIM alignment. Two signing modes exist:

• Shared domain (e.g., d=sendgrid.net): the DKIM signature uses the ESP's domain. Strict alignment fails because the DKIM domain does not match the From: domain. Relaxed alignment fails too.
• Custom domain via CNAME (e.g., d=captaindns.com): the DKIM signature uses your own domain. Alignment passes in both strict and relaxed modes.

DMARCbis recommends adkim=s (strict). This recommendation makes custom DKIM signing essential for any domain using an ESP.

SPF and the bounce domain

DMARCbis eliminates SPF verification based on HELO/EHLO. Only the MAIL FROM domain (Return-Path) counts for SPF alignment. Most ESPs use a generic bounce domain by default (e.g., bounce.sendgrid.net). This domain does not match your From: domain, which causes SPF alignment to fail.

The solution: configure a custom bounce domain (Return-Path) that matches your From: domain. Most ESPs offer this option via a DNS CNAME.

ESP checklist

1. Verify custom DKIM signing: your ESP must sign with d=captaindns.com, not with its own domain.
2. Verify custom Return-Path: the bounce domain must match your From: domain.
3. Test strict alignment: send a test email and check the headers. The d= (DKIM) and Return-Path fields must match the From: domain.
4. Start relaxed, then go strict: publish adkim=r first, validate the reports, then switch to adkim=s.

How to migrate to DMARCbis

The good news: migration is gradual. Your current DMARC records remain functional. Here are the recommended steps.

Step 1: audit your current records

Identify all your domains and subdomains that publish a _dmarc record. Note the tags used, especially pct, ri and rf.

Example of an existing record:

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=quarantine; pct=100; ri=86400; rua=mailto:dmarc-agg@captaindns.com; ruf=mailto:dmarc-fail@captaindns.com; fo=1"

Step 2: remove obsolete tags

Remove pct, ri and rf from your records. These tags will be ignored by DMARCbis receivers and provide no value to v1 receivers.

Cleaned record:

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-agg@captaindns.com; ruf=mailto:dmarc-fail@captaindns.com; fo=1"

Step 3: enable testing mode if needed

If you are preparing to move from quarantine to reject, use t=y to test first:

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=reject; t=y; rua=mailto:dmarc-agg@captaindns.com; ruf=mailto:dmarc-fail@captaindns.com; fo=1"

With t=y, DMARCbis receivers will apply quarantine instead of reject. Reports will reflect this testing mode. After validation (2 to 4 weeks of clean reports), remove t=y or switch to t=n.

Reminder: DMARC v1 receivers will ignore t=y and apply p=reject directly. This is not a bug: it is the expected behavior.

Step 4: protect non-existent subdomains

Add np=reject to block spoofing from subdomains that do not exist in your DNS:

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=reject; np=reject; sp=quarantine; rua=mailto:dmarc-agg@captaindns.com; fo=1"

Step 5: verify DKIM alignment

DMARCbis recommends adkim=s (strict) for domains where you control the DKIM signing. Strict alignment prevents a subdomain from reusing the signature of a parent domain.

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=reject; np=reject; adkim=s; aspf=r; rua=mailto:dmarc-agg@captaindns.com; fo=1"

Step 6: validate external reporting authorizations

If your rua or ruf addresses point to a domain different from the DMARC domain, verify that the authorization record exists:

captaindns.com._dmarc-report._report.monitoring.captaindns.com. IN TXT "v=DMARC1"

Common migration mistakes

Seven pitfalls come up regularly when migrating to DMARCbis. Knowing them will save you surprises in production.

1. Publishing t=y without understanding v1 behavior. DMARC v1 receivers (still the majority as of March 2026) ignore t=y because it is an unknown tag. They apply p=reject directly, without downgrading. This behavior is by design, but often surprises administrators who expect a universal testing mode.

2. Keeping pct=0 alongside t=y. This combination creates inconsistent behavior. V1 receivers apply pct=0 (no enforcement). DMARCbis receivers ignore pct and apply t=y (downgraded enforcement). Result: two receiver populations with different behaviors. Solution: remove pct before adding t.

3. Tree Walk producing a different Organizational Domain than the PSL. Some uncommon TLDs have a PSL entry that is not up to date. The Tree Walk may then identify a different Organizational Domain than the one determined by the old PSL mechanism. Mitigation: publish an explicit _dmarc record with psd=n at your Organizational Domain level.

4. Forgetting external reporting authorization records. When you switch DMARC monitoring providers, the old _dmarc-report._report records point to the previous provider. Reports silently stop without any error message. Update these records every time you change providers.

5. Not testing the impact of np=reject. This policy can affect legitimate services that use dynamic subdomains. Some CDNs, marketing platforms or campaign tools create subdomains on the fly. Verify that these services do not send email from subdomains not registered in your DNS.

6. Relying on failure reports (ruf). Major providers (Google, Yahoo, Microsoft) have largely stopped sending failure reports for privacy and GDPR compliance reasons. Use aggregate reports (rua) as your primary analysis source. Failure reports are a supplement, not a reliable foundation.

7. Planning a gradual rollout without pct. With pct removed in DMARCbis, percentage-based rollout no longer exists. The options are t=y (full downgrade) or full enforcement (no t or t=n). Use t=y with manual monitoring windows of 2 to 4 weeks to replicate a gradual rollout.

DMARCbis and regulatory compliance

Anti-phishing compliance and payment standards

PCI DSS version 4.0 (effective since March 2025) requires anti-phishing controls for entities that process payments. DMARC in enforcement mode (quarantine or reject) is among the expected measures. DMARCbis strengthens this posture with np=reject (protection of non-existent subdomains) and the recommendation for strict DKIM alignment.

Google and Yahoo bulk sender requirements

Since February 2024, Google and Yahoo require DMARC for senders of more than 5,000 messages per day. Although these providers have not yet implemented DMARCbis, they will recognize cleaned records (without pct, ri, rf) since these tags are already widely ignored.

Microsoft and Exchange Online

Microsoft is gradually enforcing stricter DMARC checks on Exchange Online and Outlook. Microsoft has not yet announced DMARCbis adoption, but early preparation will prevent last-minute adjustments.

Current adoption (March 2026)

Receiver-side adoption is still marginal. Only United Internet AG (GMX, mail.com, WEB.DE) emits reports in DMARCbis format (3 reporters out of 3,493 in observed data). Google, Microsoft, Yahoo and Amazon SES have not yet migrated. Now is the time to prepare your records: when the major providers switch, you will be ready.

Action plan: preparing for the transition

1. Inventory all domains and subdomains publishing a _dmarc record. Identify actual Author Domains and zones without a DMARC record.
2. Test with the DMARCbis Checker the compatibility of each domain. Identify obsolete tags and specific recommendations.
3. Clean up your records: remove pct, ri, rf. Keep v=DMARC1.
4. Add np=reject at the Organizational Domain level to protect non-existent subdomains.
5. Use t=y for any policy escalation (moving from quarantine to reject).
6. Strengthen alignment: target adkim=s as a priority, keep aspf=r unless strict is specifically needed.
7. Validate external authorizations if your rua/ruf addresses point to a third party.
8. Monitor aggregate reports for 2 to 4 weeks after each change to detect anomalies.

FAQ

Do I need to change v=DMARC1 to v=DMARC2?

No. The record version remains v=DMARC1. DMARCbis does not modify the version tag. Your existing records continue to work without any change to the v tag.

What is the DNS Tree Walk?

The DNS Tree Walk is the DMARCbis algorithm that replaces the Public Suffix List for discovering the applicable DMARC policy for a domain. It queries the DNS by walking up label by label from the sender domain (Author Domain), with a limit of 8 queries, until it finds a _dmarc record that identifies the Organizational Domain via the psd tag.

Does the PSL disappear entirely?

Yes, from DMARCbis's perspective. Policy discovery and Organizational Domain determination happen entirely through the DNS Tree Walk. The Public Suffix List is no longer referenced in the standard. Some receivers may maintain a PSL fallback during the transition, but it is not required.

Why was the pct tag removed?

In practice, only the values 0 (testing mode) and 100 (full enforcement) were used. Behavior for intermediate values varied between receivers, making results unpredictable. The t=y/n tag replaces it with a clear binary semantic: either the policy is downgraded by one level (testing), or it applies normally.

Is my current DMARC record compatible with DMARCbis?

Yes, as long as the v=DMARC1 tag is present. DMARCbis is backward compatible. The pct, ri and rf tags will be ignored by DMARCbis receivers, without causing any error. The recommended migration is to remove them and gradually adopt np, psd and t.

Can I publish p=reject for all my domains?

DMARCbis advises against p=reject for general-purpose domains (mailing lists, aliases, forwarding). Reserve p=reject for domains where you control every intermediary end to end. For other cases, p=quarantine remains recommended. Receivers should not reject a message solely because p=reject is published: they should cross-reference with other signals (ARC, reputation, mailing lists).

Is the t=y tag risky during the transition?

There is a calculated risk. DMARC v1 receivers ignore t=y (unknown tag) and apply the policy as-is. If you publish p=reject; t=y, a v1 receiver will apply reject without downgrading. A DMARCbis receiver will apply quarantine. This behavior is intentional: it favors security by default. Use t=y only if you accept that the strict policy will apply at receivers that have not yet migrated.

Who should use the psd tag?

Only public suffix operators: TLD registries (co.uk, com.au, gouv.fr), sector registries, and large organizations that delegate subdomains to independent entities. For a standard corporate domain, leave psd absent or set psd=n.

When will major providers implement DMARCbis?

No date has been publicly announced (March 2026). Receiver-side adoption is marginal: only United Internet AG (GMX, mail.com, WEB.DE) emits reports in DMARCbis format. The publication of the RFCs will likely trigger implementation by major providers. Preparing your records now positions you ahead.

How does the np, sp, p fallback chain work?

When a DMARCbis receiver receives an email from a subdomain, it first checks whether that subdomain exists in DNS. If it does not exist (NXDOMAIN), the np policy applies. If np is not defined, the receiver uses sp. If sp is not defined either, p applies. For existing subdomains, the fallback is sp then p (same as DMARC v1).

Does DMARCbis slow down email processing?

No. The Tree Walk adds 1 to 2 DNS queries for a typical 3-label domain. DNS caching mitigates this impact: _dmarc records and NXDOMAIN responses are cached. The 8-query limit ensures bounded processing time, even for deep domains. In practice, the latency difference is negligible.

Does my ESP need to support DMARCbis?

DMARCbis is a receiver-side change. Your ESP does not need to support it specifically. However, verify two critical points: custom DKIM signing (with d= matching your domain) and a custom Return-Path (bounce domain aligned with your From: domain). Both are essential for the strict alignment recommended by DMARCbis.

Glossary

• Author Domain: the domain used in the message From: header. It is the starting point for the Tree Walk and DMARC alignment.
• DNS Tree Walk: the DMARCbis algorithm that walks up the DNS tree label by label to find a _dmarc record and determine the Organizational Domain. Limited to 8 queries.
• Organizational Domain: an organization's primary domain, identified by the Tree Walk (via psd=n or the absence of psd). It is authoritative for the DMARC policy applicable to its subdomains.
• PSL (Public Suffix List): a list maintained by Mozilla of public suffixes. Used by DMARC v1, replaced by the Tree Walk in DMARCbis.
• PSD (Public Suffix Domain): a domain name suffix operated by an entity that delegates subdomains (e.g., co.uk, gouv.fr). Identified by psd=y in the DMARC record.
• PSO (Public Suffix Operator): the entity that administers a PSD and can publish a reference DMARC policy for associated domains.

Related email authentication guides

• DKIM2: what's new and what's changing
• ARC: the authenticated received chain explained
• BIMI, VMC and CMC: DNS compatibility
• Gmail bulk sender 2025

Sources

1. draft-ietf-dmarc-dmarcbis (IETF Datatracker)
2. draft-ietf-dmarc-aggregate-reporting (IETF Datatracker)
3. draft-ietf-dmarc-failure-reporting (IETF Datatracker)
4. DMARC.org Resources
5. PCI DSS 4.0 Summary of Changes (PCI SSC)