Relaxed vs strict DMARC alignment

27 March 2026 · 12 min read

DMARC does not actually check whether your SPF or DKIM passed. That surprises a lot of people. A message can sail through SPF with a clean pass, carry a valid DKIM signature, and still fail DMARC outright. The thing DMARC genuinely cares about is alignment: whether the domain that authenticated matches the domain a human reader sees in the From: header. The aspf and adkim tags in your DMARC record decide how fussy that match has to be, and that single character (r for relaxed, s for strict) quietly governs whether your perfectly legitimate subdomain mail survives enforcement or gets quarantined.

This guide is specifically about that choice. Not what DMARC is in general, but when strict alignment earns its keep, when relaxed is the right default, and exactly how each setting reshapes what your subdomains are allowed to do.

What alignment actually compares

Every email has two senders, and they are almost never the same address.

• The envelope From (also called the Return-Path, MAIL FROM, or 5321.From) is the SMTP-level address. SPF authenticates this domain. Your recipients never see it.
• The header From (the 5322.From) is the friendly address shown in the mail client. This is the one DMARC protects, because this is the one a phisher impersonates.

DKIM, separately, signs the message and ties it to whatever domain sits in the d= tag of the signature.

DMARC takes the domain that passed SPF (the envelope From domain) and the domain in the DKIM d=, and checks each one against the header From domain. If either lines up to the satisfaction of your alignment mode, DMARC passes. If neither does, DMARC fails, regardless of how clean the underlying SPF or DKIM result was.

So there are two independent alignment switches:

• aspf controls SPF alignment: how the envelope From domain must relate to the header From domain.
• adkim controls DKIM alignment: how the DKIM d= domain must relate to the header From domain.

Both default to relaxed (r) when you leave them out. You only get strict by writing it in.

If you want to confirm what your current record says before changing anything, run your domain through the DMARC checker, which parses every tag including aspf and adkim and tells you the effective mode.

Relaxed and strict, precisely defined

The difference is entirely about the Organizational Domain versus the exact domain.

The Organizational Domain is your registrable domain: the bit you bought, plus its public suffix. For mail.eu.shop.example.co.uk the Organizational Domain is example.co.uk. DMARC works this out using the Public Suffix List, the same list browsers use to decide cookie scope.

Relaxed alignment passes when the two domains share the same Organizational Domain. The subdomain part is ignored.

Strict alignment passes only when the two domains are an exact, character-for-character match.

A worked example. Your header From is:

From: billing@example.com

A message arrives where SPF passed for the envelope domain bounces.mailer.example.com, and DKIM signed with d=example.com.

• SPF, relaxed (aspf=r): bounces.mailer.example.com reduces to Organizational Domain example.com, which matches the header From's Organizational Domain. Aligned.
• SPF, strict (aspf=s): bounces.mailer.example.com is not literally example.com. Not aligned.
• DKIM, relaxed (adkim=r): d=example.com shares the Organizational Domain. Aligned.
• DKIM, strict (adkim=s): d=example.com exactly equals example.com. Aligned.

In relaxed mode this message passes DMARC two different ways. In strict mode it passes on DKIM alone, because that signature happened to use the bare apex domain. Change the DKIM d= to d=mailer.example.com and strict DKIM alignment breaks too, even though the signature itself is cryptographically perfect.

That last point is the whole story in miniature: strict alignment can fail a message that is fully authenticated and entirely legitimate. It is not a security upgrade in the way SPF or DKIM enforcement is. It is a narrowing of what counts as "yours".

A DMARC record that sets alignment explicitly

Here is a record with both modes spelled out so nothing is left to the default:

v=DMARC1; p=reject; rua=mailto:dmarc@example.com;
adkim=s; aspf=s; fo=1

And the far more common, far safer relaxed equivalent:

v=DMARC1; p=reject; rua=mailto:dmarc@example.com;
adkim=r; aspf=r; fo=1

You do not have to set both the same. Mixed records are completely valid and sometimes the right answer:

v=DMARC1; p=reject; rua=mailto:dmarc@example.com;
adkim=s; aspf=r; fo=1

That mixed record says: trust SPF loosely (because envelope domains are messy and vary by provider), but demand an exact DKIM d= match. We will come back to why that specific combination is often the sweet spot.

You can generate a record with the alignment tags pre-set using the DMARC record generator.

Why relaxed is the right default for almost everyone

Relaxed exists because real email infrastructure is built on subdomains, and that is by design, not by accident.

Your bounce handling lives on a subdomain. When you send through Google Workspace, Microsoft 365, Amazon SES, SendGrid, Mailgun, Postmark, or essentially any sending platform, the envelope From is set to one of their bounce subdomains so they can process non-delivery reports. With SPF, the domain that authenticates is that bounce domain, not your header From. Under aspf=r it still aligns because it shares your Organizational Domain (assuming the provider lets you use a custom return-path on your own domain). Under aspf=s it almost never aligns, and you are leaning entirely on DKIM to carry every single message.

