DMARC Subdomain Policy: sp= and np= Explained | DMARCguard Skip to main content<br>11 min read Share
DMARC Subdomain Policy: How sp= and np= Protect Every Subdomain<br>A p=reject policy on your root domain does nothing for mail.example.com — unless you tell DMARC what to do with subdomains.<br>A DMARC subdomain policy is the rule a domain owner publishes for mail sent from subdomains of an organizational domain. It is controlled by two tags: sp= (for existing subdomains) and np= (for non-existent subdomains, added in DMARCbis / RFC 9989). When you set neither, subdomains inherit the parent domain’s p= policy.<br>This post assumes you already know the basics. If you do not, start with our DMARC fundamentals guide and come back. Most subdomain spoofing succeeds because the parent domain left sp= and np= unset, so a do-nothing p=none quietly covers every subdomain too.<br>Here is what to publish, and why: how a subdomain policy resolves, sp= versus np=, the DMARCbis DNS tree walk, whether receivers actually honor these tags, and the exact record to set.<br>What is the DMARC sp tag (subdomain policy)?<br>The sp= tag sets the DMARC policy for mail from existing subdomains of your organizational domain. It takes the same three values as p= — none, quarantine, or reject — and lives in the parent domain’s _dmarc record. If you omit sp=, subdomains use whatever p= is set to.<br>Two details matter. First, the organizational domain is the registrable domain at the top of your namespace — example.com, not mail.example.com. Second, sp= is only meaningful on the organizational domain’s record. RFC 9989 §4.7 states that sp= “will be ignored for DMARC Policy Records published on subdomains,” so putting sp= on _dmarc.mail.example.com does nothing — set it on the parent.<br>Here is how the three policy tags relate:<br>TagApplies toValuesDefault when unsetp=the organizational domain itselfnone / quarantine / rejecttreated as none if missingsp=existing subdomainsnone / quarantine / rejectfalls back to p=np=non-existent subdomainsnone / quarantine / rejectfalls back to sp=, then p=<br>For the full DMARC tag grammar and how to publish the record itself, see the full DMARC tag reference and how to publish the record. The rest of this guide is about behavior: how those tags resolve and how to use them to close a spoofing gap.<br>How subdomains inherit the DMARC policy<br>Subdomains do not need their own DMARC record. A receiver applies the most specific policy it finds, in this order: (1) the subdomain’s own _dmarc record if one exists, otherwise (2) the parent’s sp= value, otherwise (3) the parent’s p= value. RFC 9989 §4.10.1 spells out exactly this precedence.<br>Walk it through with example.com. Suppose the parent publishes v=DMARC1; p=reject; sp=quarantine. Mail from news.example.com, which has no record of its own, is quarantined on failure (the sp= value). Mail from shop.example.com, which publishes its own _dmarc record with p=none, is governed by that record — the subdomain’s own policy wins.<br>The bare p=reject footgun<br>A record of just v=DMARC1; p=reject is processed as sp=reject too. So the moment you reach enforcement on the parent, every unsigned subdomain — your Marketo or ESP send domain, a status page, a legacy app — is silently rejected unless its mail is DMARC-aligned. The fix is not to back off the parent. It is to set sp= intentionally.
This inheritance is also why a permissive parent leaves subdomains exposed. If p=none is in place and sp= is unset, no subdomain is protected either.<br>Key finding 57.9% of DMARC-protected domains sit at p=none — and with no sp= set, every subdomain inherits that do-nothing policy<br>Source: State of Email Authentication 2026 — 5,499,028 Tranco domains, scan February 27, 2026 sp=none vs sp=reject — subdomain policy examples<br>Use sp=reject when no subdomains send legitimate mail (the common case). Use sp=none only when a subdomain sends mail that is not yet DMARC-aligned and you are still in monitoring mode. The two configurations below look similar and behave very differently:<br>DNS TXT record — _dmarc.example.com dns
# Root protected, subdomains WIDE OPEN — the exposed combination<br>v=DMARC1; p=reject; sp=none
# Root in monitoring, subdomains locked down — protect inactive<br># subdomains while you still test the parent policy<br>v=DMARC1; p=none; sp=reject
The first record protects the root and leaves subdomains wide open — the exposed one, and the exact gap attackers look for. The second puts the root in monitoring while locking down subdomains, which is useful when you want to protect inactive subdomains before the parent reaches enforcement.<br>If you have no legitimate subdomain senders, the strongest posture is sp=reject paired with np=reject (covered next). Getting subdomains to enforcement is part of reaching a domain-wide p=reject — the same journey as moving from p=none to enforcement on the parent.<br>The np= tag — policy for non-existent subdomains (DMARCbis, RFC 9989)<br>The np= tag, introduced in DMARCbis (RFC 9989 §4.7), sets...