Does DMARC Protect Subdomains Automatically? The sp= Tag Explained

No — subdomains do not get their own DMARC protection by default. If your DMARC record has no sp= tag, every subdomain of your domain falls back to the same policy as your root domain's p= tag. If you do set sp=, it overrides that inheritance and applies to all subdomains instead — but the two tags work independently, and mixing them up is one of the most common DMARC misconfigurations.

What sp= actually controls

A DMARC record has two separate policy tags:

• p= — the policy for mail claiming to be from your exact domain (yourdomain.com)
• sp= — the policy for mail claiming to be from any subdomain (mail.yourdomain.com, news.yourdomain.com, anything.yourdomain.com)

Both accept the same three values: none (monitor only), quarantine (send to spam), or reject (block outright).

v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@yourdomain.com

This example says: fully enforce on the root domain, but go easier on subdomains while they're still being brought into alignment.

If you omit sp=, here's exactly what happens

Leave sp= out entirely and DMARC falls back to this rule: subdomains inherit p=.

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com

With no sp= tag, this record enforces p=reject on every subdomain too — including subdomains that don't exist yet. That's actually the safer default for most senders, and it's why a lot of DMARC guides tell you not to bother with sp= unless you have a specific reason to diverge.

When you actually need a separate subdomain policy

The common real-world case: your root domain (yourdomain.com) doesn't send mail directly — it's just your website and brand — so you can push it straight to p=reject with no risk. But a subdomain like mail.yourdomain.com or news.yourdomain.com is handling live marketing or transactional sends through a third-party platform, and SPF/DKIM alignment on that subdomain isn't fully verified yet.

v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@yourdomain.com

This locks the root domain down completely — nobody can spoof yourdomain.com directly — while giving the actively-sending subdomain a softer quarantine policy until you've confirmed every sending source passes DKIM or SPF with alignment.

Once the subdomain's authentication is clean (check your DMARC aggregate reports for a stretch with zero legitimate failures), tighten sp= to reject and match the root policy.

The security gap sp=none opens

Setting sp=none — or omitting sp= on a record where p=none is still set — leaves every subdomain of your domain, registered or not, open to spoofing with no DMARC enforcement at all. This is the attack DMARC subdomain policy exists to close: an attacker registers secure-login.yourdomain.com or simply spoofs a From address using a subdomain that was never set up for mail, and because that subdomain inherits sp=none, mailbox providers apply no DMARC check to it.

This is also why financial institutions and anyone doing brand-protection DMARC work almost always run p=reject; sp=reject — total subdomain lockdown, with each legitimate sending subdomain's own SPF/DKIM records carrying the actual authentication weight (DMARC itself doesn't need separate records per subdomain to enforce this; one root-domain DMARC record with sp= covers them all).

Quick reference

Publish the DMARC record once, at the root domain only — _dmarc.yourdomain.com, not _dmarc.mail.yourdomain.com. Subdomain-specific DMARC records are rarely needed and most providers ignore them in favor of the organizational domain's record and its sp= tag.

Check your grade free

Don't guess what's broken — see it. Scan your domain free at emailsecuritygrade.com and get an instant A-F grade on your SPF, DKIM, DMARC, and MX records, with a plain-language fix for anything failing. No signup, no install — it runs in your browser.

If your emails are still landing in spam after fixing the records, a deliverability tool like InboxAlly can train mailbox providers to trust your sending — worth a look once your grade is solid.