Subdomain DMARC: Why the sp= Tag Matters More Than You Think

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

That tag is sp=. It's the least-understood part of a DMARC record, and it's 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's 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's 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's 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 doesn't publish its own record. That includes the dozens of subdomains you've never sent mail from. By default, you're 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's 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 don't have a specific reason for subdomains to be softer than the parent, you don't 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 won't 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). Don't slam them to reject blind. Authenticate and align each subdomain sender first — SPF and DKIM aligned to the sending subdomain — then enforce. While you're 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:.

You're 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

Don't 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 don't recognize. A run of mail from news. or billing. from IPs you don't 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's actually sending under your name.

Frequently asked questions

Does DMARC cover subdomains automatically? Yes. If your organizational domain publishes a DMARC record and you haven't added an sp= tag, subdomains inherit the p= policy automatically — you don't need a record on every subdomain. A subdomain only escapes that policy if it publishes its own DMARC record, or if you set a more permissive sp= value such as sp=none.

What should the sp= tag be set to? If no subdomains send legitimate mail, set sp=reject to lock them down explicitly. If subdomains do send mail, authenticate and align those senders first, then enforce — you can hold sp=quarantine while you verify. Avoid sp=none on an enforcing record: it re-opens every subdomain to spoofing.

---

Subdomain policy is a five-minute fix that closes a gap most teams don't 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's the difference between a reject that looks complete and one that actually is.