If I set p=reject, do I still need the sp tag?

Not strictly, if you omit sp, subdomains inherit the p value, so p=reject already enforces reject on subdomains. You add sp only when subdomains should behave differently from the root, such as sp=none while you inventory subdomain senders before enforcing.

What is the difference between sp and np?

sp sets policy for all subdomains that fall under the organizational domain's DMARC record. np sets policy specifically for non-existent subdomains, ones with no DNS records, which are common phishing targets. np=reject is low-risk because those subdomains send no legitimate mail.

Does a subdomain's own DMARC record override the sp tag?

Yes. If a subdomain publishes its own _dmarc record, that record governs it entirely and the organizational domain's sp tag no longer applies to it. Use a dedicated record only for subdomains with genuinely different sending needs.

DMARC Subdomain Policy (sp Tag): Protecting Your Subdomains

VigilDog Team · October 19, 2026 · 6 min read

You published a DMARC record on your root domain, set it to p=reject, and felt protected. But attackers rarely spoof your bare domain, they spoof marketing.yourdomain.com or a subdomain that has never existed. Your DMARC subdomain policy, controlled by the sp tag, is what decides whether those subdomains are covered or wide open. Getting it right closes a gap most teams do not know they have.

How DMARC applies to subdomains

DMARC is published as a TXT record at _dmarc.yourdomain.com on your organizational domain. When a receiver evaluates a message from mail.yourdomain.com, it does not require a DMARC record on the subdomain itself. Instead it walks up to the organizational domain's policy and applies it, unless the subdomain publishes its own record.

That policy check works alongside SPF and DKIM: DMARC passes when the message authenticates with SPF or DKIM and that authenticated domain aligns with the domain in the visible From address. The diagram below shows how the pieces fit together, and the sp tag is what tells the receiver how strictly to treat subdomains during that walk.

How SPF, DKIM and DMARC verify an email

The sp tag and its default behavior

The p tag sets policy for the organizational domain. The sp tag sets policy specifically for its subdomains. Both take the same values: none (monitor only), quarantine (send to spam), or reject (block outright).

The critical detail: if you omit sp, subdomains inherit the p value. So a record of v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com already enforces reject on every subdomain, you do not need sp to get coverage, you need it to differ. You add sp when subdomains should be treated differently from the root, in either direction.

Two common shapes: strict root, lenient subdomains, v=DMARC1; p=reject; sp=none; ... enforces the apex but only monitors subdomains while you inventory what sends from them. Or lenient root, strict subdomains, v=DMARC1; p=none; sp=reject; ... when your apex still has unresolved senders but you are confident no legitimate mail comes from any subdomain. Both are deliberate; the mistake is setting sp by accident and never checking what it does.

sp=none, subdomains monitored only, no enforcement (use while inventorying)
sp=quarantine, spoofed subdomain mail goes to spam
sp=reject, spoofed subdomain mail is blocked
sp omitted, subdomains inherit the p value automatically

The np tag: locking down subdomains that do not exist

There is a third policy tag many teams miss: np, the non-existent subdomain policy. It applies specifically to subdomains that have no DNS records at all, the exact targets attackers love, because a subdomain like invoices.yourdomain.com that you never created has no mail infrastructure to break.

np lets you apply your harshest policy, np=reject, to those phantom subdomains without affecting real ones. A strong, layered record looks like v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:reports@yourdomain.com. Because a non-existent subdomain by definition sends no legitimate mail, np=reject carries essentially no deliverability risk and shuts a favorite phishing vector. Support for np is not universal across every receiver, so treat it as a valuable extra layer on top of sp, not a replacement for it.

When a subdomain has its own DMARC record

Inheritance and sp only apply when the subdomain has no DMARC record of its own. The moment you publish _dmarc.marketing.yourdomain.com, that record governs marketing.yourdomain.com completely, the organizational domain's sp no longer touches it.

This is the right tool when a subdomain has genuinely different needs. Your bulk email platform sends from email.yourdomain.com with its own SPF and DKIM setup; give it a dedicated _dmarc.email.yourdomain.com record with its own reporting address and its own rollout pace, while the apex stays at reject. The trade-off is that every dedicated record is one more thing to maintain, publish them deliberately, for subdomains that actually send, not as a default habit.

A practical rollout for subdomains

Treat subdomains with the same discipline as the apex: monitor before you enforce. Start with sp=none (or the inherited p=none) and read the aggregate reports to learn which subdomains send mail and whether that mail authenticates. Only tighten once the data is clean.

The sequence: publish DMARC at the organizational domain with rua reporting; watch reports until you can account for every sending subdomain; move sp to quarantine and confirm no legitimate subdomain mail is caught; then move sp to reject and add np=reject to seal off phantom subdomains. Validate the record's syntax at each step with our DMARC checker, and if SPF or DKIM alignment is what is failing underneath, our guide to fixing SPF, DKIM, and DMARC covers the authentication layer that DMARC depends on. For the apex enforcement path specifically, our p=reject rollout guide walks the same monitor-then-enforce discipline in detail.

Keep reading the reports after you enforce

DMARC is not set-and-forget. New subdomains spin up, a marketing tool changes its sending infrastructure, an sp policy quietly stops matching reality, and aggregate reports are the only place these show up before a deliverability problem does. The teams that stay protected are the ones still reading reports months later.

VigilDog monitoring tracks your SPF, DKIM, and DMARC records, including subdomain policy, across every domain you manage, and flags drift the moment a record changes, so your sp and np settings keep protecting the subdomains you forgot you had.