What is the difference between p, sp and np in a DMARC record?

They are standing orders for three different doors. p is the policy for the organisational domain itself. sp is the policy applied to mail from existing subdomains that do not publish their own DMARC record; if sp is absent, p applies to them. np — new in the current specification, RFC 9989 — applies to subdomains that do not exist at all (the DNS returns NXDOMAIN); the fallback order is np, then sp, then p. A subdomain that publishes its own _dmarc record overrides all of this with its own policy, and its reports go to its own rua address — the root domain's reports no longer show it. 'Exists' has a precise meaning: the query does not return NXDOMAIN; an empty (NODATA) answer still counts as existing.

Why does every ESP make me send from a subdomain?

Two mechanical reasons and one organisational one. Mechanically, ESPs delegate: SendGrid's return-path subdomain and Amazon SES's custom MAIL FROM subdomain exist because the envelope sender must be a domain the ESP controls records under (via your CNAME delegation) while the visible From stays your brand; Mailchimp's variant authenticates a subdomain's DKIM so DMARC passes on aligned DKIM. Organisationally, separating traffic types (marketing vs transactional vs corporate) contains reputation and blast radius. One popular justification is folklore, though: Gmail's sender guidelines never mention subdomains — and Gmail counts sending volume at the primary domain (2,500 root plus 2,500 subdomain messages still make you a bulk sender, permanently), so splitting does not dilute bulk-sender obligations. Google's separation advice exists in its App Engine bulk-mail documentation and speaks of different domains per function, not a Gmail subdomain rule.

If my root DMARC is p=reject, can a hijacked subdomain still send mail as me?

Yes — and the current specification works the attack itself in its security considerations: an attacker who controls a delegated subdomain (for example an abandoned ESP subdomain whose CNAME still points at a service someone else can claim) can send mail that authenticates from that subdomain and passes DMARC under relaxed alignment, because policy is only consulted when authentication FAILS. Your p and sp govern failing mail; a hijacked subdomain's mail passes, so policy never gets a vote. The defences are inventory and hygiene: audit every subdomain delegation, remove CNAMEs to deprovisioned services, and read your aggregate reports for subdomain sources you don't recognize.

DMARC · Subdomains · Policy

Sending subdomains: your root policy has two deputies you've never met

First published 20 October 2026 · Semantics from RFC 9989 (§4.7, §3.2.13, §4.10.1) read directly, with the RFC 7489 dialect differences kept visible. The Google “separate subdomains” claim is corrected against Google's own pages in §3.

ONE IDENTITY, THREE DOORS p = the root · sp = existing subdomains · np = subdomains that don't exist

Your organisational domain is the identity; subdomains are staff badges issued in its name. DMARC's root record carries standing orders for badges you never explicitly configured — and, since the current specification, even for badges that don't exist. Most owners have set sp/np by accident: by leaving them blank.

Fallback order: np → sp → pBlank doesn't mean off — it means “inherit p”

The worked example (memorize this table)

Root record: v=DMARC1; p=reject; sp=quarantine; np=reject

Mail claims to be from	Governing policy	Why
`example.com` (the root)	reject	`p` — the root's own door
`shop.example.com` — exists, no own record, auth fails	quarantine	`sp` — the existing-subdomain deputy
`ghost.example.com` — never created (NXDOMAIN), auth fails	reject	`np` — the ghost deputy (9989-era receivers; a 7489-era receiver ignores `np` and lands on `sp`=quarantine — dialects differ, one reason np is a seatbelt not a wall)
`billing.example.com` — published its OWN `_dmarc` with `p=none`	none	Its own record overrides the root entirely — and its reports go to its rua. Your root reports just went blind to it
Any of them, with only `p=reject` at the root	reject everywhere	Blank sp/np inherit p — the “accidental fortress” many domains already live in

One precision: sp inside a subdomain's own record is ignored in both spec dialects. And discovery itself walks the tree (RFC 9989's label-by-label walk replaced the old public-suffix shortcut — Article #20's mechanics).

Why the ESPs insisted (the honest three reasons)

