sp= applies to real, existing subdomains that are part of your DNS namespace. np= applies to subdomains that do not exist at all. That separation matters because it lets domain owners state a policy for delegated subdomains and a different policy for invented ones that attackers may use in spoofed mail.
How sp= and np= split DMARC policy by subdomain type
dmarc uses these tags to let you apply different policy choices to different parts of your DNS namespace. The key difference is whether the subdomain exists as a real delegated name or is only an invented, non-existent name that could be used in spoofing.
That distinction matters because a policy for existing subdomains is about names you control today, while a policy for non-existent subdomains is about defensive coverage for names you have not delegated and do not want used to impersonate you.
In practice, sp= is the policy inheritance point for subdomains that exist under the parent domain, while np= is the policy setting for subdomains that do not exist in DNS at all. Together they help close a gap where attackers may try to exploit lookalike or fabricated subdomain names in email.
Why the distinction matters for spoofing and delegation
A delegated subdomain may need its own operational treatment because it can be used by a business unit, SaaS platform, or mail sender that legitimately lives under your domain. A non-existent subdomain has no legitimate owner or sender, so its policy is mainly about preventing abuse of names that should never be trusted as mail origins.
That is why the two settings should be viewed as complementary rather than interchangeable. If you only think in terms of a single parent policy, you can miss the difference between mail sent from a real child domain and mail claiming to come from a name that was never provisioned.
For background on staged DMARC deployment, alignment, and report-driven rollout, DMARC, SPF and DKIM Guide explains how policy choices evolve from monitoring to enforcement.
How to think about policy design without overcomplicating it
Start by separating three cases: the organizational domain, real subdomains that actually exist, and names that do not exist but could still be targeted in spoofed mail. That mental model makes it easier to choose a parent policy, a subdomain policy, and a non-existent-subdomain policy without accidentally treating all subdomains the same.
For large organizations, this also becomes a governance issue. Different teams may own different subdomains, but the enterprise still needs a consistent rule for names that should never be accepted as authentic mail sources. Email Identity and BEC Guide covers the operational side of stopping spoofing, inbox abuse, and domain impersonation across a broader email identity program.
Risk and Threat Considerations
Attackers often exploit domain confusion rather than protocol weakness. If the policy for non-existent subdomains is weak or absent, a spoofed message can look more plausible simply because it uses a name that resembles a real business subdomain or an expected partner path.
Failure mechanism: A recipient or downstream mail system treats an invented subdomain as credible because the policy does not clearly distinguish non-existent names from delegated ones, allowing spoofed mail to inherit trust it should not have.
Impact: That can increase the success rate of phishing, invoice fraud, and brand impersonation, especially where users recognize the parent domain but do not inspect the exact subdomain.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V10 — OAuth and OIDC | DMARC policy choices protect email-origin trust, which supports authenticated messaging flows. |
| Recommendation — Use V10-style verification to ensure email trust signals are explicit and enforced. | ||
| CIS Controls v8 | CIS-9 — Email and Web Browser Protections | The subject is email spoofing defense and policy enforcement across sender domains. |
| Recommendation — Harden mail handling and anti-spoofing controls for domain-based email trust. | ||
Practitioner Guidance
What to verify: Check whether your DMARC record expresses the policy you want for existing subdomains separately from the policy you want for non-existent subdomains. Confirm that the choice matches your delegation model, not just your current mail senders.
Decision rule: If a subdomain is real and used operationally, treat it as a governed sender path; if it is not provisioned at all, treat it as an anti-spoofing case and make the policy explicit rather than relying on the parent domain alone.
Practitioner takeaway: The practical goal is not more DMARC complexity, it is policy precision, so legitimate subdomains are handled deliberately while invented ones are denied a trust path.
Related resources from NHI Mgmt Group
- What is the difference between DMARC enforcement and a Verified Mark Certificate?
- What is the difference between DMARC monitoring and DMARC enforcement for public-sector trust?
- What is the difference between SP-initiated SSO and IdP-initiated SSO in practical deployment terms?
- What is the difference between SPF, DKIM, and DMARC in email authentication?