Your marketing and transactional streams often sign from subdomains. A platform might sign with d=em.example.com or d=mg.example.com. Relaxed DKIM still aligns. Strict does not.

Forwarding and intermediaries. SPF breaks on forwarding because the forwarder becomes the new envelope sender. DKIM usually survives forwarding (the signature travels with the message), which is exactly why DMARC's "either one passes" design is so forgiving. But if you also clamp DKIM to strict, you remove some of that resilience. For the full picture of how forwarding interacts with authentication, see forwarding and DMARC and why DKIM fails after forwarding.

The practical reality: turn on strict alignment for a typical business domain and you will start quarantining or rejecting legitimate mail from at least one of your own services. Relaxed is not the lazy option. It is the option that matches how email genuinely flows while still completely blocking the attack DMARC is meant to block.

Does relaxed leave a hole an attacker can use?

This is the honest worry, so let us address it directly. The fear is: "If relaxed lets anything.example.com align with example.com, can an attacker abuse a subdomain to impersonate the apex?"

No, not from the outside. To pass relaxed alignment against your example.com header From, the attacker needs SPF or DKIM to authenticate for a domain that resolves to the Organizational Domain example.com. They cannot create records under your domain. They do not control your DNS. An attacker sending from evil.com gets Organizational Domain evil.com, which never shares yours.

The genuine relaxed-versus-strict risk is internal and lateral, not external. If you operate marketing.example.com and you let a third-party SaaS publish SPF and DKIM under that subdomain, then under relaxed alignment that SaaS can technically produce mail that aligns with your apex example.com From address. Whether that matters depends on how much you trust everything under your own tree. For most organisations the answer is "it is fine, we control our own subdomains". For a few, that lateral exposure is exactly the reason to consider strict.

When strict alignment genuinely earns its place

Strict is a real tool, not a trap. Reach for it deliberately, in these situations.

1. A locked-down domain with one tightly controlled sending path. If bank-alerts.example.com sends only from infrastructure you fully own, signs every message with d=bank-alerts.example.com, and uses a custom return-path on that exact domain, then strict alignment (adkim=s; aspf=s) is achievable and tightens the net. It guarantees that even a compromised or careless subdomain elsewhere in your estate cannot produce apex-aligned mail. High-value transactional domains, alerting domains, and dedicated phishing-bait lookalikes are good candidates.

2. You want to prevent your own subdomains aligning upward. This is the lateral-exposure case above. Strict DKIM means a signature from d=newsletter.example.com will not align with a From: ceo@example.com message. If your subdomains are delegated to teams or vendors you do not fully trust, strict removes their ability to borrow your apex identity.

3. Defending against cousin and same-org subdomain abuse in a large estate. Big organisations with dozens of subdomains and many vendors sometimes prefer the explicitness of strict so that every sending subdomain has to stand on its own exactly-matching credentials.

4. Regulatory or contractual requirements that specify exact-match alignment. Rare, but they exist, and if you are handed one, strict is what satisfies it.

In every one of these, the precondition is the same: you can guarantee exact-match SPF or DKIM for every legitimate message. If you cannot make that guarantee, strict will cost you deliverability, not buy you security. Verify the guarantee first by analysing real aggregate reports (more on that below).

How the choice reshapes subdomain sending

This is the part the brief specifically asks about, and it is where the two modes diverge most sharply.

The apex policy, the subdomain policy, and alignment are three different things

People conflate these constantly, so let us separate them.

• p= sets the policy for the apex (the exact Organizational Domain).
• sp= sets the policy for subdomains that do not publish their own DMARC record.
• adkim / aspf set alignment strictness, and they apply to whatever domain the message claims in its header From.

Alignment and sp= are orthogonal. sp= decides what happens to a message whose header From is a subdomain. Alignment decides whether that message's authentication counts as aligned in the first place. For how sp= behaves and where subdomains can publish their own records, see the subdomain policy (sp) tag and publishing a subdomain DMARC record.

What strict does to a subdomain that sends mail

Suppose support.example.com sends ticket notifications through a help-desk vendor. The header From is support@support.example.com.

• Relaxed: the vendor can sign with d=example.com, d=support.example.com, or even d=mail.example.com, and the envelope can be the vendor's bounce subdomain under your tree. As long as everything resolves to example.com, it aligns. You have flexibility.
• Strict: the DKIM d= must be exactly support.example.com, or the envelope From must be exactly support.example.com. The vendor must support exact-subdomain signing and a custom return-path on that precise label. Many vendors cannot or will not do this on a per-subdomain basis. The result is broken DMARC for that stream.

