The DMARC sp tag sets the policy for subdomains that do not publish their own DMARC record. If the parent domain has sp=none, DMARC still applies to those subdomains, but the effective enforcement policy is none. That means receivers still evaluate DMARC, still use the parent record's reporting destinations, and still check the usual SPF or DKIM domain match, but they are not being asked by DMARC to quarantine or reject failing subdomain mail.
So the short answer is: sp=none does not mean no DMARC policy exists for subdomains. It means the inherited parent record supplies a subdomain policy of none, unless the subdomain publishes its own record. I treat this as a monitoring mode for subdomains, not as an absence of DMARC.
The direct answer
A receiver checks DMARC against the exact Header From domain first. If that exact domain has a DMARC record, that record wins. If the exact subdomain has no DMARC record, the receiver looks up the organizational domain and applies that parent record. For subdomain mail, the receiver uses sp as the effective policy when sp is present. If sp is absent, the receiver falls back to the parent p policy.
- With sp=none: Subdomains without their own DMARC record inherit the parent record, with effective policy none.
- With sp=quarantine: Subdomains without their own record inherit a quarantine request for DMARC failures.
- With sp=reject: Subdomains without their own record inherit a reject request for DMARC failures.
- With no sp tag: Subdomains without their own record inherit the parent p policy.
- With a subdomain record: The subdomain's own DMARC record controls that subdomain and overrides parent inheritance.
The clean mental model
Think of p as the parent domain policy and sp as the fallback policy for child domains. The fallback only matters when the child domain has no DMARC record of its own.
This is also why sp is not mandatory. The parent p policy already has a defined behavior for subdomains when sp is missing. A separate sp mandatory discussion is useful when you are deciding whether to include it at all.
How receivers choose the policy
For a message using user@news.example.com in the visible From header, the receiver starts at _dmarc.news.example.com. If it finds a valid DMARC record there, the search stops. If it does not find one, the receiver checks the organizational domain, usually _dmarc.example.com. At that point, sp decides the requested policy for that subdomain.
Flowchart showing exact DMARC lookup first, then parent DMARC with sp or p fallback.
|
|
|
|---|---|---|
Sub record | Subdomain | Own policy |
No sub record | Parent sp | Sub policy |
No sp tag | Parent p | Inherited p |
Syntax error | Invalid record | Fix DNS |
Effective DMARC policy selection for subdomain mail.
The policy decision is separate from the authentication result. DMARC passes only when SPF or DKIM passes with the right visible-domain relationship. The p or sp policy tells the receiver what the domain owner requests when DMARC fails. A none policy requests monitoring, not enforcement.
If you want the broader setup context, the explanation of whether subdomains by default receive a parent policy is the adjacent concept.
Practical examples
This example answers the most common confusion. The parent domain is strict for itself, but relaxed for subdomains that lack their own DMARC record.
Parent domain DMARC recorddns
Host: _dmarc.example.com Type: TXT Value: v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@example.com
- Mail from example.com: The effective policy is reject because the parent domain uses p=reject.
- Mail from a.example.com: If no subdomain record exists, the effective policy is none because the parent has sp=none.
- Mail from b.example.com: If _dmarc.b publishes its own record, that record controls b.example.com.
Now compare that with a parent record that omits sp. In that case, the subdomain fallback becomes the parent p value.
Parent record without spdns
Host: _dmarc.example.com Type: TXT Value: v=DMARC1; p=reject; rua=mailto:dmarc@example.com
With this record, a.example.com inherits reject if it has no DMARC record. That is the behavior people often miss. Setting sp=none is not the same as omitting sp when the parent p value is stricter than none.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
After editing a parent record, I check the final TXT value with a DMARC checker before assuming the receiver will parse it the way I intended. Syntax errors are not theoretical. One misplaced semicolon or duplicate tag can change the whole result.
When to use sp=none, quarantine, or reject
The right sp value depends on how much subdomain mail you have inventoried. I do not set a strict subdomain policy just because the root domain is ready. Subdomains often carry forgotten senders, internal systems, regional tools, old campaigns, and one-off vendor setups.
Use sp=none when
- Discovery: You are still finding legitimate subdomain senders.
- Reporting: You need aggregate data before applying enforcement.
- Change risk: A missed sender has a real business impact.
- Delegation: Teams outside IT control some sending subdomains.
Use sp=reject when
- Inventory: You know which subdomains send mail.
- Authentication: Each sender passes DMARC consistently.
- Abuse pattern: Attackers are forging many random subdomains.
- Ownership: DNS and sender changes are centrally reviewed.
Subdomain policy rollout stages
A practical sequence for moving subdomains away from monitoring.
Inventory
sp=none
Collect sources and fix obvious failures.
Partial enforcement
sp=quarantine
Use quarantine only after regular senders pass.
Full enforcement
sp=reject
Reject failing subdomain mail after exceptions are handled.
Special case
own record
Publish a subdomain record when it needs different handling.
A common and sensible setup is p=none with sp=reject when the root domain still needs monitoring but you are confident that no unapproved subdomains should send mail. This is useful when abusive traffic is spread across random subdomains, because the volume can hide inside reports if nobody groups it properly.
Do not use sp as a sender inventory substitute
A strict sp value works only after you know what sends from your subdomains. If a legitimate sender fails DMARC, sp=reject tells participating receivers to reject it.
Subdomain records override inheritance
A subdomain can publish its own DMARC record when it needs a different policy, different reports, or a staged rollout that does not match the parent domain. Once the subdomain record exists and is valid, the parent sp value no longer controls that subdomain.
Subdomain overridedns
Host: _dmarc.mail.example.com Type: TXT Value: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
The reporting destination matters. If you publish a DMARC record on mail.example.com and forget rua, your normal reports for that subdomain can disappear. That is one of the easiest mistakes to miss during a cleanup project.
This is where Hosted DMARC in Suped is practical. You can stage parent and subdomain policy changes from one place, then keep the DNS side cleaner. For larger setups, Suped also brings DMARC, SPF, DKIM, blocklist (blacklist), and deliverability signals into one workflow, with alerts when failures or unknown sources appear.
Hosted DMARC configuration dialog showing policy controls, CNAME setup, and expanded advanced options
For most teams, Suped is the strongest practical DMARC platform because the hard part is not typing sp=reject. The hard part is knowing when that change will break mail, spotting unknown senders, and giving the person who owns the sender a specific fix. Suped's issue detection, real-time alerts, hosted SPF, SPF flattening, hosted MTA-STS, and MSP dashboard are built around that work.
If you need a deeper explanation of precedence, the guide on how subdomain records override root policy covers that edge in more detail.
Reporting and monitoring details
The sp tag affects the requested handling of failed DMARC. It does not turn reports off. If the parent record has a valid rua tag and the subdomain has no DMARC record of its own, aggregate reports for subdomain traffic are sent according to the parent record.
What I check before tightening sp
- Coverage: Every active subdomain sender appears in DMARC reports.
- Pass rate: Important senders pass DMARC for normal production mail.
- Reporting: Each explicit subdomain record includes the right report address.
- Rollback: DNS owners know the record that restores the previous policy.
Non-existent subdomains are a related but separate issue. Some organizations publish np to express a policy for domains that do not exist, but older DMARC implementations ignore unknown tags. I do not rely on np as the only control. I still monitor reports, lock down unused subdomains where DNS allows it, and use sp=reject when real subdomain senders are known.
For ongoing operations, DMARC monitoring is what turns this from a DNS guess into a controlled rollout. Suped shows which sources send from each domain, what fails, and which policy change is safe to stage next.
DMARC record generator
Choose your policy, reporting addresses, and alignment settings.
DNS TXT record
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
When building a new record, a record generator helps avoid simple tag mistakes. I still review the generated value against the intended policy: root domain policy, subdomain fallback, report address, and any strict domain-match settings.
Views from the trenches
Best practices
Set sp only after you know which subdomains send mail and which sources pass DMARC.
Keep rua on every explicit subdomain record so reporting stays complete after overrides.
Use sp=none for discovery, then stage quarantine or reject after failures are fixed.
Review random subdomain traffic separately because abuse can be spread thinly there.
Common pitfalls
Treating sp=none as no DMARC causes teams to miss useful subdomain failure data.
Publishing a subdomain record without rua can remove that traffic from reports entirely.
Assuming omitted sp means none is wrong when the parent p policy is already stricter.
Using sp=reject before sender inventory can block legitimate delegated systems later.
Expert tips
Model p and sp separately so root enforcement does not hide subdomain exposure risks.
Check exact subdomain records first, then read the parent record for fallback policy.
Use monitoring to group failures by subdomain before moving to enforcement policy.
Treat np as extra context, not the main control for real sending subdomains today.
Marketer from Email Geeks says sp=none makes the effective subdomain policy none when the subdomain has no record of its own.
2024-09-10 - Email Geeks
Marketer from Email Geeks says p=none with sp=reject can help when abuse is spread across many random subdomains.
2024-09-10 - Email Geeks
My practical recommendation
Use sp when you want subdomains to follow a different enforcement policy than the parent domain. If the parent is already at p=reject but you are still mapping subdomain mail, set sp=none and watch the reports. If the parent is only monitoring but you know random subdomains should never send, consider sp=reject after checking real sender data.
The safe rule is simple: publish explicit records only where a subdomain needs its own policy, and include reporting on those records. For everything else, let the parent record control the fallback. If you use Suped, the same workflow can track the policy, alert on failures, surface unknown sources, and stage hosted changes without turning every policy adjustment into a manual DNS project.
