DMARC Subdomains: sp, aspf & adkim Tags Explained

When a team rolls out DMARC, attention often goes to the root domain such as example.com. In practice, a large share of legitimate mail originates from subdomains like news.example.com, support.example.com, or tickets.example.com. To avoid surprises in production, it is important to understand how DMARC evaluates those subdomains and how the aspf, adkim, and sp tags work together to deliver strong protection without blocking good mail.

At a high level, DMARC checks two things. First, authentication from SPF or DKIM. Second, alignment, which compares the visible Header From domain with the domain that passed SPF or DKIM. Your aspf and adkim tags decide how strict that comparison must be. You can require an exact match with strict alignment or allow a shared organizational domain with relaxed alignment.

Your sp tag is the inheritance control for your namespace. It decides what happens to subdomains that do not publish their own DMARC record. If a subdomain has no DMARC record of its own, the evaluator will use the parent’s sp value. If the parent omits sp, the evaluator uses the parent’s p value for subdomains by default. The selection is always driven by the visible Header From domain.

Strict alignment is uncommon in the public DNS: Palisade's 2026 study of 100,000 ranked domains found that 8.2% of valid DMARC records request strict SPF or DKIM alignment. That does not make strict mode wrong; it shows why a rollout should be based on the organization's real sender topology rather than copied from a generic record.

DMARC subdomain decisions at a glance

Policy tags and alignment tags answer different questions. p, sp, and np express the requested handling for a message that fails DMARC. aspf and adkim decide how closely an authenticated SPF or DKIM domain must match the visible From domain to produce an aligned pass.

What the sp tag really controls

Where DMARC looks first DMARC always starts with the visible Header From domain. It does not start off the Envelope From or Return Path. For example, if your email is sent from info@domain.com, the Header From domain is domain.com

The evaluator tries _dmarc.. If no valid record exists there, RFC 9989 uses a bounded DNS tree walk toward the organizational or public-suffix policy domain. For example, it can query _dmarc.promo.mail.example.com, then _dmarc.mail.example.com, and then _dmarc.example.com.

RFC 9989, published in May 2026 with RFC 9990 and RFC 9991 for reporting, replaced RFC 7489. It replaces public-suffix-list policy discovery with the DNS tree walk and adds np for non-existent subdomains alongside sp. The sp, aspf, and adkim behavior covered here remains central. See what DMARCbis changed for the full migration summary.

When sp applies

• If the Header From domain has its own DMARC record, that record’s p policy is used and sp is ignored.
• If the Header From domain does not have its own DMARC record and is a subdomain of a parent that does have a DMARC record, the parent’s sp value applies to that subdomain.
• If the parent record omits sp, the parent’s p value applies to its subdomains by default.

• Valid sp values are none, quarantine, and reject. The difference between the last two matters at enforcement time — see reject vs quarantine.
• There is no sp=same in the DMARC specification. Some tools display wording like same as p or inherit to describe the default behavior when sp is omitted. That label means the subdomain follows the parent’s p value.

• Header From is promo.mail.example.com

• _dmarc.promo.mail.example.com exists with p=none.
• Result. Use p=none from that record. sp on any parent is not consulted.

• Header From is mail.example.com

• No _dmarc.mail.example.com. Parent _dmarc.example.com exists with p=reject; sp=quarantine.
• Result. Use sp=quarantine from the parent because the Header From is a subdomain without its own record.

• Header From is help.example.com

• No _dmarc.help.example.com. Parent _dmarc.example.com exists with p=reject and no sp.
• Result. Subdomain inherits p=reject because sp is absent.

• Header From is example.com

• _dmarc.example.com exists with p=reject; sp=none.
• Result. Use p=reject. sp is irrelevant because the Header From is the parent itself.

• sp=none allows discovery and monitoring on silent subdomains during onboarding.
• sp=quarantine can throttle risk during a migration without discarding messages outright.
• sp=reject asks receivers to reject failed subdomain mail and is the long-term target once legitimate subdomain senders are aligned.

• Root protected, subdomains monitored

• Namespace fully enforced

• Subdomain override during onboarding

Operational guidance Start with a clear plan for sp. Many teams begin with sp=none to avoid breaking unknown subdomain senders. Publish per subdomain records with p=reject as each stream is validated. When coverage is complete, raise sp to reject so that any new or forgotten subdomain is protected by default.