How does the DMARC sp tag affect subdomain policies?
Updated on 14 Aug 2026: We updated this guide for RFC 9989 policy discovery and safer subdomain enforcement.
The DMARC sp tag sets the policy for existing subdomains that do not publish their own DMARC record. If the parent Organizational Domain has sp=none, DMARC still applies to those subdomains, but the effective requested policy is none. Receivers still evaluate DMARC, use any valid reporting destinations in the applicable record, and check the usual SPF or DKIM alignment, but DMARC does not ask them 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 record supplies a subdomain policy of none, unless the subdomain publishes its own record. A none value expresses no handling preference. Add a valid rua destination when the goal is aggregate monitoring.
The direct answer
Under RFC 9989, a receiver checks the exact Header From domain, called the Author Domain, first. If that domain has a valid DMARC record, its p value controls the message. If the exact subdomain has no valid record, the receiver uses the DNS Tree Walk to find the applicable Organizational Domain or PSD DMARC Policy Record. For an existing subdomain, the receiver uses sp when present. If sp is absent, the receiver falls back to the applicable p policy.
- With sp=none: Existing subdomains without their own DMARC record inherit an effective policy of none.
- With sp=quarantine: Existing subdomains without their own record inherit a quarantine request for DMARC failures.
- With sp=reject: Existing subdomains without their own record inherit a reject request for DMARC failures.
- With no sp tag: Existing subdomains without their own record inherit the applicable p policy.
- With an exact subdomain record: The subdomain's own p policy overrides inheritance for that Author Domain.
The clean mental model
Think of p as the policy for the domain that publishes the applicable record and sp as the Organizational Domain's fallback for existing subdomains. The fallback matters only when the exact Author Domain has no valid DMARC record.
These values publish the Domain Owner's handling preference. The receiving system still makes the final delivery decision under its local policy, so quarantine or reject does not guarantee identical treatment at every receiver.
The sp tag is optional because p already supplies a defined subdomain fallback when sp is absent. Include sp only when existing subdomains need a different policy.
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 and the record's p value applies. If it does not find one, RFC 9989 policy discovery uses the DNS Tree Walk to find the applicable Organizational Domain or PSD policy record, often _dmarc.example.com for a simple example.com domain. At that point, sp decides the requested policy for an existing subdomain. The np tag applies only when the Author Domain is a non-existent subdomain.
Flowchart showing exact DMARC lookup first, then parent DMARC with sp or p fallback.
|
|
|
|---|---|---|
Valid exact record | Author Domain p | Own policy |
No exact record | Organizational Domain sp | Subdomain policy |
No sp tag | Organizational Domain p | Inherited p |
Invalid p, sp, or np with valid rua | RFC 9989 fallback | Treat as p=none |
Invalid p, sp, or np without valid rua | No usable record | No DMARC processing |
Effective DMARC policy selection for subdomain mail.
The policy decision is separate from the authentication result. DMARC passes only when SPF or DKIM passes and its authenticated domain aligns with the visible From domain. The p or sp value states the requested handling when DMARC fails. A none policy expresses no handling preference.
For the broader setup context, see how DMARC records for subdomains inherit or override the parent policy.
Practical examples
This example answers the most common confusion. The Organizational Domain is strict for itself but relaxed for existing 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 Organizational Domain uses p=reject.
- Mail from a.example.com: If no exact subdomain record exists, the effective policy is none because the applicable record has sp=none.
- Mail from b.example.com: If _dmarc.b.example.com publishes its own valid record, that record's p value controls b.example.com.
Now compare that with an Organizational Domain record that omits sp. In that case, the existing-subdomain fallback becomes the 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 exact DMARC record. Setting sp=none is not the same as omitting sp when p is stricter than none.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
After editing a parent record, validate the final TXT value with the DMARC checker. A missing separator, duplicate tag, or invalid policy value can move the record to RFC 9989's invalid-record fallback instead of the intended enforcement policy.
Where to publish the sp tag
Publish sp in the DMARC record for the applicable Organizational Domain, such as _dmarc.example.com. When a specific subdomain publishes an exact override at _dmarc.mail.example.com, its p value controls mail whose Author Domain is mail.example.com.
Do not treat sp as a wildcard at every level
Under RFC 9989, sp on an ordinary subdomain record is ignored for deeper descendants. Do not assume an sp value at _dmarc.mail.example.com governs child.mail.example.com. Policy discovery still looks for the exact Author Domain and then the applicable Organizational Domain or PSD record.
RFC 9989 allows a delegated DNS subtree to establish its own Organizational Domain boundary with psd=n. Use that advanced configuration only when the delegated team needs its own policy and reporting boundary. Otherwise, keep sp on the main Organizational Domain record and publish exact subdomain records only where their p policy or report destinations must differ.
When to use sp=none, quarantine, or reject
The right sp value depends on how much subdomain mail has been inventoried. 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 existing subdomains send mail.
- Authentication: Each sender passes DMARC consistently.
- Abuse pattern: Unauthorized mail uses existing subdomains.
- Ownership: DNS and sender changes are centrally reviewed.
Subdomain policy rollout stages
A practical sequence for moving existing 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 an exact record when a subdomain needs different handling.
A useful setup is p=none with sp=reject when the root domain still needs monitoring but every legitimate existing subdomain sender is known. Under RFC 9989, add np=reject when non-existent subdomains need an explicit reject policy. If np is absent, sp remains the fallback for non-existent subdomains.
Do not use sp as a sender inventory substitute
A strict sp value is safe only after every legitimate subdomain sender is known. If one fails DMARC, sp=reject asks participating receivers to reject it, subject to each receiver's local policy.
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 Organizational Domain. Once the exact subdomain record is valid, the inherited sp value no longer controls mail using that subdomain as the Author Domain.
Subdomain overridedns
Host: _dmarc.mail.example.com Type: TXT Value: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
The reporting destination matters. If a DMARC record is published on mail.example.com without rua, receivers do not use the Organizational Domain's rua value for that exact record. Aggregate reports for the subdomain can stop.
Suped's Hosted DMARC supports this workflow by staging parent and subdomain policy changes in one place while keeping the published DNS record stable. Teams can review affected senders before changing enforcement and keep the correct report destinations on explicit overrides.
Hosted DMARC configuration dialog showing policy controls, CNAME setup, and expanded advanced options
Suped can also alert on new failures and unknown sources after a policy change. Its hosted SPF, SPF flattening, hosted MTA-STS, and MSP dashboard keep related authentication work in the same operational workflow without changing how sp itself is evaluated.
Reporting and monitoring details
The sp tag affects the requested handling of failed DMARC. It does not turn reports off. If the applicable Organizational Domain record has a syntactically valid rua tag and the subdomain has no exact record, aggregate reports for subdomain traffic are requested through that inherited record. An external report destination must also pass the authorization checks defined for DMARC reporting.
What to 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 case. RFC 9989 defines np as the policy for non-existent subdomains. If np is absent, the receiver uses sp when present, otherwise p. Do not rely on np as the only control. Monitor reports, secure unused DNS names where practical, and use sp=reject after real subdomain senders are known.
For ongoing operations, Suped's DMARC monitoring groups traffic by domain and source, shows alignment failures, and provides the evidence needed to stage the next policy change.
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, the record generator helps avoid simple tag mistakes. Review the generated value against the intended root policy, subdomain fallback, report address, and alignment modes. Under RFC 9989, np, psd, and t are active tags. The older pct, rf, and ri tags are historic and should not be used as current rollout or reporting controls.
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 existing and non-existent subdomain traffic as separate policy decisions.
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 Organizational Domain fallback.
Use monitoring to group failures by subdomain before moving to enforcement policy.
Use np for non-existent domains, not as the main control for real sending subdomains.
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
Practical recommendation
Use sp when existing subdomains need a different enforcement policy than the Organizational Domain. If the root is already at p=reject but subdomain mail is still being mapped, set sp=none and review aggregate reports. If the root is only monitoring but every legitimate existing subdomain sender is known, use sp=reject after verifying real sender data.
Publish exact records only where a subdomain needs its own policy or reporting destination, and include rua on those records when aggregate reporting is required. For everything else, let the Organizational Domain record supply the fallback. Suped can track the policy, alert on failures, surface unknown sources, and stage hosted changes without turning every adjustment into a manual DNS project.
