How does the DMARC sp tag affect subdomain policies?
Updated on 22 Oct 2026: We clarified subdomain overrides, record validation, and reporting checks for DMARC policy changes.
The DMARC sp tag sets the requested 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.
What the sp tag controls
Under RFC 9989, a receiver checks the exact visible From domain (RFC5322.From), called the Author Domain, first. If that domain has a valid DMARC record, its p value supplies the requested policy. If the exact subdomain has no valid record, the receiver uses the DNS Tree Walk to find the applicable Organizational Domain or Public Suffix Domain (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.
How p and sp differ
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, policy discovery 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.
DMARC subdomain policy lookup: exact record first, then the Organizational Domain's sp or p fallback.
|
|
|
|---|---|---|
Valid exact record | Author Domain p | Own policy |
Existing subdomain, no exact record, sp present | Organizational Domain sp | Subdomain policy |
Existing subdomain, no exact record, no sp tag | Organizational Domain p | Inherited p |
Invalid p, sp, or np with a valid rua URI | RFC 9989 fallback | Treat as p=none |
Invalid p, sp, or np without a valid rua URI | No usable record | No DMARC processing |
Multiple DMARC records at one lookup name | Discard those records | Continue policy discovery where applicable |
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 meets the visible From domain's alignment requirements. The p or sp value states the requested handling when DMARC fails. A none policy expresses no handling preference.
The duplicate-record and invalid-policy rules differ. RFC 9989 defines policy discovery and the fallback rules.
For the broader setup context, see how DMARC records for subdomains inherit or override the parent policy.
Examples of p and sp inheritance
The Organizational Domain requests rejection for its own DMARC failures but monitoring for existing subdomains without an exact 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 Suped's DMARC checker. Publish one DMARC TXT record per lookup name and keep v=DMARC1 first. Check separators and policy values; syntax errors do not all trigger the same fallback.
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. In a DNS zone editor that appends example.com, the parent record's Host field is usually _dmarc; an exact override for mail.example.com is usually _dmarc.mail. Confirm the resulting full DNS name.
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. That boundary also affects relaxed SPF and DKIM alignment. Use it only when the delegated team needs an independent DMARC 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
Typical policy choices; quarantine is optional before reject.
Inventory
sp=none
Collect sources and fix obvious failures.
Quarantine
sp=quarantine
Request suspicious handling for failing mail after regular senders pass.
Reject
sp=reject
Request rejection of failing mail after legitimate exceptions are handled.
Subdomain exception
own record
An exact subdomain record can apply at any rollout stage.
A useful setup is p=none with sp=reject when the root domain still needs monitoring and every legitimate existing subdomain sender is known and passes DMARC. 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 requires an inventory of legitimate subdomain senders and verification that their mail passes DMARC. 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
Subdomain overrides do not inherit individual tags
An exact subdomain DMARC record replaces the inherited record. Receivers do not merge its optional tags with the parent's settings.
Suppose the parent has aspf=s and adkim=s. The subdomain override above omits both, so it uses their relaxed defaults (r). Include those tags on the override to retain strict alignment, as specified in RFC 9989.
Relaxed alignment requires the SPF-authenticated domain or DKIM signing domain to share the visible From domain's Organizational Domain. Strict alignment requires an exact domain match. The sp tag changes neither mode.
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. Reporting is receiver-dependent, so missing traffic is not proof that a sender does not exist.
What to check before tightening sp
- Compare aggregate reports with sending logs and the subdomain inventory; reports do not cover every receiver.
- Verify legitimate senders pass DMARC across normal sending cycles, including infrequent mail and forwarded messages.
- 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. Non-existent means a DNS NXDOMAIN response, not merely a missing MX record. An existing subdomain that never sends mail still uses sp or its p fallback.
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, Suped's record generator helps avoid simple tag mistakes. Review the 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. For receivers implementing t=y, a requested reject policy becomes quarantine, and quarantine becomes none. Omit t or use t=n for normal enforcement.
Views from the trenches
Best practices
Set sp only after you know which subdomains send mail and which sources pass DMARC.
Keep rua on explicit subdomain records to retain reporting requests after policy overrides.
Use sp=none for discovery, then stage quarantine or reject after failures are fixed.
Review existing and non-existent subdomain traffic separately when choosing policy values.
Common pitfalls
Treating sp=none as no DMARC causes teams to overlook useful subdomain reporting 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 DMARC 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 view
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 view
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
Check the result after changing sp
Query the published parent record and any exact subdomain overrides after saving a change. Allow for DNS cache TTLs, then check receiver results and legitimate senders' bounce logs.
Aggregate reports can contain results under both old and new policies during propagation, as described in RFC 9990. Compare the reported policy and message counts with the intended change before tightening enforcement again.
Frequently asked questions
No. DMARC still evaluates subdomain mail. The effective requested policy is none for existing subdomains without their own record. A valid rua destination requests aggregate reports from participating receivers; it does not guarantee complete coverage.
Existing subdomains without their own DMARC record inherit the applicable p policy. If the Organizational Domain has p=reject, those subdomains inherit reject.
Yes. A valid DMARC record at the exact Author Domain supplies that subdomain's p policy. Include rua if aggregate reports are required. Optional tags are not inherited individually; omitted aspf and adkim use their relaxed defaults.
Publish sp on the applicable Organizational Domain DMARC record. On an exact subdomain override, use p for that subdomain. An sp value on an ordinary subdomain record does not govern deeper descendants under RFC 9989.
Use sp=reject only after every legitimate existing subdomain sender is known and passes DMARC. Otherwise, participating receivers can reject legitimate mail under their local policies.
No. sp sets the requested DMARC handling for subdomain failures. SPF or DKIM still needs to pass and meet the visible From domain's alignment requirements. The sp tag does not publish SPF records or DKIM keys.