Delegation mechanics: the envelope/return-path must live somewhere the ESP can publish records under your authority — a subdomain you delegate by CNAME (SendGrid's em…, Article #31; SES's MAIL FROM, Article #32). DKIM-only variants (Mailchimp, Article #15) authenticate a subdomain's signature so DMARC passes on the DKIM leg.
Containment: a marketing blow-up (or a compromised ESP account) stains a subdomain's reputation and can be retired — you can't retire your root.
NOT volume dilution: the claim “Google recommends separate subdomains in its sender guidelines” is false as stated — our research full-text-searched Gmail's sender guidelines: zero occurrences of “subdomain.” Gmail counts volume at the primary domain (root + subdomain volumes sum; bulk status, once earned, is permanent). Google's separation advice lives in its App Engine bulk-mail documentation and says “different domains for each function.” Credit the right document or don't credit Google.

Three postures — choose one on purpose

Posture	Shape	Suits
Unified	One root record; sp/np blank (inherit p); no subdomain records	Most small businesses. Simple, consistent, reports all in one place. The accidental-fortress effect is a feature once senders are inventoried
Split	Key sending subdomains publish their OWN records (own policies, own rua)	Distinct business units/streams with separate owners. Cost: report fragmentation — assign each stream's reports an owner or they go unread
Fortress	Root `p=reject` + explicit `sp=reject` (+ `np=reject` for 9989 receivers)	After a complete subdomain sender inventory from aggregate reports. Publishing sp=reject BEFORE the inventory is how legitimate subdomain senders (your invoicing tool, your helpdesk) get rejected by your own policy — a failure mode common enough we name it in-house: the self-inflicted subdomain outage

The risk that reframes all of this

The specification's own security section (§11.8) works the attack: an attacker controlling evil.example.com sends as your domain and passes DMARC under relaxed alignment — because their subdomain mail authenticates. Translate to your DNS: every subdomain you ever delegated to a service you later abandoned (a dangling CNAME to a deprovisioned ESP — the pattern behind the research-named “SubdoMailing” cases) is a badge still active in a stranger's drawer. Your defences, in order:

Audit delegations: list every subdomain CNAME/NS delegation; for each, name the live service that owns it. No owner → remove it (the inventory discipline of Articles #13/#18, applied to delegations).
Read reports by subdomain: aggregate reports (Article #36) show sources claiming your subdomains — an unrecognized one is a finding, not noise.
Set np deliberately as you modernize: ghost subdomains get no benefit of your doubts at 9989-aware receivers.

Traps

Trap	Reality
“sp is a nice-to-have extra”	Blank sp = p applies. You've had an sp policy all along; this guide just introduced you.
Publishing a subdomain record “for reports only”	Its p comes with it — a p=none subdomain record under a p=reject root quietly re-opens that subdomain's failing mail AND moves its reports out of your sight.
Copying sp into every subdomain record	Ignored by specification. Harmless, but it reveals the copier never tested — test instead.
Trusting 7489-era tooling for np	Older receivers ignore np entirely (unknown tag). Your ghost protection is only as wide as receiver upgrades — set it, don't lean on it.

FAQ

Do I need separate DMARC records for my SendGrid/SES subdomains?

Usually no — those subdomains are envelope infrastructure; the From your customers see is the root, governed by the root record (Unified posture). Their own _dmarc records become relevant when you send as the subdomain (From on the subdomain) as a distinct stream.

We just discovered a subdomain sending we never approved.

That's the spoofing-triage workflow (Article #14) with the delegation audit above: check for a dangling CNAME first — an inherited badge explains “authenticated” abuse better than a breach does.

Should np be reject even while root is at quarantine?

Reasonable and common: ghosts have no legitimate mail to protect, so the ghost door can be strict before the front door is. (State it as your decision, made for that reason — the spec merely supplies the tag.)

Sources

RFC 9989 — §3.2.13 (np), §4.7 (sp semantics, fallback chain, existence test), §4.10.1, §11.8 (the worked subdomain attack) · RFC 7489 §6.3 (legacy sp; no np; PSL discovery) · Gmail Email Sender Guidelines + FAQ (volume counting at primary domain; full-text subdomain check) · Google Cloud App Engine bulk-mail guidelines (separate-by-purpose, different domains) · This site's Packs #13/#15/#31/#32 (dangling delegations, ESP subdomain mechanics).

Verification note: tag semantics and the fallback chain were confirmed from RFC 9989's text on 20 October 2026; receiver adoption rates for np are unmeasured anywhere we could verify, and Yahoo's position on separation has no first-party text — both absences are stated rather than papered over.

Did this guide work for you?

Your reaction tells us whether this guide solved the problem it promised to solve.