DMARC for Subdomains: The sp= Tag, Inheritance Rules, and Common Mistakes

The DMARC sp= tag sets the policy for subdomains of the domain where the record is published. If mail.example.com has no DMARC record of its own, receivers fall back to _dmarc.example.com and apply sp= if present — or p= if it isn't. Subdomains do not automatically get the same policy as the parent unless you understand and configure this fallback.

This is the tag most DMARC configs get wrong. Teams publish p=reject on the organizational domain, declare victory, and never notice that mail.example.com, shop.example.com, and support.example.com are either unprotected or protected in ways they didn't intend. Worse, shadow subdomains — set up by a departed agency, a forgotten ESP, or an attacker registering nothing but exploiting your own DNS — send unauthenticated mail that DMARC never governs the way you assumed. This post covers how policy discovery actually works, when a subdomain needs its own record, and the mistakes that quietly leave gaps.

The organizational domain concept

Everything in DMARC policy discovery hinges on the organizational domain: the registrable domain you bought from a registrar — the public suffix plus one label. For example.com, the organizational domain is example.com. For mail.example.co.uk, it's example.co.uk (the public suffix is co.uk, so the org domain includes one more label). Receivers determine this using the Public Suffix List, a maintained registry of suffixes like com, co.uk, and github.io.

Why it matters: DMARC records are looked up at exactly two places — the full domain in the From header, and if nothing is found there, the organizational domain. Nothing in between. If your From domain is a.b.example.com and there's no _dmarc.a.b.example.com, the receiver jumps straight to _dmarc.example.com. It does not walk the tree through b.example.com.

How does DMARC policy discovery actually work?

The lookup algorithm from RFC 7489, in plain terms:

1. Take the domain from the RFC 5322 From header — say news.example.com.
2. Query _dmarc.news.example.com. Found a valid v=DMARC1 record? Use it. Done.
3. Otherwise, if the domain is the organizational domain, stop — no policy applies.
4. Otherwise, query _dmarc.example.com (the organizational domain). If found, apply that record — using its sp= value for the subdomain, or p= if no sp= is present.

The decision table:

Two subtle points that trip people up:

• A subdomain's own record uses `p=`, not `sp=`. If _dmarc.mail.example.com says v=DMARC1; p=reject, that p= governs mail.example.com itself. The sp= tag in that record would only matter for its subdomains (x.mail.example.com).
• The fallback record's `sp=` is read, not its `p=` alone. This is the whole point of the tag. p=reject; sp=none means: strict on the org domain, monitoring-only on every subdomain that lacks its own record.

p= vs sp=: the semantics in one place

p= is the requested policy for the domain where the record lives. sp= is the requested policy for all subdomains that don't publish their own record. If sp= is absent, subdomains inherit p=. Valid values for both: none (monitor only), quarantine (treat as suspicious, typically spam folder), reject (refuse delivery).

So this record:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; sp=quarantine; rua=mailto:[email protected]; pct=100"

means: reject unauthenticated mail from example.com itself; send unauthenticated mail from any record-less subdomain to spam. And this one:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"

means reject everywhere, org domain and every subdomain without its own record. Silence (sp= omitted) is inheritance — which is exactly what most people intend, and occasionally not what they get, because they forget subdomains exist at all.

When does a subdomain need its own _dmarc record?

Publish a dedicated _dmarc.<sub> record when any of these is true:

1. The subdomain uses different sending infrastructure with different risk. If mail.example.com runs through a marketing ESP with a messy history of forwarding and list imports, while the org domain is locked-down corporate Google Workspace, you may want p=quarantine on the subdomain while the org domain sits at p=reject. One record can't express that — the fallback applies one sp= to all subdomains uniformly.

2. You're rolling out enforcement progressively. The standard path from none to reject often runs per-stream: enforce on the transactional subdomain first (cleanest authentication), hold marketing at a lower policy while you fix alignment, enforce org domain last (or first, if it's quiet). Per-subdomain records give you that granularity without touching the org record.

3. A subdomain shouldn't send mail at all. vpn.example.com, intranet.example.com, dev.example.com — infrastructure hostnames that never legitimately appear in a From header. Give them an explicit deny record:

_dmarc.vpn.example.com. 3600 IN TXT "v=DMARC1; p=reject;"

Now any spoofed mail from those names fails hard, regardless of what your org-level sp= says. This is cheap, high-value anti-phishing work.

4. You want separate reporting. A dedicated record can carry its own rua= address, so aggregate reports for mail.example.com go to the marketing ops mailbox instead of the security team. Report volume per subdomain gets noisy fast; separation keeps both audiences reading.

If none of these apply, skip the extra record and let inheritance do its job. Fewer records, fewer places to drift.

One boundary case worth deciding explicitly: parked or vanity subdomains that exist only as website hostnames. If promo.example.com hosts landing pages but never sends mail, it doesn't need its own record — but it does need to be covered by your org-level policy, which means your sp= posture is doing real protective work even for domains with zero mail infrastructure. Spoofers love plausible-looking subdomains precisely because recipients trust anything under a known brand.

