# DMARC aspf & adkim Tags Explained (Relaxed vs Strict)

> What aspf=r, aspf=s, adkim=r, and adkim=s actually do, how alignment works on subdomains, and when to use the sp tag. Clear examples included.

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](/tools/dmarc). 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

![Five-step flow showing how DMARC resolves a subdomain's policy from its own record, the parent's sp tag, or the parent's p value.](/images/figures/dmarc-and-subdomains-aspf-adkim-and-sp-tags-explained-fig1.webp)
*sp only applies when the subdomain has no DMARC record of its own.*

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**

- 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` 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](/resources-post/fixing-spf-alignment-dmarc----full-guide) 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.
![DMARC subdomain, SPF alignment, and DKIM alignment controls in Palisade.](/images/cms/68db8524d8048bc4cbb5a5d3_dmarc-subdomains-tags.jpg)

*Palisade's AI-first DMARC agent helps operators manage sp, aspf, and adkim across their domains.*
### 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

- Inventory every email source. Note the current Return Path domain and the DKIM `d=` domain.
- If most sources already use subdomain Return Path and subdomain `d=`, start with `aspf=r` and `adkim=r`.
- 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.
- If you are high risk with few vendors, aim for `aspf=s` and `adkim=s` after a short discovery period.
- Use per subdomain DMARC records for exceptions. Keep exceptions temporary and attach a removal date.
- Plan your `sp` progression. Start with `sp=none` only if needed. Target `sp=reject` once subdomains are aligned.

![Two-column comparison of relaxed and strict DMARC alignment modes for the aspf and adkim tags.](/images/figures/dmarc-and-subdomains-aspf-adkim-and-sp-tags-explained-fig2.webp)
*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`. 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.

‍