One Missing DMARC Tag, and Your Subdomains Can Lose Protection Under RFC 9989: When ‘psd’ Matters for Domains with Multi-Part Suffixes

Key takeaways

• Domain-based Message Authentication, Reporting, and Conformance (DMARC) RFC 9989 no longer uses the Public Suffix List (PSL) to find the Organizational Domain. Instead, it uses a DNS Tree Walk. The example below shows how this change can leave your subdomains open to spoofing.
  • If an Organizational Domain under RFC 7489 (such as acmecorp.uk.com) has no ‘psd’ tag, RFC 9989 continues to walk up the DNS tree to identify the Organizational Domain, and the outcome depends on what the higher levels publish.
  • If the parent (such as uk.com) also publishes a DMARC record without a ‘psd’ tag, then it could be treated as the Organizational Domain by RFC 9989, and subdomains without their own record would inherit the associated policy.
• Publishing ‘psd=n’ on your Organizational Domain is a low-risk way to make the boundary explicit and to limit the potential impact of records published higher in the tree.

The scenario

Consider an author domain, it.acmecorp.uk.com, with no DMARC record of its own. Its parent, acmecorp.uk.com, is protected:

v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; fo=1; rua=mailto:dmarc_rua@emaildefense.proofpoint.com; ruf=mailto:dmarc_ruf@emaildefense.proofpoint.com

The owner of acmecorp.uk.com intends for email from spoofed subdomains to be protected, but whether that happens depends on which DMARC standard the receiver follows.

RFC 7489 (original DMARC)

1. The receiver checks the Public Suffix List: uk.com is listed as a public suffix.
2. That makes acmecorp.uk.com the Organizational Domain.
3. it.acmecorp.uk.com has no record, so it inherits from acmecorp.uk.com.
4. Result: ‘sp=reject’ applies, and RUA/RUF reports are sent to Proofpoint®.

RFC 9989 (DNS Tree Walk)

1. The receiver queries _dmarc.it.acmecorp.uk.com. There is no record.
2. The DNS Tree Walk continues to acmecorp.uk.com. There is a record, but no ‘psd’ tag.
3. The DNS Tree Walk continues to uk.com. There is a record, but no ‘psd’ tag . DMARC record for uk.com as of October 12, 2026:

v=DMARC1; p=none; rua=mailto:support@centralnic.com; ruf=mailto:support@centralnic.com

1. The DNS Tree Walk continues to .com. There is no record.
2. With no ‘psd’ signal found, the fallback applies and the domain with the fewest labels that has a valid DMARC record becomes the Organizational Domain. That domain is uk.com.
3. it.acmecorp.uk.com has no record, so it inherits from its Organizational Domain, uk.com.
4. Result: ‘p=none’ applies, and RUA/RUF reports are sent to centralnic.com.

What changed

Email from acmecorp.uk.com itself is unaffected because the domain has its own DMARC record. The exposure is on subdomains below that domain.

• Email traffic originating from the spoofed subdomains moves from protected to unprotected: 
  • DMARC policy: ‘p=reject’ under RFC 7489 and ‘p=none’ under RFC 9989
• Aggregate (RUA) and forensic (RUF) reports are no longer sent to Proofpoint:
  • RUA/RUF reports are sent to Proofpoint under RFC 7489 and to CentralNic under RFC 9989
• The Organizational Domain also changes, which can affect alignment outcomes.
  • acmecorp.uk.com under RFC 7489 and uk.com under RFC 9989

The fix: declare your boundary

Add ‘psd=n’ to the DMARC record on acmecorp.uk.com:

v=DMARC1; p=reject; sp=reject; psd=n; adkim=s; aspf=s; fo=1; rua=...; ruf=...

The DNS Tree Walk now stops at acmecorp.uk.com, which becomes the Organizational Domain, and the ‘sp=reject’ policy and report destinations apply to subdomains such as it.acmecorp.uk.com. In this scenario, the tag makes inheritance behave the same under RFC 7489 and RFC 9989.

What to check

• Do you operate an Organizational Domain under a multi-part suffix (uk.com, co.uk, and similar)?
• Does your domain publish a ‘psd’ tag? If not, review the Organizational Domain as determined by the DNS Tree Walk.
• Do any subdomains rely on inherited policy?
• Are subdomain-spoofing protections and RUA/RUF destinations the same under both standards?

Not every multi-part suffix creates this exposure. The risk appears when a higher-level suffix publishes its own record without declaring itself a public suffix domain. You cannot control what the owner of a suffix publishes, but you can control what your own domain declares.

Other scenarios

In the scenario above, .com has no DMARC record. If it did, the result would depend on the ‘psd’ tag and record contents of .com:

• No ‘psd’ tag or ‘psd=n’: .com would be the Organizational Domain, and its policy and RUA/RUF addresses would apply to subdomains.
• ‘psd=y’: The walk would stop, and uk.com would remain the Organizational Domain.

Publish ‘psd=n’ on the domain you want treated as the Organizational Domain to avoid this complexity.

How Proofpoint can help

Proofpoint Email Fraud Defense (EFD) analyzes each of your domains twice, once under RFC 7489 and once under RFC 9989. It flags domains where the resolved policy differs, so you can find cases like this before enforcement decisions create surprises. Proofpoint Professional Services consultants can also help review your domain structure and records.

Learn More

Visit Proofpoint Email Fraud Defense to learn how Proofpoint can help you simplify DMARC deployment, improve email authentication, and accelerate your journey to enforcement.

To learn how Proofpoint helps organizations defend against AI-scaled threats and advanced impersonation attacks across email and digital communications, visit Proofpoint Collaboration Security or contact your Proofpoint representative today.