DMARC Subdomain Policy: How the sp Tag Actually Works

A DMARC record on your main domain does more than protect that one name. Through the sp tag and policy inheritance, it also governs every subdomain, and getting that wrong is how a domain running p=reject still gets spoofed.

This is the DMARC sp tag subdomain policy explained: what a subdomain inherits, what you can override, and where the gaps hide. The rules come from RFC 9989, the 2026 DMARC standard that replaced RFC 7489.

How subdomains inherit the DMARC policy#

A DMARC record uses three policy tags. The p tag sets the policy for the organizational domain itself. The sp tag sets the policy for existing subdomains. The np tag sets the policy for subdomains that do not exist in DNS.

The sp tag is described in RFC 9989 as the assessment policy for all subdomains of the organizational domain. If sp is absent, receivers apply the p value to subdomains. So inheritance is the default: publish nothing extra and every subdomain follows p.

When a subdomain has no record of its own, the receiver climbs the DNS tree to your organizational domain and reads its policy. The table below shows exactly which value wins.

Which policy a subdomain actually gets#

Read the precedence in one line. For a subdomain that exists, the order is: its own record, then sp, then p. For a subdomain that does not exist, the order is: np, then sp, then p.

The single trap worth memorizing is that a subdomain's own DMARC record wins over the parent's sp. Receivers query the exact From domain first. If they find a valid record there, they use its p tag and never look at the parent. A weak record on a subdomain quietly overrides a strict sp above it.

Does a subdomain need its own DMARC record?#

Usually not. Because subdomains inherit the p policy through sp, one record on the organizational domain covers the whole tree. You publish a separate record on a subdomain for one reason: to give that subdomain a policy that differs from the parent.

Note the split with SPF and DKIM. A DMARC record is inherited, but SPF and DKIM are not. Every subdomain that sends mail still needs its own SPF and DKIM so that its mail can align and pass DMARC. Inheritance covers the policy, not the authentication.

• One org-domain record, sp absent: every subdomain follows p. Simplest, and correct for most domains.
• One org-domain record with sp: every subdomain gets the sp policy, the parent keeps p.
• A record on a specific subdomain: only that subdomain changes; the rest still inherit.

Before you start#

Publishing or changing a subdomain policy is a DNS edit, but a wrong one blocks real mail. Line these up first.

• Know your organizational domain, the registered name your subdomains inherit from.
• Inventory the subdomains that send mail, and any bulk services sending on their behalf.
• Confirm SPF and DKIM are configured for each sending subdomain, since alignment needs them.
• Decide your target policies. If you are new to none, quarantine and reject, work through a staged DMARC rollout first.
• Have an rua address ready so aggregate reports show what your change did before you tighten further.

How to set a different DMARC policy for a subdomain#

1. 1

   Read the parent record

   Look up the TXT record at _dmarc.example.com and note its p tag and whether sp or np are already present. That record is what every subdomain inherits today.

2. 2

   Decide inheritance or override

   If all subdomains should share one policy, you only need the parent. If one subdomain needs something different, you will publish a record just for it.

3. 3

   To change all subdomains at once, add sp

   Edit the parent record, for example v=DMARC1; p=reject; sp=quarantine; rua=mailto:[email protected]. Now the org domain rejects and every existing subdomain quarantines.

4. 4

   To change one subdomain, publish its own record

   Add a TXT record at _dmarc.sub.example.com, for example v=DMARC1; p=none; rua=mailto:[email protected]. This overrides the inherited policy for sub.example.com only.

5. 5

   Cover subdomains that do not exist

   Add np to the parent, for example np=reject, so mail from names like billing.example.com that have no DNS record is rejected. No legitimate sender uses a non-existent subdomain.

6. 6

   Verify, then tighten

   Query the records again to confirm they resolve, then watch aggregate reports at p=none or sp=none before moving a subdomain to quarantine or reject.

Platform differences: the standard vs the docs you will find#

DMARC is published in DNS, so the record you create is the same at any registrar. What differs is which specification a provider's guidance describes, and how each receiver enforces the result.

Microsoft's own DMARC guidance still cites RFC 7489 and documents the pct tag, which RFC 9989 removed. Its subdomain behavior is correct, but it steers you toward per-subdomain records rather than the sp tag during rollout. The table pins down where the two line up.

The np tag and non-existent subdomain spoofing#

Attackers like subdomains that do not exist because nobody watches them. A From address of invoices.example.com or vpn.example.com reads as plausible whether or not the zone exists, and a spoofer never has to pass authentication if the policy is permissive.

The np tag closes that. It sets the DMARC policy for non-existent subdomains, which RFC 9989 identifies by a DNS lookup that returns NXDOMAIN. If np is absent, non-existent subdomains fall back to sp, and if that is also absent, to p.

np=reject is unusually safe to deploy early. Because no legitimate mail comes from a name that does not resolve, you can reject there while your real senders are still being tuned at p=none or sp=none. It is the one subdomain control most domains can turn on without breaking anything.

What to do when it does not work#

Most subdomain policy problems come from inheritance not behaving the way you assumed. Match the symptom to the cause.

A faster way to handle what does land in the inbox#

DMARC is a sending-side control you publish in DNS, so nothing here is something an email client configures for you. AI Emaily is not a DMARC monitoring service; if you want aggregate reports turned into dashboards, use a platform built for that.

What a client owns is the receiving side. Authentication results are one signal among several about how far to trust a message, and AI Emaily treats every incoming email as untrusted input. It runs spam and phishing protection on what arrives, triages the rest, and drafts replies you approve before anything sends, with undo and an audit trail. It works across Gmail, Outlook and any IMAP account, and a 7-day free trial lets you see it on your own mail.

We build AI Emaily, so treat this as the one commercial note on the page. The subdomain rules above stand on their own whether or not you ever try it.