Subdomain DMARC: Why the sp= Tag Matters

You moved your main domain to p=reject. Spoofing of yourdomain.com stops cold. So you are done — except an attacker can still send as news.yourdomain.com, mail.yourdomain.com, or any subdomain you have never used, and depending on one tag in your record, those messages may sail straight into inboxes.

That tag is sp=. It is the least-understood part of a DMARC record, and it is where a confident-looking reject policy quietly springs a leak. The good news: the default behavior is on your side. The risk is in the overrides. If you want a refresher on what the policy values mean, our explainer on DMARC policy: none vs reject covers the basics this post builds on.

How DMARC treats subdomains by default

Here is the part that surprises people: subdomains inherit your organizational domain's policy automatically. You do not need a separate DMARC record on every subdomain.

When a receiver gets mail from news.yourdomain.com, it does this:

1. Look for a DMARC record at _dmarc.news.yourdomain.com. If one exists, use it.
2. If there is none, find the organizational domain (yourdomain.com, via the Public Suffix List) and read its record at _dmarc.yourdomain.com.
3. Apply that record's sp= policy to the subdomain — or, if there is no sp= tag, fall back to its p= policy.

So a plain v=DMARC1; p=reject; rua=... with no sp= tag already rejects spoofed mail from every subdomain that does not publish its own record. That includes the dozens of subdomains you have never sent mail from. By default, you are covered.

Which raises the obvious question: if the default is safe, how do real domains end up exposed?

The sp= tag, explained

sp= sets a different policy for subdomains than the one you use for the organizational domain. It exists for a legitimate reason: you might want p=reject on your primary domain while a batch of subdomains is still being brought into alignment, so you temporarily run them softer.

Three values, same as p=:

• sp=none — monitor only. Subdomains are not protected.
• sp=quarantine — failing subdomain mail goes to spam.
• sp=reject — failing subdomain mail is refused.

The trap is sp=none. A very common pattern looks like this:

v=DMARC1; p=reject; sp=none; rua=mailto:reports@yourdomain.com

That record says: "Reject spoofed mail for my main domain — but allow anyone to send as any subdomain." It is usually a rollout leftover. Someone set sp=none early to avoid breaking a subdomain sender, tightened p= to reject, and never came back to the subdomain policy. The dashboard shows a reassuring reject, and news.yourdomain.com is wide open.

Where the protection quietly breaks

Three failure modes account for almost every exposed subdomain:

• A permissive sp=. sp=none (or sp=quarantine under a p=reject parent) is a deliberate hole. If you do not have a specific reason for subdomains to be softer than the parent, you do not want this.
• A subdomain with its own record. Remember step 1 of the lookup: a DMARC record on the subdomain takes precedence and the parent's sp= never applies. A marketing platform or legacy app that published _dmarc.mail.yourdomain.com with p=none years ago silently bypasses your enforcement — and it will not show up unless you go looking.
• DMARC only on a subdomain, not the organizational domain. If you published your record at _dmarc.app.yourdomain.com but never at _dmarc.yourdomain.com, the organizational domain and every other subdomain have no policy at all. Always anchor DMARC at the organizational domain first.

Why do attackers bother with subdomains? Because a lookalike like mail-yourdomain.com is obviously fake, but mail.yourdomain.com is a real part of your namespace. Recipients trust it, and an unused subdomain has no legitimate traffic to muddy the spoof. Dormant subdomains are low-effort, high-credibility targets — which is exactly why leaving them open matters.

Recommended settings by scenario

No subdomains send legitimate mail. Lock them down explicitly:

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

Strictly, p=reject with no sp= already does this by inheritance — but stating sp=reject removes ambiguity and protects you if someone loosens p= later. Belt and suspenders.

Some subdomains send mail (helpdesk, marketing, app notifications). Do not slam them to reject blind. Authenticate and align each subdomain sender first — SPF and DKIM aligned to the sending subdomain — then enforce. While you are verifying, you can hold subdomains softer:

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

Then tighten sp= to reject once the reports show every legitimate subdomain source is aligned. Alignment is the thing that actually makes or breaks this — our guide to DMARC alignment walks through how SPF and DKIM have to line up with the visible From:.

Still mid-rollout on the main domain. Get the organizational domain to enforcement using the staged, evidence-driven path in the DMARC rollout playbook, then treat subdomains as their own short rollout.

How to confirm coverage in your reports

Do not guess — verify. Your aggregate (rua) reports list the sources sending under your domain and its subdomains, with the policy that was applied. Two things to look for:

• Subdomain sources you do not recognize. A run of mail from news. or billing. from IPs you do not operate is exactly the spoofing your sp= is meant to stop. Confirm those are failing under an enforcing policy.
• Subdomains being evaluated under a weaker policy than you expect. If a subdomain shows none while your parent is reject, either an sp= override or a subdomain-level record is in play. Track it down.

Reading that out of raw aggregate XML by hand is miserable, which is the whole reason most subdomain gaps go unnoticed for months. Check your domain's current DMARC record to see how your p= and sp= resolve, and what is actually sending under your name.

Subdomain policy is a five-minute fix that closes a gap most teams do not know they have. Confirm your organizational domain enforces, decide whether any subdomains legitimately send, and set sp= to match — then let your reports prove it. That is the difference between a reject that looks complete and one that actually is.