Auditing shadow sending subdomains with rua reports

Here's the uncomfortable exercise every domain owner should run quarterly: read your DMARC aggregate reports and list every subdomain that appears as a header_from or in the source records. Compare against the list of subdomains you think send mail. If you're not fluent in the XML yet, our guide to reading DMARC aggregate reports covers the fields that matter.

What you'll typically find:

• Legitimate streams you forgot. The ticketing system on support.example.com, the webinar platform on events.example.com. Add them to your inventory, fix their SPF/DKIM alignment, move on.
• Misconfigured streams. Subdomains sending with no DKIM and SPF that doesn't align — passing today only because policy is none, doomed the day you enforce. These are your pre-enforcement work list.
• Spoofing. Volume from IPs you've never seen, failing everything. That's not your mail — but it is your brand, and it's exactly what enforcement policies exist to kill.

Then make the strategic call about sp=. If your audit shows subdomains are mostly spoof targets rather than senders, a strict sp=reject (or even the default inheritance of p=reject) is the right end state. If you run many legitimate sending subdomains, you'll want a deliberate email subdomain strategy — separating transactional, marketing, and corporate mail onto distinct subdomains, each with its own authentication and policy posture — before you tighten sp= at all.

The BIMI interaction nobody mentions

BIMI (Brand Indicators for Message Identification) — the logo in the inbox — requires DMARC enforcement. Gmail and Yahoo require the From domain's DMARC policy to be at p=quarantine or p=reject before they'll display a BIMI logo.

The subdomain catch: if mail goes out From mail.example.com, the policy that matters is the one applying to mail.example.com — which, absent its own record, comes from sp= at the org level. So a config like p=reject; sp=none on the org domain means your org-domain mail qualifies for BIMI and your subdomain mail does not, even with a perfect VMC (Verified Mark Certificate) and a valid BIMI record. We've seen teams debug "why won't my logo show" for weeks before discovering their sp= was effectively none. If you're setting up BIMI on a sending subdomain, audit the effective policy for that exact domain first — the full checklist is in our BIMI logo setup guide.

Common mistakes, ranked by how often we see them

1. Assuming `p=reject` covers subdomains "automatically." It does — but only via inheritance, only for subdomains without their own record, and only as strictly as your sp= (or its absence) dictates. "Automatic" hides the mechanics until a subdomain record someone added in 2022 quietly overrides everything.
2. Forgetting an old subdomain record exists. A p=none record left on _dmarc.mail.example.com during testing is a permanent hole at that subdomain. Audit _dmarc.* across your zone, not just the org record.
3. Setting `sp=reject` while legitimate subdomains fail authentication. Instant self-inflicted delivery failure on streams you didn't know existed. Audit rua data before enforcing; that sequencing is the whole point of the none→quarantine→reject rollout.
4. Expecting tree-walk discovery. There is none. a.b.example.com falls back to example.com, skipping b.example.com entirely.
5. Ignoring subdomains in monitoring. Authentication records drift — ESPs change CNAME targets, SPF includes rot. WillItInbox's DMARC monitoring tracks SPF/DKIM/DMARC drift with alerts, and the DMARC checker will show you the effective record for any domain or subdomain you test. Run every sending subdomain through the DMARC check tool quarterly; it takes minutes and catches the silent holes.

Worked example: a real-world zone

; Organizational domain — strict, subdomains at quarantine by default
_dmarc.example.com.       3600 IN TXT "v=DMARC1; p=reject; sp=quarantine; rua=mailto:[email protected]; fo=1"

; Marketing subdomain — its own record while alignment gets fixed
_dmarc.mail.example.com.  3600 IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

; Non-sending infrastructure — explicit deny
_dmarc.vpn.example.com.   3600 IN TXT "v=DMARC1; p=reject;"

Effective policies: example.com → reject. mail.example.com → none (own record wins). vpn.example.com → reject (own record). shop.example.com → quarantine (inherits via sp=). Four domains, three mechanisms, one config. That's the model to aim for: deliberate at every layer, inherited by default.

Verifying effective policy: a five-minute audit

Inheritance logic is simple on paper and surprisingly easy to misjudge in a real zone. Verify, don't assume. The audit:

# What's published at the org domain?
dig TXT _dmarc.example.com +short

# Does any subdomain override exist?
dig TXT _dmarc.mail.example.com +short
dig TXT _dmarc.vpn.example.com +short

For every sending subdomain you know about, ask two questions: does a _dmarc.<sub> record exist, and if not, what does the org record's sp= (or absent sp=, the p=) yield for it? Then hunt for the records you don't know about — a zone transfer or a pass over your DNS provider's record list for anything matching _dmarc.* often surfaces leftovers from old tests and departed vendors. Each stray record is a policy you didn't choose, applied to mail you didn't audit.

Do this quarterly and after any DNS migration. Zone moves are where subdomain records silently die or resurrect, and DMARC doesn't alert you when its own discovery inputs change — that's a monitoring problem, not a protocol feature.