DMARC Subdomain Policy (sp): Fixing Weak Subdomain Protection

How receivers find the policy for a subdomain

Understanding the lookup order is what makes the risk concrete. When a receiver evaluates a message with a From address at billing.example.com, it first queries _dmarc.billing.example.com. If a valid DMARC record exists there, that record governs, and both p and sp on the parent are irrelevant.

If no record exists at the subdomain, the receiver determines the organizational domain, using the Public Suffix List to work out where the registrable boundary is, and queries _dmarc.example.com. If that record carries an sp tag, the value of sp applies. If it does not, p applies.

Non-existent subdomains are also covered. This works for subdomains that do not exist in DNS at all. An attacker does not need a real subdomain, a hostname, or any records. Sending as accounts-payable.example.com triggers the same lookup path and lands on whatever sp says. Every possible name under your domain is covered by that one tag.

Why subdomains get targeted

Subdomain spoofing works well socially. An address at security-alerts.example.com or it-helpdesk.example.com looks plausible to a recipient who recognizes the parent domain, and in many clients the display is truncated in ways that make the distinction harder to notice. It also tends to survive longer than parent domain spoofing, because monitoring and reporting workflows are usually built around the main domain.

From an attacker's perspective, checking sp is trivial. The record is public, and a domain publishing p=reject; sp=none is advertising exactly where to aim.

Findings and their severity

sp=none under p=quarantine or p=reject (Warning)

The subdomain policy is set to none while the organizational domain enforces DMARC. Subdomains inherit no protection, so an attacker can send authenticated-looking mail from any subdomain even though the parent domain is locked down.

v=DMARC1; p=reject; sp=none

sp=quarantine under p=reject (Info)

The subdomain policy is one step weaker than the organizational policy. Subdomains are enforced at quarantine rather than reject, so failing mail from a subdomain lands in spam instead of being refused. The inbox is still protected.

v=DMARC1; p=reject; sp=quarantine

Legitimate reasons for a weaker sp

There is a real case for it, which is why this should be evaluated rather than flagged blindly. If a subdomain is delegated to a business unit or an acquired company that is not ready to enforce, a weaker sp keeps their mail flowing while the parent domain stays protected.

The problem is that sp is not selective. It applies to every subdomain at once, including all the ones nobody is using. You have loosened the policy across your entire namespace to accommodate one team.

How to fix it

If you have no specific reason for a different subdomain policy, remove the sp tag. Subdomains will inherit p, and there is one fewer value to drift out of alignment when the parent policy changes later. Alternatively, set sp to match p explicitly if you prefer the record to be self-documenting.

# Best: remove sp entirely  - subdomains inherit p
v=DMARC1; p=reject; rua=mailto:dmarc@example.com

# Explicit match
v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com

When one subdomain genuinely needs looser handling, publish a DMARC record on that subdomain instead. A record at _dmarc.marketing.example.com with p=none gives that team room to work while every other subdomain stays protected by the parent policy. This is the correct tool for the job, and it also gives you separate aggregate reports for that stream.

Coming in DMARCbis. DMARCbis introduces an np tag for non-existent subdomains, letting you apply a strict policy specifically to names with no DNS records while keeping a different policy for subdomains that are actually in use. Until that is widely supported, sp remains the control that covers the whole subdomain space.