DMARC for Subdomains: What Every Admin Should Know

Introduction

Subdomain DMARC behavior is governed by the sp= tag — or by inheritance if sp= isn't set. Either way, every subdomain has a DMARC posture, declared or implicit. This article covers what admins need to know.

Why this topic matters

The most common DMARC mistake involving subdomains: an admin moves the parent to p=reject and inadvertently breaks mail from a subdomain whose senders weren't included in the audit. Knowing how subdomain policy works prevents the surprise.

How subdomain policy works

Two layers:

1. The sp= tag in the parent domain's DMARC record sets the subdomain policy.
2. A separate DMARC record at _dmarc.subdomain.parent.com overrides sp= for that specific subdomain.

If neither is set, the subdomain inherits p= from the parent.

Three patterns that work

Pattern 1: Uniform enforcement

Set p=reject; sp=reject. All subdomains inherit reject. Simplest; works when you control all senders.

Pattern 2: Different policy per subdomain

Publish a separate DMARC record at each subdomain that needs different behavior. Allows fine-grained control.

Pattern 3: Parent at none, subdomain at reject

Used during rollouts when you want to enforce on a low-stakes subdomain first. Set p=none; sp=reject plus a specific subdomain record.

Step-by-step approach

1. Inventory subdomains with active senders.
2. Default to uniform policy (sp=reject matching p=reject).
3. Set per-subdomain DMARC only where needed.
4. Audit each subdomain's authentication. SPF and DKIM separately.
5. Move the subdomain policies up together to avoid surprises.

Best practices

• Always set sp= explicitly. Don't rely on inheritance defaults.
• Watch for shadow subdomains. careers.brand.com, events.brand.com, others added without IT knowledge.
• Use subdomains for sender isolation. A problematic sender can be moved to its own subdomain with separate authentication.
• Document subdomain DMARC architecture. Future engineers need the map.
• Pair with SPF on each subdomain for full coverage.

Recommended next step

Audit your published sp= tag and any per-subdomain DMARC records. Inconsistencies are where the surprises live.

FAQ

What if I don't set sp=?

The subdomain inherits p= from the parent.

Can subdomains have stricter policy than parent?

Yes — publish a stricter per-subdomain DMARC record.

What about deep subdomain nesting?

DMARC is checked at the immediate domain. a.b.c.brand.com looks for _dmarc.a.b.c.brand.com first, then falls back to organizational domain rules.

Does the org-domain lookup use Public Suffix List?

Yes. DMARC uses the PSL to determine the organizational domain for inheritance.

Should I use subdomains for marketing vs. transactional?

Often yes — separates the risk profiles and lets you tune policy independently.

Final thoughts

Subdomain DMARC is the layer where many surprises live. Setting sp= explicitly and managing per-subdomain records deliberately eliminates the inheritance ambiguity.

Treat each subdomain as a separate DMARC posture decision.