DMARC Subdomains: aspf, adkim & sp Explained

What the sp tag really controls

Where DMARC looks first DMARC policy discovery starts with the visible RFC5322 From domain, not the Envelope From or Return Path. For example, if a message has From: info@domain.com, its Author Domain is domain.com.

For an existing subdomain, sp is considered when policy discovery selects the Organizational Domain or PSD record rather than an exact Author Domain record.

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 Author Domain has its own valid DMARC record, that record's p policy is used.
• If policy discovery selects the Organizational Domain or PSD record and the Author Domain is an existing subdomain of that domain, the selected record's valid sp value applies.
• If the applicable Organizational Domain or PSD record omits sp, its p value applies to an existing subdomain.
• If a DMARC Policy Record is published on a subdomain of an Organizational Domain or PSD, its sp value is ignored. The record's p value applies to that exact Author Domain.
• If the Author Domain does not exist, np is considered before sp; the subdomain policy guide covers that branch in detail.

Valid values and a label you may see

• 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.

Concrete examples

• 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.

What sp can do in practice

• sp=none expresses no handling preference for failures from applicable existing subdomains.
• sp=quarantine says the Domain Owner considers those failures suspicious.
• sp=reject says the Domain Owner considers those failures a clear indication that use of the domain is not valid.

These are published Domain Owner Assessment Policies. A participating Mail Receiver can use the requested policy in its own handling decision, but DMARC does not guarantee a specific placement or disposition at every receiver.

Record fragments to adapt

These examples are illustrative. Replace the reporting address with one authorized for your domain and review the complete record before publication.

• Root protected, subdomains monitored

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

• Namespace fully enforced

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

• Subdomain override during onboarding

_dmarc.events.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Operational guidance Choose sp from production evidence, not from the apparent simplicity of the namespace. Inventory active Author Domains, inspect delivered-message authentication, and review aggregate reports before requesting stricter handling. Publish a separate subdomain record when that Author Domain needs its own policy, reporting destination, alignment mode, or operational owner. A parent sp change can affect legitimate low-volume senders that a public DNS inventory cannot reveal.

Alignment modes: what aspf and adkim actually control

DMARC has two independent alignment checks.

• SPF alignment uses the RFC5321 Mail From identity, often called the Return Path. Check what a domain currently publishes with the SPF checker.
• DKIM alignment uses the d= domain in the DKIM signature.

Each alignment can be strict (s) or relaxed (r).

aspf (SPF alignment)

• aspf=r relaxed. The From domain must share the same organizational domain with the SPF authenticated domain.
• aspf=s strict. The domains must match exactly.

adkim (DKIM alignment): see the dedicated adkim tag guide for a deeper walk-through.

• adkim=r relaxed. The From domain must share the same organizational domain with the DKIM d= domain.
• adkim=s strict. The domains must match exactly.

Palisade's DMARC agent helps operators manage sp, aspf, and adkim across their domains.

Operational fit for each alignment mode

aspf=s (SPF strict)

What it requires From domain must match the SPF identity exactly.

When it may fit

• Every legitimate sender can use an SPF-authenticated Mail From domain identical to the Author Domain.
• The organization deliberately wants SPF-based DMARC passes to require that exact domain relationship.

Trade offs

• Many providers default to subdomain Return Path values like bounce.mail.example.com. Those fail under strict mode unless reconfigured.
• Legacy systems may not support a root Return Path.

Real example From billing@example.com via a billing platform that insists on spf.mail.example.com. With aspf=s, SPF fails alignment until you change the Return Path to example.com or rely on DKIM alignment instead.

aspf=r (SPF relaxed)

What it requires From and SPF identity share the same organizational domain.

When it may fit

• Operational flexibility for multi ESP environments and faster onboarding.
• Accommodates controlled subdomain Return Path values that share the same Organizational Domain as the Author Domain.

Trade offs

• More than one domain can satisfy the relationship, so subdomain issuance and Return Path ownership still need governance.
• Relaxed alignment is not a receiver-delivery guarantee and does not make a failing SPF check pass.

