DMARC Subdomain Policy (sp=)

DMARC's p= tag controls policy for the apex domain. The sp= tag controls policy for subdomains. If you publish p=reject for yourdomain.tld but leave sp= unset, behavior on subdomains like support.yourdomain.tld depends on the receiver: many fall back to inheriting p=, but a small number do not. RedScore passes only when subdomain policy is reject or quarantine, either explicitly via sp= or inherited from a strong p=.

This check only runs when your domain has a non-null MX. If you have only a null MX or no MX, it shows as not applicable rather than failing.

How the verdict maps to evidence

• Pass: DMARC record has sp=reject or sp=quarantine.
• Pass: sp= is unset but p=reject or p=quarantine. Subdomains inherit the apex policy.
• Warn: sp=none. Subdomains have an explicit weak policy.
• Warn: sp= unset and p= is none, missing, or weak. Subdomains inherit weak policy.
• Fail: no DMARC record at _dmarc.yourdomain.tld.

Fail: no DMARC record

If you have no DMARC at all, fix that first. The DMARC Policy Enforcement guide walks through publishing a record in monitoring mode and graduating to enforcement; this subdomain check passes naturally once you complete that rollout at p=reject or p=quarantine.

Warn: sp=none or inherited weak policy

Two paths to pass, depending on whether your subdomains send mail.

Path A: no subdomains send mail (most common)

Set sp=reject (or sp=quarantine) explicitly on your apex DMARC record. This locks down every subdomain that does not have its own DMARC, blocking attackers who spoof addresses like support@notifications.yourdomain.tld.

_dmarc.yourdomain.tld.   IN  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@yourdomain.tld; adkim=s; aspf=s"

If your apex policy is currently p=quarantine and you are not yet ready for p=reject, you can still set sp=reject as long as no subdomain legitimately sends mail. Subdomains can be locked down ahead of the apex.

Path B: subdomains send mail

If a subdomain like notifications.yourdomain.tld or mail.yourdomain.tld sends legitimate mail, lock down the apex first, then publish a DMARC record for each sending subdomain individually. Each subdomain DMARC record is independent of the apex and lets you tune SPF, DKIM, and DMARC per use case.

_dmarc.yourdomain.tld.   IN  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@yourdomain.tld; adkim=s; aspf=s"

_dmarc.notifications.yourdomain.tld.   IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.tld; adkim=s; aspf=s"

The subdomain's own DMARC overrides whatever the apex sp= says, so each sending subdomain can run its own phased rollout (p=none → quarantine → reject) without affecting the rest. Each sending subdomain also needs its own SPF and DKIM aligned to that subdomain.

Verify the fix

• Run dig +short TXT _dmarc.yourdomain.tld @1.1.1.1 and confirm sp= is reject or quarantine, or that p= is at reject/quarantine and sp= is intentionally unset.
• If you publish per-subdomain DMARC, run dig +short TXT _dmarc.<subdomain>.yourdomain.tld for each one and verify each policy is what you intended.
• After two to four weeks of aggregate reports arriving, confirm that subdomain spoofing attempts in the reports show disposition=reject or disposition=quarantine. If they show disposition=none, the policy is not being applied as expected.
• Re-run the RedScore lookup.

Common pitfalls

• Setting sp=none deliberately for "flexibility." It does not give flexibility; it just exposes every subdomain to spoofing. Use Path B (per-subdomain DMARC) for legitimate sending subdomains instead.
• Forgetting that sp= only applies to subdomains without their own DMARC record. If notifications.yourdomain.tld publishes its own _dmarc record, that record wins regardless of the apex sp= value.
• Setting sp= weaker than p= without a reason. Receivers may treat this as a misconfiguration. If you genuinely want subdomains weaker than the apex (rare), document why.
• Per-subdomain DMARC at the wrong host. _dmarc.notifications.yourdomain.tld is correct, not _dmarc.yourdomain.tld for the notifications subdomain. The leading _dmarc label always sits in front of the policy target.
• Apex p=reject without sp= explicit. Most receivers do inherit p= for subdomains, but a small number do not. Set sp= explicitly to remove the ambiguity.