DMARC subdomain policy: how sp, np and the tree walk work

DMARC is published on one name, but attackers can use any name under your domain. They can forge a real subdomain like news.example.com, or invent one like payroll-update.example.com. How DMARC covers those names depends on three tags, p, sp and np, and on how receivers find your record. This guide explains the rules in RFC 9989, the standard that replaced RFC 7489 in May 2026.

How does DMARC apply to subdomains?

When a message arrives, the receiver looks at the domain in the visible From address. RFC 9989 calls it the Author Domain. Then it looks for a policy:

1. A record on the From domain itself. If _dmarc.news.example.com exists, that record applies, and its p tag is the policy.
2. Otherwise, the organizational domain's record. The receiver walks up the DNS tree to find the organizational domain, usually example.com, and uses its record.
3. For a subdomain, that record's sp or np tag. sp applies if the subdomain exists, np if it doesn't. If the tag you'd need isn't there, p applies.

So one record at _dmarc.example.com protects every subdomain that doesn't publish its own. Microsoft's DMARC guide says the same: the parent's record "automatically covers all subdomains (including nonexistent subdomains)" that don't have their own record.

What do sp and np mean?

Both tags are defined in section 4.7 and take the same values as p: none, quarantine or reject.

• sp is the policy for existing subdomains of the organizational domain. It doesn't apply to the organizational domain itself.
• np is the policy for non-existent subdomains. If np is absent, receivers apply sp, or p if sp is absent too.

That inheritance means p=reject alone already covers everything. You only need sp or np when you want subdomains treated differently from the main domain.

What counts as a non-existent subdomain?

RFC 9989 uses the definition from RFC 8020. A name doesn't exist if a DNS query for it returns NXDOMAIN. That has some consequences:

• A name with any DNS record exists. www.example.com with only an A record is an existing subdomain, so sp applies, not np.
• A name with other names below it exists too, even with no records of its own.
• Wildcard records make every name exist. If you publish *.example.com, queries for invented names no longer return NXDOMAIN, so np never applies. sp or p covers those names instead.

That's why np is most useful for domains without wildcards, where attackers invent names that have no DNS records at all.

How does the RFC 9989 tree walk find the organizational domain?

RFC 7489 found the organizational domain with the Public Suffix List, a published list of suffixes like .com and .co.uk. RFC 9989 replaced that with a DNS "tree walk" (section 4.10):

1. Query _dmarc at the From domain.
2. Remove the left-most label and query again. Repeat up to the top, stopping early only at a record that carries a psd tag.
3. Long names are shortened first, so the walk never takes more than eight queries.
4. The organizational domain is the name with the fewest labels that has a valid DMARC record, unless a psd tag says otherwise.

For a.mail.example.com, a receiver queries _dmarc.a.mail.example.com, _dmarc.mail.example.com, _dmarc.example.com and _dmarc.com. If records exist at both mail.example.com and example.com, the organizational domain is example.com (the RFC's own example in section 4.10.2).

A record on a subdomain covers only that name

This surprises people. Under the discovery rules, a message from a.mail.example.com uses a record at the From domain, the organizational domain, or a public suffix domain, in that order. A record at mail.example.com is none of those for a.mail.example.com. So example.com's sp applies, not mail.example.com's policy.

RFC 9989 also says sp "will be ignored" in records published on subdomains of an organizational domain. Putting sp=reject in _dmarc.mail.example.com does nothing.

The exception is psd=n. It marks a record's domain as the organizational domain for itself and its subdomains. With psd=n on _dmarc.mail.example.com, that record becomes the policy source for a.mail.example.com. Use it carefully: it also changes alignment, because mail.example.com and example.com would then be separate organizational domains. Most organizations should leave psd out.

Examples of DMARC subdomain policies

Replace the domains and report address with your own.

Everything at reject

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

The main domain, every existing subdomain and every invented subdomain are at reject. This is the simplest end state.

Main domain still testing, invented subdomains blocked

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; np=reject; rua=mailto:dmarc@example.com"

Existing subdomains inherit quarantine. Names that don't exist get reject. This is useful while you're still checking senders, since no legitimate mail should come from a name that doesn't exist in DNS. Receivers that haven't adopted RFC 9989 may not recognize np and would apply quarantine instead.

One subdomain with a different policy

_dmarc.example.com.       TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
_dmarc.news.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

news.example.com gets quarantine while you fix a newsletter tool. Every other subdomain stays at reject. This is safer than sp=quarantine, which would weaken all subdomains at once.

Organizational domain at reject, existing subdomains monitored

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; sp=none; np=reject; rua=mailto:dmarc@example.com"

This works, but it leaves every existing subdomain, such as www or mail, open to spoofing. Use it only briefly, and only if you can't publish per-subdomain records.

Common subdomain mistakes

The sender side matters as much as the policy. Each subdomain that sends mail needs SPF or DKIM that aligns with it. Microsoft notes that each subdomain needs its own SPF record, while DMARC is inherited. With relaxed alignment, the default, a DKIM signature from example.com aligns with mail from news.example.com because both share the same organizational domain.

How to check and set your subdomain policy

1. Look up your current record with the DMARC Checker. Note p, sp, np and any psd tag.
2. List subdomains that send mail. Your aggregate reports show the From domains seen by receivers. Subdomains that send legitimately need aligned SPF or DKIM before you enforce.
3. Decide where you need exceptions. Prefer a separate record on one subdomain over a weaker sp for all of them.
4. Add np=reject if your main policy isn't at reject yet. It's low risk and closes the invented-subdomain gap for receivers that support it.
5. Build the record with the DMARC Generator and publish it at _dmarc.
6. Test real mail. Send from each subdomain to an outside mailbox, then check dmarc=pass and the header.from domain in the Email Header Analyzer.

Next steps

1. Read DMARC record examples for every tag, including t test mode and psd. For the basics, see what DMARC is.
2. If you're still at p=none, follow the staged plan in moving DMARC from p=none to p=reject.
3. Lock down domains that never send mail using the parked domain checklist.
4. Run the Email Health Check to see your SPF, DMARC and MX together. iBlockSpam's domain monitoring can alert you if your DMARC record changes later.

Browse our other SPF, DKIM and DMARC guides.