So strict alignment effectively forces every sending subdomain to have its own exactly-matching DKIM key and return-path configuration. That is a meaningful operational burden. It is doable for a handful of carefully managed subdomains. It is painful across dozens of vendor-driven ones.

The apex-and-subdomain mismatch trap

A subtle and very common breakage: you send "from the apex" but your provider signs with a subdomain d=, and you have set strict.

From: hello@example.com
DKIM: d=mg.example.com   (Mailgun-style subdomain signing)

Under adkim=r this aligns. Under adkim=s it fails, because mg.example.com is not exactly example.com. Nothing is misconfigured in the email itself. The signature is valid. The mail is legitimate. Strict alignment alone breaks it. This single mismatch is one of the most frequent causes of "DMARC fails but SPF and DKIM pass", which we cover in detail at DMARC fails but SPF and DKIM pass.

Why adkim=s; aspf=r is often the pragmatic compromise

Recall the mixed record from earlier. There is a reason it shows up in mature setups.

• SPF alignment is inherently fragile because envelope domains vary wildly by provider and you rarely control them precisely. Keeping aspf=r avoids needless SPF-side failures.
• DKIM is the durable signal. It survives forwarding and you usually have more control over the d= value. If, and only if, you can guarantee that every legitimate stream signs with an exactly-matching d=, then adkim=s closes the lateral-subdomain hole without the SPF pain.

The catch is that "guarantee every stream signs with an exact match" precondition. If even one important service signs with a subdomain d= you did not account for, strict DKIM will quietly start failing it. So this combination is for domains you have already mapped completely, not for day-one rollouts.

How to decide, in order

Do not pick alignment in the abstract. Pick it from evidence about your own mail. The sequence that avoids self-inflicted outages:

1. Stay at p=none with relaxed alignment while you collect data. At p=none nothing is enforced, so alignment failures cost you nothing yet but still show up in reports. This is the safe observation window. See the broader journey at the enforcement journey.
2. Read aggregate (RUA) reports to inventory every source that sends as your domain and its subdomains, and note for each one whether it aligns by SPF, by DKIM, or both, and under which mode. The DMARC report analyzer turns the raw XML into a readable source-by-source breakdown, and reading your first DMARC report walks through what each field means.
3. Ask the strict question per stream: for each legitimate source, can it produce an exact-match d= or exact-match envelope domain? If the answer is yes for all of them, strict is on the table. If it is no for any of them, relaxed is your answer for that alignment dimension.
4. Move the policy, not the alignment, first. Get to p=quarantine then p=reject under relaxed alignment. Enforcement is where the security benefit lives. Tightening alignment afterwards, if at all, is a refinement.
5. Only then, if you have a specific reason, tighten to strict, one dimension at a time, watching reports for new failures after each change.

Tightening alignment before you have full source visibility is the classic way to break legitimate mail at enforcement. Tightening it after, with evidence, is controlled and reversible.

Common mistakes around alignment

• Setting strict to "be more secure" without checking sources. Strict is not more secure against external spoofing; relaxed already blocks that completely. Strict only constrains your own subdomains, and it costs deliverability if your sources cannot meet it.
• Forgetting that aspf and adkim are independent. You can, and often should, set them differently.
• Assuming strict apex alignment also governs subdomains. It governs alignment for whatever header From appears. The subdomain policy is a separate sp= decision.
• Reaching p=reject on relaxed, then flipping to strict and not re-reading reports. Every alignment tightening is a potential new failure surface. Treat it like a policy change and monitor it.
• Letting a vendor sign with a subdomain d= you have not whitelisted in your mental model, under strict DKIM. Silent failures follow.

For the wider set of pitfalls, DMARC common mistakes is the companion read, and DKIM alignment explained goes deeper on the DKIM-specific mechanics.

The practical takeaway

Relaxed alignment is the correct default for the overwhelming majority of domains. It matches the way real email actually flows, where bounce handling, marketing platforms, and transactional services all legitimately operate from subdomains of your domain, and it still completely blocks an outside attacker from impersonating your header From. It is not the loose or careless option. It is the one that lets you reach p=reject without breaking your own mail.

Strict alignment is a deliberate, narrow tool. It earns its place on tightly controlled domains where you can guarantee exact-match SPF or DKIM on every legitimate message, and where you specifically want to stop your own subdomains or vendors from borrowing your apex identity. Set it after you have full source visibility, never before, and tighten one dimension at a time.

The honest rule of thumb: get to enforcement on relaxed first, because that is where the security is, then consider strict only if you have a concrete lateral-trust reason and the report data to back it. Start by confirming what your record says today with the DMARC checker, map your real sources with the DMARC report analyzer, and if mapping every subdomain sender and getting alignment right across a messy estate is more than you want to own, our done-for-you hosted DMARC service handles the journey from p=none to p=reject, alignment tuning included, with no email outage.