How DMARC Applies to Subdomains (and the sp= Tag)

One record, a whole tree of domains

DMARC is published once, at _dmarc.acme.com. That single record governs the organizational domain and every subdomain under it, unless a subdomain publishes its own DMARC record. The policy that applies to a subdomain is decided in a specific order.

How the subdomain policy is chosen

When a receiver evaluates mail from news.acme.com, it resolves the policy like this:

1. Does _dmarc.news.acme.com exist? If the subdomain publishes its own DMARC record, that record wins outright.
2. Otherwise, look at the organizational domain's record. If _dmarc.acme.com sets an sp= tag, that value is used for the subdomain.
3. If there's no sp=, the subdomain inherits p=. The root policy applies to subdomains by default.

So sp= is the lever for treating subdomains differently from the root domain (stricter or looser) without publishing separate records for each one.

A worked example

v=DMARC1; p=quarantine; sp=reject; rua=mailto:dmarc@acme.com

• Mail from acme.com that fails DMARC is quarantined (the p= value).
• Mail from any subdomain (news.acme.com, totally-made-up.acme.com) that fails is rejected (the sp= value).

This is a common and sensible shape: a slightly forgiving policy on the domain you actively send from, and a hard sp=reject on subdomains, most of which you never send from at all.

Why unused subdomains are a target

Attackers know that teams focus DMARC on their main domain. If your root is at p=reject but you never set sp=, a subdomain still inherits reject, good. But the mistake to avoid is a weaker root or a missing policy that leaves subdomains open. Spoofers will happily send "invoices" from billing.acme.com if nothing stops them.

The defensive move for domains you never send mail from is a locked-down record (no authorized senders and a hard fail) so nothing can pass:

SPF:   v=spf1 -all
DMARC: v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@acme.com

Alignment and subdomains

One more subtlety: relaxed alignment (the default, adkim=r/aspf=r) treats a subdomain as aligned with its organizational domain. So mail from mail.acme.com with a From: of acme.com aligns fine under relaxed mode. Switch to strict (s) and the domains must match exactly, which often breaks legitimate subdomain senders. Unless you have a specific reason, keep alignment relaxed.

Put it into practice

Set your sp= when you build the record with the DMARC record generator, then confirm subdomain mail is behaving as expected by reading your aggregate reports in the DMARC report reader. The header_from in each row tells you which domain the mail claimed to be from. New to the tags? Start with DMARC policy modes, decode your aggregate telemetry with our DMARC report guide, and review core infrastructure setup in our SPF, DKIM & DMARC guide.