Public Suffix Domain (PSD) DMARC explained (what it is, when it applies, and why admins should care)

PSD DMARC is one of those DMARC topics that sounds niche until you run into a domain space where it matters.

If you only manage a normal domain like example.com, you may never need to publish anything specifically for PSD DMARC. But if you troubleshoot mail in regulated namespaces, branded suffixes, or receiver-side filtering systems, it is worth understanding because it changes where DMARC policy can be discovered.

The short version is:

• standard DMARC looks for policy at the exact From domain and then at the Organizational Domain
• PSD DMARC extends that logic so a participating public suffix can also publish DMARC policy
• this mainly helps protect against abuse involving domains under that suffix that do not have their own usable DMARC policy

Start with the normal DMARC boundary

In RFC 7489, DMARC depends on the concept of an Organizational Domain.

That requires a receiver to know where the registrable boundary is. For example:

• for mail.example.com, the Organizational Domain is normally example.com
• for service.example.co.uk, the Organizational Domain is normally example.co.uk

That second example is why DMARC implementations use a public suffix list. A suffix such as co.uk is not the registrant's domain. It is the registry-controlled boundary below which domains are registered.

If you want a refresher on the registrable boundary itself, What is an apex domain? is the adjacent topic.

What is a Public Suffix Domain?

RFC 9091 defines a Public Suffix Domain (PSD) as a place in the DNS tree where independent organizations can register names below it.

Real-world examples include suffixes such as:

• com
• org
• co.uk
• specialized suffixes such as bank

So if example.org is the registered domain, the PSD is org. If example.co.uk is the registered domain, the PSD is co.uk.

The important distinction is that a PSD is usually the registry boundary, not the organization you are trying to authenticate.

Why standard DMARC stops short

Normal DMARC is built for domain owners to publish policy for their own domain and, optionally, its subdomains.

That works well for:

• example.com
• news.example.com
• billing.example.com

But it leaves a gap for abuse involving names below a public suffix that are not valid or do not publish their own DMARC record.

RFC 7489 explicitly says DMARC does not solve cousin-domain abuse in general. That is why Domain lookalike/homograph defense for email exists as a separate problem space.

PSD DMARC narrows one part of that gap for participating suffixes.

What PSD DMARC adds

In RFC 9091, receivers that support PSD DMARC can do one additional policy-discovery step.

Very roughly, the lookup order becomes:

1. check the exact From domain for a DMARC record
2. if needed, check the Organizational Domain
3. if still nothing usable is found, and the relevant public suffix is a participating PSD DMARC suffix, check the PSD itself

That means a receiver may consult a DMARC record published at a public suffix such as _dmarc.bank or another participating PSD boundary.

The key limitation is just as important as the feature:

• PSD policy is a fallback step
• it does not override an Organizational Domain that already publishes its own DMARC policy

So if example.bank already has its own DMARC record, that policy is still the one that matters for mail from example.bank.

When PSD DMARC actually applies

This is the part most admins care about.

PSD DMARC is not something receivers should blindly apply to every public suffix on the Internet. RFC 9091 describes it as an experimental extension, and it expects receivers to know which PSDs are valid PSD DMARC participants.

Operationally, PSD DMARC matters in cases like these:

1. A special or regulated suffix wants protection across the whole namespace

RFC 9091 uses examples such as a regulated namespace like .bank.

If an attacker spoofs mail from a non-existent domain under that suffix, PSD DMARC can let the suffix operator publish a policy that helps receivers treat that mail as suspicious or rejectable, even though the fake domain never published its own DMARC record.

That is useful because defensive registration of every typo and cousin domain is not scalable.

2. A branded suffix behaves more like one organization's domain tree

RFC 9091 also calls out branded PSDs such as .google.

Those suffixes may appear on the public suffix list for technical reasons, but operationally they are closer to one organization controlling the full tree. PSD DMARC gives them a way to benefit from DMARC at that boundary too.

3. A receiver is evaluating mail from a domain under a participating PSD that has no usable DMARC policy of its own

This is the practical fallback case.

If the receiver cannot apply a host or Organizational Domain DMARC policy, PSD DMARC gives it one more place to look, but only when that PSD is known to participate.

What the np tag is for

RFC 9091 adds a DMARC tag named np.

It stands for the requested receiver policy for non-existent subdomains. Its values are the same as p and sp:

• none
• quarantine
• reject

Why this matters:

