How to Generate a DMARC Record for Subdomains: sp= Tag Guide

Managing DMARC policies across subdomains is one of the most misunderstood aspects of email authentication. Organizations routinely operate dozens of subdomains for marketing campaigns, transactional email, development environments, and partner integrations, each with different email sending requirements. Without a deliberate subdomain strategy, these domains either inherit a policy that is too strict, breaking legitimate mail, or too permissive, leaving them open to spoofing. The sp= tag in your organizational domain’s DMARC record gives you centralized control over subdomain policy without requiring individual DMARC records at every subdomain. This guide explains exactly how subdomain policy inheritance works, when to use sp= versus dedicated subdomain records, and the most common patterns for balancing security with deliverability.

How Does Subdomain Policy Inheritance Work?

When a receiving mail server evaluates a message from mail.example.com, it first looks for a DMARC record at _dmarc.mail.example.com. If no record exists there, it falls back to the organizational domain’s record at _dmarc.example.com. This fallback behavior is defined in RFC 7489, Section 6.6.3, and it means that every subdomain without its own DMARC record is governed by the parent domain’s policy. If the parent record includes an sp= tag, that value applies to all subdomains that rely on inheritance. If sp= is absent, subdomains inherit the p= tag value instead. According to Valimail’s 2025 Email Authentication Report, 68% of organizations with DMARC at enforcement have not published sp= tags, meaning their subdomains default to the same policy as the organizational domain. This implicit inheritance works well when your subdomain policy should match your parent policy, but it creates problems when subdomains have different requirements.

As of 2025, DMARC is mandatory under multiple compliance frameworks. CISA BOD 18-01 requires p=reject for US federal domains. PCI DSS v4.0 mandates DMARC for organizations processing payment card data as of March 2025. Google and Yahoo require DMARC for bulk senders (5,000+ messages/day) since February 2024, and Microsoft began rejecting non-compliant email in May 2025. The UK NCSC, Australia’s ASD, and Canada’s CCCS all mandate DMARC for government domains. Cyber insurers increasingly require DMARC enforcement as an underwriting condition.

What Does the sp= Tag Do?

The sp= tag accepts the same three values as the p= tag: none, quarantine, and reject. It appears in the organizational domain’s DMARC record and applies exclusively to subdomains that do not publish their own DMARC records. A record like v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@example.com; enforces strict rejection for the organizational domain while leaving all subdomains in monitoring mode. This is particularly useful during initial DMARC deployment, when the organizational domain may already be well-characterized but subdomains still need time for sender discovery and alignment testing. The sp= tag gives you a single point of control, so you do not need to publish and maintain individual records across every subdomain in your DNS zone. You can generate a record with the correct sp= value using our DMARC record generator.

Should You Use sp= or Dedicated Subdomain Records?

The choice between sp= and individual subdomain DMARC records depends on how many subdomains you operate and how varied their email sending patterns are. The sp= tag is ideal when most subdomains share the same policy requirement. It keeps your DNS clean and your configuration centralized. A single change to the organizational domain’s record updates policy for every inheriting subdomain instantly. However, sp= applies uniformly to all subdomains without exception. If even one subdomain needs a different policy, you must publish a dedicated DMARC record for that specific subdomain. Dedicated subdomain records always take precedence over sp= inheritance, giving you granular control where you need it. The most effective approach combines both: use sp= as the default policy for the majority of subdomains, then publish explicit records only for the handful of subdomains that require exceptions. A 2025 analysis by Agari found that organizations using this hybrid approach resolved DMARC alignment issues 40% faster than those relying solely on per-subdomain records.

How Do You Generate a DMARC Record with sp= Using Our Tool?

Our DMARC record generator includes a dedicated subdomain policy field that lets you set the sp= value independently from your main policy. Start by selecting your organizational domain’s p= policy based on your current enforcement readiness. Then choose the sp= value that reflects where your subdomains stand in their authentication journey. If your subdomains are still being characterized, set sp=none to collect aggregate reports without impacting delivery. If your organizational domain is at p=reject and you are confident that all active subdomains have correct SPF and DKIM alignment, match sp=reject to close off subdomain spoofing entirely. The generator outputs the complete TXT record value, which you publish at _dmarc.yourdomain.com in your DNS provider. After publishing, verify the record using our DMARC checker to confirm that both p= and sp= tags are correctly parsed.