Real example From news@example.com via an ESP that uses return.news.example.com. With aspf=r, a passing SPF result for that Mail From domain can align with the Author Domain.

adkim=r (DKIM relaxed)

What it requires From and DKIM d= share the same organizational domain.

When it may fit

• A legitimate platform signs with a controlled subdomain that shares the Author Domain's Organizational Domain.
• The organization needs that passing subdomain signature to remain eligible for a DKIM-aligned DMARC pass.

Trade offs

• Subdomain signing authority and DKIM key rotation still need governance.
• Forwarding can preserve or break DKIM depending on whether the signed content changes; relaxed alignment does not guarantee that the signature survives.

Real example From support@example.com with a passing signature using d=support.example.com. With adkim=r, DKIM aligns and can produce the DMARC pass even if SPF does not provide an aligned pass after forwarding.

adkim=s (DKIM strict)

What it requires From domain must match DKIM d= exactly.

When it may fit

• Every production sender that relies on DKIM alignment can sign with a d= domain identical to its visible From domain.
• The organization deliberately wants DKIM-based DMARC passes to require that exact relationship.

Trade offs

• Some providers cannot sign with root d= without extra setup.
• Migration requires DNS changes and coordination.

Real example From alerts@example.com, signed d=example.com using a centralized service. With adkim=s, any vendor that insists on d=vendor.example.com fails until you move them to root signing.

How to decide from production evidence

• Inventory every email source. Note the current Return Path domain and the DKIM d= domain. An email security score gives a quick baseline before you start.
• Treat relaxed alignment as the protocol default, not as evidence that every sender is configured correctly.
• Change adkim to strict only after every production path that depends on DKIM alignment has an exact-match signing domain or another verified aligned pass. Use the operational adkim change and rollback guide for that review.
• Change aspf to strict only after the SPF-authenticated Mail From identity for every relevant sender exactly matches its Author Domain, or DKIM supplies the intended aligned pass.
• Use per-subdomain DMARC records when an Author Domain requires a separate policy, reporting destination, alignment setting, or operational owner.
• Decide p, sp, and np separately from alignment mode. Review the p/sp/np inheritance and DNS Tree Walk before changing namespace-wide handling.

Applies to both aspf (SPF) and adkim (DKIM) alignment.

Real subdomain scenarios

• Marketing on a new ESP signs with d=promo.example.com and uses return.promo.example.com. If the visible From domain is promo.example.com, a passing SPF result for that Mail From domain or a passing DKIM signature with that d= domain can satisfy relaxed alignment. Publishing the tags alone does not make authentication pass.
• A legacy ticketing tool sends from support@example.com but uses a vendor Return Path that you cannot change. SPF often fails after forwarding to agents. If a delivered message retains a passing DKIM signature with d=support.example.com, that signature aligns under adkim=r and can satisfy DMARC even when SPF fails. Publishing DKIM keys alone does not establish a passing signature.
• A phishing campaign abuses the existing subdomain secure-login.example.com. Raising the parent to sp=reject or publishing _dmarc.secure-login.example.com with p=reject asks participating receivers to reject messages that fail DMARC for that name.

Check the record before changing alignment or subdomain policy

Use the DMARC checker to confirm the public policy record at the Author Domain and any applicable parent. The checker can show published tags and syntax; it cannot identify every production sender, prove that a delivered message aligned, or predict a Mail Receiver's private delivery decision.

Palisade analyzes DMARC aggregate-report evidence to identify sending sources and alignment issues and to propose remediation work. Your team reviews the evidence and controls any DNS change. Start with Palisade when the unresolved job is ongoing sender inventory and policy progression rather than a one-time public record check.

Evidence

Sources and further reading

• RFC 9989 Section 4.4: Identifier Alignment Explained
• RFC 9989 Section 4.7: DMARC Policy Record Format and tag definitions
• RFC 9989 Section 4.10.1: DMARC Policy Discovery
• RFC 7208: Sender Policy Framework
• RFC 6376: DomainKeys Identified Mail