Last updated: July 2026

In short: The optional sp= tag in a DMARC record establishes an independent policy specifically for subdomains. It allows administrators to lock down subdomains strictly or manage them with greater flexibility than the primary domain.

By default, Domain-based Message Authentication, Reporting, and Conformance (DMARC) enforces policy inheritance across your DNS hierarchy. When you publish a DMARC record at _dmarc.example.com, the policy mode declared in the p= tag applies not only to example.com but automatically inherits across every subdomain, such as mail.example.com or portal.example.com.

However, large organizational architectures or phased rollouts often require subdomains to follow different rules than the primary domain name. To provide this granular control, the protocol specifies the sp= (Subdomain Policy) tag.

How the sp= tag operates under RFC 7489

The sp= tag accepts exactly the same policy values (none, quarantine, reject) as the primary p= tag. Its distinguishing feature is its strict domain scope: it applies solely to subdomains, overriding whatever policy is declared in p=.

According to RFC 7489, the protocol defines: sp: Requested Mail Receiver policy for all subdomains (plain-text; OPTIONAL). Indicates the policy to be enacted by the Receiver at the request of the Domain Owner. It applies only to subdomains of the domain queried and not to the domain itself. Its syntax is identical to that of the "p" tag defined above. If absent, the policy specified by the "p" tag MUST be applied for subdomains.

A DMARC record utilizing a distinct subdomain policy looks like this:

v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc-reports@example.com

In this deployment, unauthenticated emails claiming to originate from the root domain (example.com) are rejected outright (p=reject), whereas unauthenticated messages claiming to originate from any subdomain are placed in quarantine (sp=quarantine).

Strategic use cases for the sp= tag

Deploying an sp= tag is especially valuable in two common operational scenarios:

1. Locking down subdomains while monitoring the root domain

Organizations often require several months to audit and authorize all complex email workflows across their primary domain (example.com). While the root domain remains in monitoring mode (p=none), attackers could easily exploit unprotected subdomains (support.example.com or billing.example.com) to launch spoofed phishing campaigns.

By configuring p=none; sp=reject, you immediately lock down all non-sending subdomains against exact-domain spoofing while safely collecting XML reports on your primary domain.

2. Providing a safety buffer during subdomain onboarding

If your primary domain is already enforced under p=reject, but your marketing team launches a new third-party email platform on a dedicated subdomain (news.example.com), an immediate reject policy might drop legitimate mail if DNS alignment is incomplete. Setting sp=quarantine creates a temporary safety buffer for your subdomains until all newly onboarded services pass alignment cleanly.

Verifying your configuration

To check whether your primary policy and subdomain policy inherit properly across your DNS tree, analyze your domain using the free MXAudit scanner.

To learn more about structuring enterprise authentication policies and setting up specific hosting providers, visit the DMARC hub and practical guides like IONOS DMARC setup.

Further reading