What Are Common Subdomain Policy Patterns?

The most widely adopted pattern during DMARC rollout is a strict organizational policy paired with a permissive subdomain policy. Organizations set p=reject on the root domain to protect their primary brand identity while keeping sp=none or sp=quarantine on subdomains that are still being onboarded. Marketing subdomains like news.example.com or promo.example.com frequently use third-party email service providers whose DKIM and SPF configurations take time to align, so keeping them in monitoring mode during that process avoids delivery disruptions. Production subdomains that send transactional email, such as app.example.com or notify.example.com, can typically move to sp=reject earlier because their sending infrastructure is more tightly controlled. Organizations with dormant or parked subdomains benefit from setting sp=reject to prevent attackers from exploiting subdomains that should never send email at all. Moving from sp=none to sp=reject is a phased process that typically takes 90 or more days per phase, with the full journey from initial deployment to complete enforcement spanning 9 to 18 months depending on organizational complexity.

Does sp= Override a Subdomain’s Own DMARC Record?

No. A DMARC record published directly at a subdomain always takes precedence over the organizational domain’s sp= tag. When a receiving server checks DMARC for mail.example.com, it queries _dmarc.mail.example.com first. If a record exists there, that record’s p= tag determines the policy, and the organizational domain’s sp= value is never consulted. This precedence rule is what makes the hybrid approach work: you set a default via sp= and override it selectively with dedicated records where needed. One important nuance is that the subdomain’s own record must be complete and valid. A malformed record at the subdomain level causes a PermError, and different receiving servers handle PermErrors inconsistently. Some fall back to the organizational domain’s policy while others treat the lookup as failed entirely. Always validate subdomain records with a DMARC checker after publishing.

How Does sp= Apply to Sub-Subdomains?

Sub-subdomains like tracking.mail.example.com follow the same inheritance chain but with an important caveat. RFC 7489 defines the organizational domain as the domain directly under the public suffix, which in most cases is the registrable domain like example.com. When evaluating DMARC for a sub-subdomain, the receiving server looks for a record at _dmarc.tracking.mail.example.com, then falls back to _dmarc.example.com, skipping _dmarc.mail.example.com entirely. This means a DMARC record published at mail.example.com does not automatically cover tracking.mail.example.com unless it is the organizational domain. The sp= tag at the organizational domain level governs all subdomains and sub-subdomains that lack their own records. If you need distinct policies at multiple subdomain depths, you must publish explicit DMARC records at each level. Keep this hierarchy in mind when planning your authentication architecture, particularly if your organization uses nested subdomains for environment isolation or geographic routing.

Frequently Asked Questions

What Happens if I Omit the sp= Tag Entirely?

If your DMARC record does not include an sp= tag, all subdomains without their own DMARC record inherit the p= tag value from the organizational domain. Setting p=reject without sp= means every subdomain is also subject to reject policy. This is safe only if you have confirmed that all active subdomains have properly aligned SPF and DKIM. If any subdomain sends legitimate email that fails alignment, those messages will be rejected. Adding an explicit sp= tag, even if its value matches p=, makes your intent clear and simplifies future audits.

Can I Set sp=reject While Keeping p=none?

Yes, this is a valid configuration, though it is uncommon. Setting sp=reject with p=none means your organizational domain is in monitoring mode while all subdomains enforce strict rejection. This pattern is occasionally used by organizations that have locked down their subdomains first because subdomain sending is simpler and more controlled, while the root domain still needs time to characterize all legitimate senders. The DMARC specification places no restrictions on the relationship between p= and sp= values, so any combination is technically valid.

Sources

• CISA Binding Operational Directive 18-01
• Microsoft Outlook DMARC Enforcement May 2025 (2025)
• PCI DSS v4.0 — DMARC Requirement (2025)