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.

The rest of this article goes deeper on sp, then covers alignment modes with practical guidance and examples.

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.<Header-From-domain>. If none exists, it walks up to the organizational domain using the public suffix list. For example, from _dmarc.promo.mail.example.com to _dmarc.mail.example.com, then to _dmarc.example.com.

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 values and a label you may see

• Valid sp values are none, quarantine, and reject.
• 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

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

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

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

4. 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 allows discovery and monitoring on silent subdomains during onboarding.
• sp=quarantine can throttle risk during a migration without discarding messages outright.
• sp=reject blocks unauthenticated or misaligned subdomain mail and is the long term target once you have clear coverage.

Examples you can copy

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

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

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

When and why to choose each alignment mode

aspf=s (SPF strict)

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

Why choose it

• Maximum brand control and clear accountability.
• Useful in regulated or high risk environments such as banking or healthcare.
• Easier incident response since any SPF aligned pass points to the exact domain.

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.

Why choose it

• Operational flexibility for multi ESP environments and faster onboarding.
• Lower risk of false negatives during migrations.
• Often the most practical SPF choice for diverse stacks.

Trade offs

• Slightly lower assurance because more subdomains can pass.
• Requires governance on who can create sending subdomains and how Return Path is issued.

Real example
From news@example.com via an ESP that uses return.news.example.com. With aspf=r, SPF can align while you move toward strong DKIM alignment.

adkim=r (DKIM relaxed)

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

Why choose it

• Very practical default. Many platforms sign with d=sub.example.com that you control.
• DKIM survives forwarding better than SPF, so relaxed DKIM provides resilience without forcing root d= everywhere.
• Helps satisfy BIMI prerequisites once DMARC alignment is stable.

Trade offs

• Same assurance considerations as SPF relaxed. You must manage subdomain issuance and key rotation well.

Real example
From support@example.com signed with d=support.example.com. With adkim=r, the message aligns and passes DMARC even if SPF fails after a forward.

adkim=s (DKIM strict)

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

Why choose it

• Highest assurance on the signal that most reliably survives forwarding.
• Simplifies investigations since any DMARC aligned pass must be signed by the root.
• Strong choice when you can centralize DKIM keys and standardize d=example.com across vendors.

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 quickly

1. Inventory every email source. Note the current Return Path domain and the DKIM d= domain.
2. If most sources already use subdomain Return Path and subdomain d=, start with aspf=r and adkim=r.
3. If you can standardize on d=example.com across vendors, prefer adkim=s. Consider keeping aspf=r for flexibility unless you also control Return Path globally.
4. If you are high risk with few vendors, aim for aspf=s and adkim=s after a short discovery period.
5. Use per subdomain DMARC records for exceptions. Keep exceptions temporary and attach a removal date.
6. Plan your sp progression. Start with sp=none only if needed. Target sp=reject once subdomains are aligned.

Real subdomain scenarios

• Marketing on a new ESP signs with d=promo.example.com and uses return.promo.example.com. With aspf=r and adkim=r, mail aligns on day one.
• 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. With DKIM keys on support.example.com and adkim=r, the stream passes DMARC reliably.
• A phishing campaign abuses secure-login.example.com. You do not have a DMARC record on that subdomain. Raising the parent to sp=reject or publishing _dmarc.secure-login.example.com with p=reject cuts off the vector.

FAQs

Q1. Do subdomains inherit the root DMARC policy by default
Yes. If a subdomain does not publish its own record, it inherits the parent policy. The sp tag lets you override the default for all subdomains at once.

Q2. What happens if I omit sp
Subdomains follow the same policy as the root p tag. For example, if p=reject, subdomains reject unless you add sp to change that.

Q3. Should most organizations pick strict or relaxed alignment
Most start with relaxed alignment for both aspf and adkim to prevent breakage during discovery. As governance improves, many tighten DKIM first by moving to adkim=s, then consider aspf=s if Return Path can be standardized.

Q4. Can different subdomains use different policies
Yes. Publish a DMARC record at each subdomain that needs a custom stance. For example, _dmarc.events.example.com can use p=none during onboarding, while _dmarc.billing.example.com uses p=reject.

Q5. Is sp=none safe to leave in place
Treat sp=none as temporary. Monitor aggregate reports, find every sending subdomain, publish DMARC on each one, then move sp to quarantine or reject.

Q6. How do aspf and adkim interact with sp
aspf and adkim decide whether authentication aligns. sp decides the enforcement outcome for subdomains that do not publish DMARC. They cover different parts of the evaluation.

Q7. What is a sensible starting configuration
A common starting point is p=none; sp=none; aspf=r; adkim=r to collect data without risk. Then raise the root to p=reject, publish per subdomain DMARC with p=reject as you validate streams, and finally raise sp to reject to protect the whole namespace.

‍