DMARC subdomain policy best practices: sp, dedicated records, and inheritance gotchas

DMARC gets talked about like a single switch you flip for a domain.

In reality, most domains are a small ecosystem:

• the apex (example.com) where people type addresses and expect mail to "just work"
• a handful of subdomains used for actual sending (news.example.com, billing.example.com, support.example.com)
• and a larger number of subdomains that exist because of DNS history, vendor setup wizards, or "we might use this later" ideas.

This is where DMARC subdomain strategy matters.

Not because DMARC is complicated, but because the inheritance rules are easy to misunderstand, and the blast radius of a misunderstanding is... not fun.

If DMARC fundamentals are still a bit fuzzy, start with What is DMARC?. If the "SPF passes but DMARC fails" situation sounds familiar, DMARC alignment: From vs Return-Path (strict vs relaxed) explains why that happens.

The one rule that clears up 80% of confusion

DMARC policy is looked up based on the domain in the visible From: header.

• From: billing@example.com -> receivers look for _dmarc.example.com
• From: billing@news.example.com -> receivers look for _dmarc.news.example.com

If there is no DMARC record for the subdomain, receivers fall back to the organizational domain's DMARC record.

That fallback is where the sp= tag comes in.

What sp= actually does (and what it doesn't)

sp is "subdomain policy". It only applies to subdomains that do not publish their own DMARC record.

That second sentence is the gotcha.

• A subdomain with its own _dmarc.sub.example.com record does not inherit sp.
• A subdomain without its own record does inherit from the organizational domain, and sp (if present) overrides p for that subdomain.

So think of sp as a default policy for "everything under here, unless a subdomain opts out by publishing its own DMARC record".

If sp is omitted, subdomains inherit p.

For a refresher on the tag itself (and the other usual tags), DMARC record tag cookbook is the practical companion.

Two common strategies (both valid, depending on the domain)

There are lots of variations, but in production these tend to be the two stable "shapes".

Strategy A: "No subdomain should ever send" (lock it down)

This is for domains that only send from the apex (or not at all), and where subdomains are basically technical leftovers.

The goal: make spoofing harder across all subdomains by default.

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@yourdomain.tld"

This works well when:

• there truly are no legitimate senders using From: on subdomains
• the organization has a habit of vendors spinning up "temporary" subdomains (and forgetting about them)

Strategy B: "The apex is strict, subdomains are a work zone" (contain the blast radius)

This is for domains that want strong protection on example.com, but also have subdomains used for marketing platforms, SaaS tools, or transactional systems.

The goal: protect the main brand domain while giving subdomains room to be cleaned up deliberately.

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@yourdomain.tld"

Then, for each subdomain that actually sends, publish an explicit DMARC record on that subdomain:

_dmarc.news.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.tld"

Why this pattern is popular:

• the apex can move to p=reject sooner (usually the most valuable protection)
• each mail stream gets an explicit policy and can be audited independently
• if a vendor setup is messy, it tends to break that subdomain's mail rather than the main domain's

If a staged rollout is in progress, DMARC setup stages matches how teams typically get from "reports everywhere" to "reject with confidence".

Dedicated subdomains: the practical reasons to do it

Some teams avoid subdomains because it feels like more DNS.

But dedicated subdomains are often what makes DMARC operationally manageable, especially once there's more than one sender.

Here are the three reasons that keep showing up:

1) Vendor isolation

If a marketing platform misbehaves or gets misconfigured, it's much better for that to affect news.example.com than example.com.

2) Cleaner alignment

Many providers can DKIM-sign with a domain you control, but the details vary. Having a dedicated From: subdomain gives freedom to align DKIM and SPF without contorting the apex.

If this is the part that keeps biting, revisit DMARC alignment: From vs Return-Path (strict vs relaxed). Subdomain strategy and alignment strategy are basically the same conversation.

3) Reputation boundaries

Mailbox providers don't publish a neat "reputation per subdomain" chart, but separating streams still tends to help in practice: marketing volume behaves differently than low-volume transactional mail.

It's not magic. It's just making it easier to reason about what's being sent, from where, and why.

Inheritance gotchas that cause real incidents

These are the ones that tend to surprise people because they're not syntax errors. Everything "looks" correct until mail starts landing in spam or bouncing.

Gotcha 1: sp is not a shield for a subdomain with its own DMARC record

If _dmarc.news.example.com exists, sp on _dmarc.example.com is irrelevant for mail that claims From: ...@news.example.com.

That's usually good -- it's how subdomains opt into their own policy -- but it also means a forgotten subdomain DMARC record can keep enforcing an old policy long after the main domain was updated.

Gotcha 2: "We don't send from subdomains" (until someone does)

This one happens quietly.

A SaaS tool gets configured to send password resets "from your domain", and the easiest-looking option is support@help.example.com because it feels "separate".

If the org's DMARC record uses sp=reject, that new mail stream will fail hard unless it's properly authenticated and aligned.

That's not DMARC being annoying. That's DMARC doing exactly what it was asked to do.

Practical fix: either authenticate/alignment for that subdomain properly (preferred), or explicitly publish a DMARC record for the subdomain with the intended rollout policy while it's being brought into compliance.

Gotcha 3: Organizational domain isn't always "what looks right"

DMARC uses the organizational domain concept (based on the public suffix list), which mostly behaves like intuition... until it doesn't.

example.co.uk is the classic case: the organizational domain is example.co.uk, not co.uk.

This matters when:

• deciding where DMARC "lives" for a brand
• interpreting reports for subdomains that look unrelated but roll up to the same organizational domain

If DMARC reports show policy lookups that seem strange, this is a good thing to sanity-check.

Gotcha 4: Setting sp=none and assuming subdomains are "safe"

sp=none is not "permit mail". It's "don't ask receivers to quarantine/reject failing mail".

If a subdomain is used for real sending, sp=none should be treated as temporary -- a holding pattern while the subdomain gets its own record and its own aligned authentication.

A small checklist that works in practice

When deciding what to do with subdomains, keep it simple:

1) List every domain that appears in From: across the organization. Don't guess; use reports. 2) For each From: domain, decide whether it is allowed to send. 3) For allowed senders, ensure at least one aligned mechanism (DKIM or SPF) is reliable for that stream. 4) Publish DMARC records so the policy matches reality: strict on identities that matter, explicit policies on real sending subdomains, and sp used intentionally rather than as decoration.

If DMARC records start to grow lots of tags, it's usually a sign that strategy is unclear. The "boring" records in DMARC record tag cookbook are a good reset.

Where to go next

If the goal is "lock down the brand domain without accidentally breaking a vendor stream", the most useful next read is A (sane) DMARC setup process for busy domains.