DMARC Subdomain Policy (sp= Tag): When and How to Use It

When you publish a DMARC record at your root domain, it doesn't just protect yourdomain.com — it also protects every subdomain you own, whether you use them or not. But what if your marketing team sends from news.yourdomain.com and isn't ready for strict enforcement, while your root domain is? That's where the sp= tag comes in.

The subdomain policy tag lets you apply different enforcement rules to subdomains than you use for your organizational domain. Used correctly, it's one of the most powerful tools in your DMARC toolkit. Used incorrectly, it's a loophole attackers can exploit.

What the sp= Tag Does

DMARC has two policy tags:

• p= — the policy applied to the organizational domain itself (the root domain)
• sp= — the policy applied to subdomains of that domain

If you omit sp=, subdomains automatically inherit the p= policy. That's usually what you want. But if you set sp= explicitly, it overrides the inheritance for every subdomain.

A typical record with a subdomain policy looks like this:

v=DMARC1; p=reject; sp=quarantine; rua=mailto:[email protected];

Here, the root domain uses reject, but any subdomain that fails DMARC is quarantined instead.

How Inheritance Actually Works

DMARC inheritance is simpler than people think — but there are gotchas.

The most important rule: if a subdomain publishes its own DMARC record, that record wins. The organizational domain's sp= tag is only consulted when the subdomain has no record of its own.

You can verify your configuration in seconds with our free DMARC record checker — it shows both the p= and sp= values and flags inheritance issues.

When You Should Use sp=

There are four situations where an explicit subdomain policy genuinely helps.

1. Protecting Unused Subdomains

If you only send from yourdomain.com and never use subdomains for email, set sp=reject regardless of your main policy. Attackers love to spoof accounts.yourdomain.com or billing.yourdomain.com because these names feel legitimate. A strict subdomain policy slams that door shut.

2. Rolling Out Enforcement Gradually

You want p=reject on your main domain, but a business unit sends from marketing.yourdomain.com and hasn't finished their authentication work. Set p=reject; sp=quarantine temporarily so the subdomain gets some protection without bouncing legitimate-but-misaligned mail.

3. Running a Transactional-Only Root Domain

Some organizations send all transactional email from the root and all bulk marketing from a subdomain. A common pattern is p=reject; sp=quarantine — the critical transactional traffic gets strict enforcement while marketing mail has a softer failure mode.

4. Staging and Test Environments

staging.yourdomain.com probably shouldn't send production email, but it sometimes does accidentally. An sp=reject at the root prevents those leaks from reaching inboxes.

When Not to Use sp=

Avoid the sp= tag if:

• You're still in monitoring mode (p=none). You gain no protection and introduce a second variable to troubleshoot.
• Your subdomains already publish their own DMARC records. The sp= tag is ignored in that case anyway.
• You don't actually know what your subdomains send. Generate a new DMARC record with the right defaults first and watch reports before making changes.

The Subdomain Spoofing Loophole

Here's the attack: you publish p=reject with no sp= tag, so subdomains inherit reject. Good. But an attacker registers yourdomain.com.evil.com — a completely different domain that only looks like a subdomain. DMARC doesn't help there.

A related but real problem: if you accidentally publish p=reject; sp=none, attackers can spoof any subdomain they invent — payroll.yourdomain.com, hr.yourdomain.com — and mailbox providers will accept it. Always double-check your sp= value after editing the record.

Troubleshooting Subdomain Policy Issues

If legitimate subdomain mail is failing when you didn't expect it to, work through this checklist:

1. Does the subdomain have its own DMARC record? If yes, your root domain's sp= isn't being used — fix the subdomain record directly.
2. Is SPF or DKIM aligned at the subdomain level? Relaxed alignment allows mail.yourdomain.com to align with yourdomain.com, but strict alignment requires an exact match.
3. Are aggregate reports showing the failing source? The DMARC reports guide walks through reading rua data to find the culprit.
4. Is your DNS cache stale? Changes can take up to the TTL to propagate.

For a broader walkthrough of fixing DMARC failures, see our troubleshooting guide.

Recommended Configuration

For most small businesses that don't send from subdomains, this is the safest starting point:

v=DMARC1; p=reject; sp=reject; adkim=r; aspf=r; rua=mailto:[email protected];

If you do send from subdomains but haven't finished authenticating them, use:

v=DMARC1; p=reject; sp=quarantine; rua=mailto:[email protected];

And once everything is aligned, tighten sp= to reject.

Keep an Eye on It

A subdomain policy is only as good as the monitoring behind it. New subdomains appear when teams spin up new services, and old ones get repurposed without anyone updating DNS. Continuous monitoring catches these drifts before they become incidents.