How does the DMARC sp tag affect subdomain policies?
Michael Ko
Co-founder & CEO, Suped
Published 27 Jul 2025
Updated 17 Aug 2025
8 min read
Understanding how DMARC works is crucial for maintaining email security and deliverability. At its core, DMARC (Domain-based Message Authentication, Reporting, and Conformance) helps domain owners protect their brand from email spoofing and phishing attacks by giving email receivers instructions on how to handle emails that fail authentication checks.
A common point of confusion arises when dealing with organizational domains and their subdomains. While a DMARC record on the main domain (often called the organizational domain) can cover its subdomains by default, the sp tag is specifically designed to manage policies for subdomains.
The question often comes up: if a parent domain’s DMARC record includes sp=none, does that mean no DMARC policy applies to subdomains, or does it apply a p=none policy to them? Let's dive into the specifics of the sp tag and clarify how it affects DMARC policy application for subdomains.
The sp tag, short for subdomain policy, is an optional yet powerful element within your DMARC record. Its primary function is to allow domain owners to define a distinct DMARC policy for their subdomains, separate from the policy applied to the organizational (parent) domain via the p tag. This provides granular control over how email receivers should handle messages originating from subdomains that fail DMARC authentication.
Similar to the main p tag, the sp tag can take three values: none, quarantine, or reject. Setting sp=none instructs receiving servers to take no action on emails from subdomains that fail DMARC, but still collect DMARC reports. sp=quarantine tells receivers to move such emails to the spam or junk folder, while sp=reject directs them to block or discard the emails entirely. This flexibility is key for managing varied sending behaviors across your domain ecosystem.
Here's an example of a DMARC record that includes the sp tag, which sets a policy for subdomains different from the primary domain policy. You can learn more about all the available DMARC tags and their meanings.
By default, if you publish a DMARC record for your organizational domain, its p tag policy will apply to all subdomains unless explicitly overridden. This means if you have p=reject on your main domain example.com, then mail.example.com will also inherit a p=reject policy. This is the simplest form of policy application.
The sp tag, when present in the organizational domain's DMARC record, allows you to specify a different policy for all subdomains that do not publish their own DMARC record. For example, if example.com has p=reject; sp=none, any subdomain like news.example.com without its own DMARC record will effectively apply p=none. This clarifies the common confusion: sp=none means the subdomain will adopt a p=none policy, not that it will be entirely exempt from DMARC checks. For more details on this, you can review the DMARC policies for organizational domains and subdomains explained.
An important caveat from RFC 7489, the foundational DMARC specification, states that the sp tag is ignored if it's found in a DMARC record published on a subdomain itself. This means sp only functions when it's part of the organizational domain's DMARC record. If a subdomain has its own DMARC record, that record's p tag will always take precedence over any sp setting from the parent domain. For example, RFC 7489 details this behavior.
Practical implications of sp tag settings
The choice of your sp tag value has significant implications for your email ecosystem. Setting sp=none is often used during the initial DMARC implementation phase to collect reports and understand email flows without impacting deliverability. However, it leaves your subdomains vulnerable to spoofing, as failing emails will still be delivered. A stronger approach is to gradually transition your DMARC policy from none to quarantine or reject.
For domains with many subdomains, or those frequently targeted by spoofing attempts, setting sp=reject can be a vital security measure. This ensures that any unauthorized email claiming to be from your subdomains (even non-existent ones) will be outright rejected by receiving mail servers. This is particularly effective against distributed botnet attacks that might use various subdomains to send spam or phishing emails.
Policy values for organizational domains (p=)
p=none: Monitors email flow and collects DMARC reports without affecting delivery of unauthenticated mail. Ideal for initial setup.
p=quarantine: Directs receiving servers to send unauthenticated emails to the spam or junk folder. Good for a cautious enforcement step.
p=reject: Instructs receiving servers to block or discard unauthenticated emails. Provides the strongest protection against spoofing.
It’s important to understand the full scope of your DMARC policy, especially when dealing with various subdomains and email sending services. For comprehensive guidance, you can review best practices for DMARC setup, including policies and reporting. Additionally, the Google Workspace Admin Help provides helpful insights on DMARC setup.
Important considerations and best practices
Effective DMARC implementation with subdomains requires careful planning. If you omit the sp tag from your organizational domain's DMARC record, subdomains will simply inherit the p policy. This might be acceptable if all your subdomains have the same authentication and sending characteristics as your main domain, but it's rarely the case in complex organizations.
When subdomains need a different policy or use different sending platforms, you have two main options: use the sp tag on the parent domain, or publish a separate DMARC record directly on the subdomain itself. The latter provides the most specific control and will always override any sp setting from the parent. For more on this, check out how DMARC records on subdomains override root policies.
Regardless of your chosen approach, ensure you have robust DMARC reporting enabled (`rua` and `ruf` tags). These reports are indispensable for monitoring your email ecosystem, identifying legitimate sending sources that might be failing DMARC, and detecting unauthorized senders or spoofing attempts. Without proper reporting, you're flying blind, unable to see the true impact of your sp policies or overall DMARC configuration. If you're wondering should I add an explicit DMARC record for subdomains, consider the visibility provided by reports.
Views from the trenches
Best practices
Always include DMARC reporting tags (`rua`, `ruf`) in your DMARC records to gain visibility into your email traffic and authentication results.
Gradually increase your DMARC policy enforcement from `p=none` to `quarantine` then `reject`, monitoring reports at each stage.
Use the `sp` tag on your organizational domain to set a blanket policy for subdomains, or create individual DMARC records for specific subdomains if granular control is needed.
Regularly review your DMARC reports to identify legitimate sending sources that may not be properly authenticated and fix any misconfigurations.
Common pitfalls
Setting `sp=reject` too quickly without thorough testing can lead to legitimate emails from subdomains being blocked, impacting deliverability.
Misunderstanding that `sp=none` means no DMARC policy applies, when in reality it applies a `p=none` policy to subdomains.
Forgetting that a DMARC record on a subdomain overrides the parent domain's `sp` tag, leading to unexpected policy applications.
Not collecting DMARC reports, which makes it impossible to monitor the impact of `sp` policies or detect email spoofing on subdomains.
Expert tips
For large organizations, consider grouping subdomains by function (e.g., marketing, transactional) and applying specific DMARC policies to each group.
When dealing with new or temporary subdomains, a default `sp=reject` on the organizational domain can prevent malicious use, while allowing specific DMARC records for authorized subdomains.
Automate DMARC report analysis to quickly spot trends, identify unauthorized sending, and ensure your `sp` policies are working as intended.
The `np` tag (non-existent subdomain policy) is an upcoming feature in DMARCbis that can help prevent spoofing on domains you don't even own yet.
Expert view
Expert from Email Geeks says that if a subdomain does not publish its own DMARC record, the DMARC policy will be `p=none` if the parent domain has `sp=none`.
2024-09-10 - Email Geeks
Expert view
Expert from Email Geeks says that you might want to set the parent domain's policy to `p=none` but `sp=reject` if your domain is being spoofed by botnets across many random subdomains.
2024-09-10 - Email Geeks
Summary and best practices
The DMARC sp tag is a vital component for managing DMARC policies across your domain's subdomains. While subdomains generally inherit the organizational domain's p policy by default, the sp tag offers the flexibility to define a separate policy for these sub-domains.
Remember, sp=none on a parent domain explicitly sets a monitoring-only policy for subdomains that don't have their own DMARC record. For robust protection, especially against sophisticated spoofing techniques, consider moving your sp policy to quarantine or reject once you have full visibility into your sending practices.
Always combine these policy settings with diligent DMARC report analysis to ensure optimal email deliverability and security for all your domains and subdomains.
