Your Subdomains Aren't Protected: The DMARC sp= Tag

The Record Nobody Publishes Until It's Too Late

Your organisation has a DMARC record on example.com. Policy is at p=reject. Reports are flowing. Job done.

Then someone starts spoofing invoices.example.com. Or hr.example.com. Or no-reply.example.com — a subdomain that has never existed, has no DNS records of any kind, and has never sent an email.

Whether that spoofed mail gets through depends entirely on a tag most people never set: sp.

How Subdomain Policy Inheritance Works

DMARC uses a specific lookup procedure. When a receiver evaluates a message from invoices.example.com, it:

1. Queries _dmarc.invoices.example.com for a DMARC record.
2. If found, uses that record's p= policy.
3. If not found, queries _dmarc.example.com — the organisational domain.
4. If a record is found there, applies its sp= value, not its p= value.
5. If sp= isn't specified, sp defaults to whatever p= is.

That default in step 5 is why most organisations are accidentally protected. If your record is v=DMARC1; p=reject; rua=..., subdomains inherit reject.

But the moment you set sp= explicitly — often during a rollout, to avoid breaking subdomain mail — you've created a gap that's easy to forget about.

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

This record says: reject spoofed mail from the root domain, and do nothing about spoofed mail from any subdomain. An attacker reads it in seconds and knows exactly where to aim.

The organisational domain concept

DMARC determines the "organisational domain" using the Public Suffix List — the same list browsers use to decide cookie scope.

For invoices.emea.example.com, the organisational domain is example.com, because .com is the public suffix. The lookup goes to the exact subdomain first, then jumps straight to the organisational domain. It does not walk up one label at a time. There's no intermediate check of _dmarc.emea.example.com unless that's the exact From domain.

This matters for organisations under multi-label suffixes like .co.uk or .com.au, where the organisational domain is the third-level name rather than the second.

Publishing Subdomain Policies Deliberately

There are three sensible patterns.

Pattern 1: Inherit everything

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

No sp= tag. Subdomains inherit reject. Simplest and strongest, appropriate once you're confident every subdomain that sends mail is properly authenticated.

Pattern 2: Explicit subdomain enforcement

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

Functionally identical to pattern 1, but states the intent. Worth doing purely so that anyone auditing the record later doesn't wonder whether the omission was deliberate.

Pattern 3: Root at reject, subdomains still in rollout

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

A legitimate transitional state. Quarantine rather than none — it still provides meaningful protection while you sort out subdomain senders.

sp=none should be genuinely temporary. If it's been in place for a year, it isn't a rollout, it's a permanent gap.

Per-subdomain overrides

A subdomain can publish its own DMARC record, which takes precedence entirely:

_dmarc.marketing.example.com
v=DMARC1; p=quarantine; rua=mailto:[email protected]

Useful when one subdomain uses a platform you're still authenticating, or when a business unit wants its own reports routed elsewhere. The parent record's sp= is ignored for that subdomain.

The Non-Sending Subdomain Problem

Here's the part that's frequently overlooked. Most organisations have far more subdomains than they realise — CDN endpoints, staging environments, vendor-provided hostnames, legacy names from projects long finished.

None of them send email. All of them can be spoofed if the policy allows it.

The cleanest approach is a strong sp=reject on the organisational domain, which covers every subdomain including ones nobody remembers. For specific high-risk non-sending subdomains you can also publish explicit records:

_dmarc.staging.example.com
v=DMARC1; p=reject; rua=mailto:[email protected]

Paired with an SPF record that authorises nothing:

staging.example.com
v=spf1 -all

And a null MX to signal the domain doesn't receive mail either:

staging.example.com. IN MX 0 .

That combination — -all SPF, p=reject DMARC, null MX — is the standard hardening set for a domain that has no business in email at all. There's no rollout risk because there's no legitimate mail to break.

Checking What's Actually Published

The DMARC Lookup tool queries the record and parses the tags:

1. Enter your domain.
2. Read the published record and the parsed policy tags.
3. Then repeat for your subdomains. This is the step people skip.

Check each subdomain that sends mail, each subdomain that used to send mail, and a couple that never have. What you're looking for:

• Does the subdomain have its own record, or is it inheriting?
• If inheriting, what does the parent's sp= say?
• Is there an sp=none sitting in a record where nobody noticed it?

If the parent has no sp= tag at all, subdomains inherit p= — which is usually what you want, but verify it rather than assuming.

Reading Reports for Subdomain Activity

DMARC aggregate reports are scoped to the record that requested them, so a rua= on the organisational domain receives data covering subdomains that fall back to it.

The report's <identifiers><header_from> field tells you which domain each set of messages claimed to be from. Grouping your reports by that field is how you discover:

• Subdomains sending legitimate mail you didn't know about
• Subdomains being spoofed
• Subdomains that were decommissioned but are still generating traffic

A subdomain appearing in reports with high volume and consistent authentication failure is either a forgotten legitimate sender or an active spoofing campaign. Either way you want to know.

Note that a subdomain publishing its own rua= pointing elsewhere means that traffic won't appear in your organisational reports. Centralising report addresses is usually the better choice for visibility.

Common Mistakes

Setting sp=none during rollout and never revisiting it. Set a calendar reminder when you publish it.

Assuming subdomains are covered because the root is at reject. True only if sp= is unset or set to an enforcing value.

Forgetting the external reporting authorisation record. If you send rua= to a domain you don't control, that domain must publish an authorisation record at example.com._report._dmarc.thirdparty.net. Without it, compliant reporters won't send you data.

Publishing DMARC without SPF and DKIM in place. DMARC evaluates alignment of those two mechanisms. A policy with nothing to align against just fails everything.

Ignoring adkim and aspf alignment modes. Setting these to strict without auditing subdomain-signing platforms breaks legitimate mail.

Treating the Public Suffix List as intuition. For domains under multi-label suffixes, verify what the organisational domain actually resolves to rather than guessing.

FAQ

What happens if I don't set sp=? Subdomains inherit the p= policy. For most organisations that's the desired behaviour.

Does DMARC check every level of a subdomain? No. It checks the exact From domain, then jumps directly to the organisational domain determined by the Public Suffix List. Intermediate levels aren't queried.

Should non-sending subdomains have their own DMARC records? A strong sp=reject on the parent covers them. Explicit records add clarity for high-risk names and let you route reports separately.

Can a subdomain have a weaker policy than the parent? Yes — a subdomain's own record takes precedence entirely, in either direction. That's worth knowing when auditing, since it means a strong parent policy doesn't guarantee subdomain protection.

Where do subdomain reports go? To the rua= address on whichever record applied. If the subdomain inherited from the parent, reports go to the parent's address.

The Takeaway

DMARC's subdomain inheritance is well designed and quietly easy to undermine with a single tag. Check whether sp= is set anywhere in your records, verify what each of your subdomains actually resolves to, and harden the ones that don't send mail with the full -all plus p=reject plus null MX combination.

Check your DMARC records free with the DMARC Lookup at sadiqbd.com — no sign-up, instant results.