• a PSD operator may especially care about mail claiming to be from domains that do not exist at all
• the risk of rejecting non-existent-domain mail is usually lower than rejecting mail for real, active domains

If np is not present, the receiver falls back to sp or p as defined in RFC 9091.

A concrete example

Imagine a namespace where registrations happen under bank.

There is a real institution:

• example.bank

But an attacker sends mail with:

• From: support@examp1e.bank

Assume examp1e.bank is not actually registered.

Without PSD DMARC, a receiver may find no DMARC policy at the fake domain and no usable Organizational Domain policy beyond it.

With PSD DMARC support, if bank is a participating PSD, the receiver can also query _dmarc.bank and apply the PSD operator's published handling and reporting rules.

That does not make cousin-domain abuse disappear everywhere. It does mean a participating suffix can extend some DMARC protection to a part of the namespace that plain DMARC could not cover well.

What PSD DMARC does not do

This is where confusion starts, so it is worth being explicit.

PSD DMARC does not mean:

• every TLD or public suffix now automatically enforces DMARC for everyone under it
• your own domain-level DMARC record becomes optional
• mailbox providers must all support PSD DMARC the same way
• DMARC suddenly solves all lookalike-domain abuse under unrelated suffixes

It also does not replace normal sender hygiene. You still need aligned SPF and DKIM for your real domains. If that part needs a refresher, see DMARC identifier alignment deep dive.

Why privacy and reporting are a big deal here

RFC 9091 spends meaningful time on privacy because PSD-level reporting can leak information upward to the public suffix operator.

That is why the document is careful about where PSD DMARC reporting is appropriate, especially for multi-organization suffixes.

Two practical takeaways:

• support is intentionally conservative
• feedback tied to PSD DMARC is limited more carefully than normal org-level DMARC reporting

In particular, RFC 9091 says PSD DMARC feedback must be limited to aggregate reports, not failure-report style leakage.

Why domain owners should care

If you run a normal business domain under a common suffix such as .com, the immediate effect may be small today.

But PSD DMARC still matters if any of these are true:

1. Your organization uses a regulated or special-purpose suffix where the registry may enforce stricter email authentication expectations.
2. You operate in a branded suffix environment.
3. You run inbound filtering, gateways, or analysis tooling and need to explain why a receiver found policy at the PSD layer.
4. You review DMARC reports or spoofing incidents involving non-existent lookalike domains inside one controlled namespace.

The biggest mistake is assuming PSD DMARC is "just another tag" in your own domain's record. It is really about who is allowed to publish fallback policy at the registration boundary.

Why receiver and tooling admins should care even more

If you operate a receiver, secure email gateway, or authentication-analysis tool, PSD DMARC is more operationally relevant.

You need to know:

• whether your DMARC engine supports RFC 9091 at all
• how it determines participating PSDs
• whether its public suffix list data is current
• how it handles the np tag

This is another reason stale public suffix data is dangerous. The Public Suffix List itself warns that static copies age badly. If the suffix boundary logic is outdated, Organizational Domain discovery can be wrong even before PSD DMARC enters the picture.

The safe mental model

Use this model and PSD DMARC gets much easier to reason about:

• DMARC normally works at the domain and Organizational Domain levels
• a PSD is the registry boundary above the Organizational Domain
• PSD DMARC is an extra, not-universal fallback that lets certain participating suffixes publish policy there too
• it is most useful for branded suffixes and regulated spaces, especially around non-existent cousin domains
• it does not replace your own domain's DMARC deployment

What admins should do in practice

For most domain owners:

1. Keep publishing and enforcing DMARC on your own domains normally.
2. Do not assume PSD DMARC protects you if your own domain has weak SPF/DKIM alignment.
3. If you operate under a special suffix, verify whether the registry publishes guidance about DMARC requirements.

For receiver or tooling admins:

1. Check whether your DMARC implementation supports RFC 9091.
2. Verify how PSD participation data is sourced and updated.
3. Test how non-existent domains under participating suffixes are classified.
4. Make sure analysts can distinguish ordinary DMARC policy discovery from PSD fallback discovery.

Bottom line

Public Suffix Domain DMARC is an extension to DMARC policy discovery, not a replacement for normal DMARC.

It matters when a participating public suffix wants to publish fallback DMARC policy at the registry boundary, especially to help with abuse involving non-existent domains under that suffix. Most domain owners still need to focus first on ordinary SPF, DKIM, and DMARC deployment on their own domains, but admins who work in special namespaces or on receiver-side tooling should absolutely know when PSD DMARC is in play.