DMARC for subdomains: how sp= and policy inheritance work

Many businesses send email from more than one name: example.com for staff, news.example.com for a newsletter, billing.example.com for invoices. DMARC has a clear rule for which policy applies to each, and one tag, sp=, that controls most of it.

How a receiver finds the policy

For a message from news.example.com, a receiver following RFC 7489:

1. Looks for a DMARC record at _dmarc.news.example.com. If one exists, it uses that record's p=.
2. If not, it looks at the organisational domain, _dmarc.example.com, and applies its sp= policy, or its p= if there is no sp=.

The organisational domain is the registrable domain, worked out from the public suffix list. Receivers do not walk up every level in between.

What sp= is for

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

Here the main domain is at reject, and subdomains without their own record get quarantine. Common reasons to set sp= differently from p=:

• The main domain is enforced but a subdomain's senders are still being fixed, so subdomains stay gentler for a while.
• The opposite: the main domain is still at none while you work through senders, but no subdomain sends email, so sp=reject protects them now.

When a subdomain needs its own record

Give a subdomain its own DMARC record when it needs a different policy or different reporting addresses. A subdomain's own record replaces the inherited one entirely, so include a rua tag if you still want reports.

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

Protect subdomains that never send email

Attackers like subdomains because they look legitimate: secure.example.com, billing.example.com. If the organisational domain's effective subdomain policy is reject, receivers apply it to every subdomain without its own record, including ones that do not exist in DNS. That is the simplest protection there is. For extra safety on names you do use for websites only, publish v=spf1 -all at those hostnames.

Common mistakes

• Assuming p=reject covers subdomains when sp=none is set. It does not. Check the whole record with the DMARC explainer.
• A subdomain record with no rua, so its traffic disappears from reports.
• Forgetting that a subdomain's SPF and DKIM must align with the subdomain (relaxed alignment allows example.com DKIM to align with news.example.com mail, but strict alignment does not).

How Hookgap reports subdomains

When you check a subdomain, Hookgap looks for its own DMARC record first, then falls back to the organisational domain's sp= policy, and says on the report that the policy is inherited. Email checks run on the subdomain only if it has its own mail servers; website and SSL checks always run on the exact host. More on how a check works.