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

URL: https://iblockspam.com/blog/dmarc-subdomain-policy-sp
Last updated: 2026-10-09
Published: 2026-10-09
Topic: SPF, DKIM & DMARC
Author: iBlockSpam Team

> How DMARC covers subdomains: the organizational domain, the sp and np tags, the RFC 9989 DNS tree walk, and the subdomain mistakes that leave gaps.

## Short answer

A subdomain without its own DMARC record uses the record of its organizational domain. The sp tag sets the policy for subdomains that exist, np sets it for subdomains that don't exist, and both fall back to p. A subdomain that publishes its own record uses that record's p instead.

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](https://www.rfc-editor.org/rfc/rfc9989.html), 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](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure) says the same: the parent's record "automatically covers all subdomains (including nonexistent subdomains)" that don't have their own record.

| From domain | Has its own record? | Policy used |
|---|---|---|
| `example.com` | Yes | `p` |
| `news.example.com` | Yes | `p` from `_dmarc.news.example.com` |
| `shop.example.com` (exists in DNS) | No | `sp` from `_dmarc.example.com`, else `p` |
| `invented.example.com` (NXDOMAIN) | No | `np`, else `sp`, else `p` |

## What do sp and np mean?

Both tags are defined in [section 4.7](https://www.rfc-editor.org/rfc/rfc9989.html#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](https://www.rfc-editor.org/rfc/rfc8020.html). 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](https://www.rfc-editor.org/rfc/rfc9989.html#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](https://www.rfc-editor.org/rfc/rfc9989.html#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

| Mistake | Effect | Fix |
|---|---|---|
| `sp=none` left in place | Real subdomains can be spoofed freely | Remove `sp` or set it to `quarantine` or `reject` |
| `sp` in a subdomain's record | Ignored by receivers | Put `sp` on the organizational domain's record |
| Expecting a subdomain record to cover names below it | Deeper names use the organizational domain's policy | Publish records where you need them, or rely on the parent |
| Relying on `np` with wildcard DNS | `np` never applies, because every name exists | Make sure `sp` or `p` is strong enough |
| Moving to `p=reject` without checking subdomain senders | Legitimate mail from `news.` or `support.` fails | Check aggregate reports for subdomain sources first |
| Two records at one `_dmarc` name | Receivers discard both | Keep exactly one |
| `aspf=s` or `adkim=s` with subdomain senders | Subdomain mail fails alignment | Leave alignment relaxed unless you need strict |

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](https://iblockspam.com/tools/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](https://iblockspam.com/tools/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](https://iblockspam.com/tools/email-header-analyzer).

## Next steps

1. Read [DMARC record examples](https://iblockspam.com/blog/dmarc-record-examples) for every tag, including `t` test mode and `psd`. For the basics, see [what DMARC is](https://iblockspam.com/blog/what-is-dmarc).
2. If you're still at `p=none`, follow the staged plan in [moving DMARC from p=none to p=reject](https://iblockspam.com/blog/dmarc-none-to-reject-small-business).
3. Lock down domains that never send mail using the [parked domain checklist](https://iblockspam.com/blog/protect-parked-domains-from-spoofing).
4. Run the [Email Health Check](https://iblockspam.com/tools/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](https://iblockspam.com/blog/topic/authentication).

## Frequently asked questions

### Does a DMARC record cover subdomains?

Yes. A record at _dmarc.example.com applies to every subdomain that doesn't publish its own record. Existing subdomains get the sp policy, non-existent ones get np, and both fall back to p. Microsoft's documentation says the same: the parent's record covers all subdomains, including nonexistent ones.

### What is the difference between sp and np in DMARC?

sp applies to subdomains that exist in DNS, such as news.example.com with its own records. np applies to subdomains that don't exist, meaning a DNS query for the name returns NXDOMAIN. np was experimental in RFC 9091 and became standard in RFC 9989 in May 2026.

### Can I put sp in a subdomain's DMARC record?

You can, but receivers ignore it. RFC 9989 says sp is ignored in records published on subdomains of an organizational domain. Subdomains below that subdomain look up the organizational domain's record, not the one in between, unless you mark the subdomain as its own organizational domain with psd=n.

### Should I use sp=none while I test subdomains?

Prefer a separate record on the subdomain you're testing, such as p=none on _dmarc.news.example.com. sp=none opens every other subdomain to spoofing, including ones attackers invent. If you use it at all, pair it with np=reject so invented names stay protected.

### Does p=reject on my main domain block mail from my subdomains?

Only mail that fails DMARC. Subdomains that send legitimate mail need SPF or DKIM that aligns with the subdomain, which relaxed alignment allows for any domain under the same organizational domain. Check aggregate reports for subdomain senders before you enforce.

## Sources

- [RFC 9989: DMARC, section 4.7: DMARC Policy Record Format (sp and np tags)](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.7)
- [RFC 9989, section 4.10: DNS Tree Walk](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.10)
- [RFC 9989, Appendix B.4: Tree Walk Examples](https://www.rfc-editor.org/rfc/rfc9989.html#appendix-B.4)
- [RFC 8020: NXDOMAIN: There Really Is Nothing Underneath](https://www.rfc-editor.org/rfc/rfc8020.html)
- [RFC 9091: Experimental DMARC Extension for Public Suffix Domains (obsoleted by RFC 9989)](https://www.rfc-editor.org/rfc/rfc9091.html)
- [RFC 7489: DMARC (obsoleted by RFC 9989)](https://www.rfc-editor.org/rfc/rfc7489.html)
- [Microsoft Learn: Set up DMARC to validate email in Microsoft 365](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure)

## Free tools for this guide

- [DMARC Checker](https://iblockspam.com/tools/dmarc-checker): Check your policy, reporting and the safe path from p=none to reject.
- [DMARC Record Generator](https://iblockspam.com/tools/dmarc-generator): Build a DMARC record with the right policy, reporting and alignment settings.
- [Email Health Check](https://iblockspam.com/tools/email-health-check): Grade your domain's MX, SPF, DKIM, DMARC and transport security in one scan.
- [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer): Trace hops and authentication results — runs entirely in your browser.

---

Source: iBlockSpam, https://iblockspam.com/blog/dmarc-subdomain-policy-sp (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt