Subdomain policy is weaker than the domain policy
The sp tag sets a weaker policy for subdomains than the p tag sets for the organisational domain. Because attackers are free to invent subdomains that were never used for mail, a weaker subdomain policy leaves the easiest spoofing route open: a message from invoices.yourdomain.com can be sent under whatever the sp tag permits, regardless of how strict the parent policy is.
Check your own domainDMARC checker
What causes this
The sp tag sets the policy for subdomains. When it is weaker than p (for example p=reject with sp=none), every subdomain of your domain, including ones that do not exist, is left effectively unprotected. Attackers prefer subdomains precisely because they are so often overlooked, and a non-existent subdomain is just as usable for a forged From address as a real one.
What it breaks
Mail forged from subdomains is not subject to your main policy. This is a common gap in otherwise well-configured domains.
What the receiving server does
When a message arrives from a subdomain that publishes no DMARC record of its own, the receiver applies the organisational domain's policy, but it uses the sp value if one is present, and only falls back to p if it is not. So p=reject with sp=none instructs receivers to reject failing mail from the exact domain while accepting failing mail from every subdomain. Attackers do not need to guess a subdomain that exists, because DNS does not have to resolve for the From: header to display it.
How the two tags interact
The sp tag is only consulted for subdomains without their own DMARC record. If you do not publish sp at all, subdomains inherit p, which is usually what you want.
How to fix it
Raise sp to match p, or remove sp so subdomains inherit the domain policy.
- Confirm no legitimate subdomain sends mail that would fail the stricter policy.
- Either delete the sp tag (subdomains then inherit p) or set sp to the same value as p.
If you send with
- When a weaker sp is defensible
- During a rollout where a subdomain is used by a system you do not yet control (a legacy application server, or a third party sending from a delegated subdomain), sp can hold that subdomain at a weaker policy while the parent enforces. It is a staging position with a date attached, not a resting place.
- Subdomains that send legitimate mail
- If a subdomain has real sending needs that differ from the parent, give it its own DMARC record rather than weakening sp for every subdomain at once. A record at _dmarc.mail.example.com applies only to that name and leaves the rest protected.
Confirming the fix worked
- Remove the sp tag entirely if subdomains should inherit the parent policy, which is the common case.
- Where a subdomain genuinely needs different handling, publish a DMARC record on that subdomain instead of weakening sp.
- Confirm aggregate reports show no legitimate volume from subdomains you did not expect before tightening.
- Re-check after the change and confirm the parent policy is still the one you intend.
Common questions
- If I do not publish sp, what happens to subdomains?
- They inherit the p value. Omitting sp is the simplest way to have subdomains protected to the same standard as the organisational domain.
- Why would a weaker subdomain policy be a problem if the subdomain does not exist?
- Because nothing requires a subdomain to exist for it to appear in a From: header. An attacker can display invoices.yourdomain.com whether or not that name resolves, and the receiver will apply your sp policy to it.
- Does a subdomain's own DMARC record override sp?
- Yes. A DMARC record published at the subdomain takes precedence. The sp tag only applies to subdomains that have no record of their own.
- Does SPF work the same way for subdomains?
- No, and the difference catches people out. DMARC applies to subdomains by default; SPF does not inherit at all, so each subdomain that sends mail needs its own SPF record.