DMARC Alignment Explained: Strict vs. Relaxed Alignment

Ask most administrators whether their domain is protected against spoofing and they’ll point to an SPF record and a DKIM selector. Both are running, both pass, and the mail flows. On paper, the domain looks defended.

The problem is that SPF and DKIM were never designed to protect the part of the message a human being reads. SPF validates a domain that appears in the SMTP conversation. DKIM validates a domain that appears in a cryptographic signature header. Neither one is required to have anything to do with the sender shown in a mail client.

That is the gap a phisher lives in. An attacker can register a throwaway domain, publish a flawless SPF record for it, sign the message with a valid DKIM key for that same throwaway domain, and still put From: billing@example.com in the visible header. Every individual authentication check passes. The recipient sees your brand.

DMARC closes that gap with one deceptively simple rule: authentication only counts if it belongs to the domain in the visible From: header. That rule is DMARC alignment, and understanding it is the difference between a DMARC record that stops spoofing and one that just generates reports.

What DMARC Actually Evaluates

A single email carries several domain identifiers, and they are frequently different from each other by design. Three of them matter here.

Identifier	Where it lives	What validates it	Visible to the recipient?
RFC5321.MailFrom (envelope sender / Return-Path)	The SMTP MAIL FROM command	SPF	No
d= signing domain	The DKIM-Signature header	DKIM	No
RFC5322.From (header From)	The message headers	Nothing, on its own	Yes

The last row is the important one. The From: header is the only identifier the recipient sees, and it is the only one with no native authentication mechanism attached to it. Anyone can type anything there.

DMARC’s job is to bind that visible domain to a domain that was actually proven. It does this in two stages:

1. Did an authentication mechanism pass? SPF verified the sending IP for the envelope domain, or DKIM verified a signature for the signing domain.
2. Does the domain that passed relate to the domain in the From: header? This is alignment.

A message achieves a DMARC pass when at least one mechanism satisfies both stages — SPF passes and is aligned, or DKIM passes and is aligned. One aligned pass is enough. Both mechanisms failing alignment means DMARC fails, no matter how green the individual results look.

This is worth stating plainly because it is the single most common misconception in the field:

An SPF pass does not mean DMARC passes. A DKIM pass does not mean DMARC passes. Authentication without alignment is authentication of somebody else’s domain.

What “Alignment” Means Technically

Alignment is a domain comparison, and DMARC lets you choose how strict that comparison is. You control it with two tags in your DMARC TXT record:

• aspf= — alignment mode for SPF
• adkim= — alignment mode for DKIM

Each accepts r (relaxed) or s (strict). If you omit them, both default to relaxed. A large number of production DMARC records are running relaxed alignment simply because nobody set the tags.

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; adkim=s; aspf=r;
  rua=mailto:dmarc-reports@example.com; fo=1"

That record enforces strict DKIM alignment and relaxed SPF alignment — a combination that is more common in mature deployments than you might expect, for reasons covered later.

Exact matching vs. organizational-domain matching

Strict alignment requires the two domains to be identical, character for character. example.com aligns strictly with example.com and with nothing else. Not mail.example.com, not example.co.uk, not notify.example.com.

Relaxed alignment requires the two domains to share the same organizational domain — the registrable domain sitting one label below a public suffix. Under relaxed alignment:

• mail.example.com aligns with example.com
• example.com aligns with bounces.mktg.example.com
• example.com does not align with example.net
• example.com does not align with example-secure.com

Here is the part that gets misrepresented constantly, so be precise about it:

Relaxed alignment does not mean “any subdomain is trusted.” It means both domains must reduce to the same organizational domain. It is a shared-parent test, not a wildcard. An attacker on an unrelated domain gains nothing from relaxed mode.

Organizational domains are determined by the Public Suffix List, which is why bbc.co.uk and news.bbc.co.uk share an organizational domain while bbc.co.uk and itv.co.uk do not — co.uk is a public suffix, not a registrable domain. The revised DMARC specification, commonly called DMARCbis, replaces the Public Suffix List with a live DNS tree walk to determine this boundary. The practical alignment logic described here is unchanged.

SPF Alignment

SPF authenticates the domain in the SMTP envelope — the MAIL FROM address, which recipients usually see surfaced as Return-Path:. SPF has no opinion whatsoever about the From: header.

SPF alignment therefore compares the RFC5322.From domain against the SPF-validated RFC5321.MailFrom domain. Consider a message with From: alerts@example.com:

Return-Path domain	SPF result	Relaxed aspf=r	Strict aspf=s
alerts@example.com	pass	Aligned	Aligned
bounce@mail.example.com	pass	Aligned	Not aligned
bounce-7f2a@relay.contoso.example	pass	Not aligned	Not aligned
alerts@example.com	fail	Not applicable	Not applicable

Row three is the spoofing scenario, and row two is the reason strict SPF alignment breaks so much legitimate mail. Bulk senders, ticketing systems, CRM platforms and marketing tools almost universally use a dedicated bounce subdomain so that non-delivery reports route back to their infrastructure. Under relaxed alignment that works perfectly. Under strict, it fails.

One footnote for completeness: when a message has a null envelope sender (bounce messages and delivery status notifications), SPF is evaluated against the HELO/EHLO identity instead. DMARC does not use that HELO result for alignment, which is one reason DKIM is the more reliable of the two mechanisms.

DKIM Alignment

DKIM authenticates the domain named in the d= tag of the signature header. That domain is chosen by whoever generated the signature, and it does not have to match the From: header either.

DKIM alignment compares the RFC5322.From domain against the d= domain of a verified signature. Same message, From: alerts@example.com:

DKIM d= domain	DKIM result	Relaxed adkim=r	Strict adkim=s
example.com	pass	Aligned	Aligned
notify.example.com	pass	Aligned	Not aligned
example.com	fail (body modified)	Not applicable	Not applicable
esp.fabrikam.example	pass	Not aligned	Not aligned

A message can carry several DKIM signatures. DMARC only needs one of them to both verify and align, so a vendor’s own signature sitting alongside your aligned one does no harm.

DKIM alignment also has an operational advantage that matters enormously in practice: DKIM survives forwarding, SPF usually does not. When a recipient auto-forwards mail to another mailbox, the forwarding server becomes the new connecting IP and SPF for your domain fails. The DKIM signature travels with the message and keeps verifying, as long as the forwarder doesn’t rewrite the body or protected headers. For that reason, aligned DKIM should be treated as your primary path to a DMARC pass, with aligned SPF as reinforcement.

Strict vs. Relaxed Alignment Side by Side

Area	Strict alignment (s)	Relaxed alignment (r)
Domain matching	The authenticated domain must be an exact, character-for-character match of the From: domain. mail.example.com does not satisfy a From: of example.com.	The authenticated domain and the From: domain must resolve to the same organizational domain. Subdomains of the same registrable domain satisfy each other; unrelated domains never do.
Security posture	Marginally tighter. Removes any scenario where a subdomain — including one delegated to a vendor, or one compromised through a stale DNS record — can produce mail that authenticates for the parent domain.	Strong against external spoofing, which is the overwhelming majority of the threat. Its residual exposure is internal: anyone who controls any subdomain of your organizational domain can generate aligned mail for it.
Subdomain flexibility	None. Every sending source must authenticate under the precise domain in the From: header. Separate subdomains require their own DMARC and DKIM configuration.	High. You can segment mail streams (billing.example.com, notify.example.com) while continuing to send From: example.com, or vice versa.
Third-party services	Frequently incompatible without deliberate work. Most SaaS platforms use vendor bounce subdomains and vendor-scoped signing domains; making them match exactly requires custom Return-Path and custom DKIM configured to the precise From: domain, which not every vendor supports.	Broadly compatible. Vendor-supplied CNAME setups for custom Return-Path and DKIM land on a subdomain of your domain, which is exactly what relaxed alignment accommodates.
Deployment complexity	High. Every sending platform must be inventoried, tested and often reconfigured. Any new vendor onboarded later can fail silently until reports surface it.	Low to moderate. Standard vendor onboarding procedures generally produce alignment without special negotiation.
Best-fit environments	Organizations with a small, well-known set of senders; a mature DMARC deployment already at p=reject; high-value transactional domains; regulated sectors; dedicated single-purpose domains.	Nearly all general-purpose corporate domains, any environment with multiple SaaS senders, subdomain-segmented mail architectures, and every organization still building visibility into its sending sources.

Walking Through Real Messages

Abstract rules become obvious once you trace actual messages. In every example below, the visible header is From: alerts@example.com and the DMARC record is on example.com.

Scenario 1 — Subdomain bounce address, no aligned signature

Return-Path bounce@mail.example.com, SPF pass. DKIM signature d=fabrikam.example, pass.

Relaxed SPF: aligned, so DMARC passes. Strict SPF: not aligned, and DKIM was never aligned in either mode, so DMARC fails. This is the classic case that breaks when someone switches on aspf=s without an inventory.

Scenario 2 — Vendor envelope, aligned signature

Return-Path bounces-9f31@esp.contoso.example, SPF pass for the vendor. DKIM d=example.com, pass.

SPF is not aligned in either mode — irrelevant. DKIM is aligned strictly and relaxed, so DMARC passes in both modes. One aligned mechanism is all it takes, which is why properly configured custom DKIM is the most durable investment you can make.

Scenario 3 — Segmented marketing stream

Return-Path bounce@mktg.example.com (SPF pass), DKIM d=mktg.example.com (pass).

Relaxed on both: pass. Strict on both: fail on both mechanisms, because neither domain exactly equals example.com. The fix under strict is to move the From: header to mktg.example.com so the identifiers match exactly — which is a legitimate architecture, just a deliberate one.

Scenario 4 — Mail forwarded by a recipient

The message leaves your infrastructure aligned, then a recipient’s mailbox rule forwards it onward. SPF now fails against the forwarder’s IP. The DKIM signature d=example.com still verifies.

DMARC passes on the strength of aligned DKIM alone. Without an aligned signature, this message would have been rejected at the second hop despite being entirely legitimate.

Scenario 5 — The spoof

An attacker sends from their own infrastructure. Return-Path noreply@examp1e-billing.example, with a valid SPF record and a valid DKIM signature for that attacker-controlled domain. Both mechanisms pass. From: still reads alerts@example.com.

Neither identifier shares an organizational domain with example.com. DMARC fails in both relaxed and strict mode, and with p=reject the message is refused. Note carefully: relaxed alignment stopped this. Alignment mode was never the control that blocked the attack — the alignment requirement itself was.

Why a Legitimate Email Can Still Fail DMARC

Alignment failures rarely announce themselves. Mail quietly lands in junk, or vanishes, and the first signal is a business unit complaining that invoices aren’t arriving. Here is a workflow that resolves the majority of cases.

Step 1 — Get a raw copy of a failing message

Ask for the original message with full headers, or pull it from message trace. Paraphrased screenshots will not do; you need the header block verbatim.

Step 2 — Read the Authentication-Results header

This header is where the receiving system records its verdict. A typical Microsoft 365 example:

Authentication-Results: spf=pass (sender IP is 203.0.113.24)
 smtp.mailfrom=bounce.example.com; dkim=pass (signature was verified)
 header.d=notify.example.com; dmarc=fail action=quarantine
 header.from=example.com; compauth=pass reason=100

Everything you need is in there. Line up three fields:

• header.from= → example.com (the domain being protected)
• smtp.mailfrom= → bounce.example.com (what SPF authenticated)
• header.d= → notify.example.com (what DKIM authenticated)

Both mechanisms passed. Both are subdomains. dmarc=fail therefore tells you immediately that this domain is running strict alignment on both tags — because under relaxed, this message would have passed twice over.

Step 3 — Confirm the published policy

nslookup -type=TXT _dmarc.example.com

Check aspf and adkim. Remember that an absent tag means relaxed. If the record shows adkim=s; aspf=s, you have confirmed the cause in under a minute.

Step 4 — Isolate which mechanism should be carrying the message

Decide which one ought to align for this sending source, then verify the underlying configuration:

• If DKIM should align: check the vendor’s signing configuration and confirm the selector CNAMEs resolve. In Microsoft 365 specifically, a domain without custom DKIM enabled signs as d=yourtenant.onmicrosoft.com, which never aligns with yourdomain.com in any mode. That single default is behind a very large share of DKIM alignment failures — one of several reasons Microsoft 365 is secure by default but not by configuration.
• If SPF should align: check whether the platform is using a custom Return-Path. Many vendors leave it on their shared bounce domain until you explicitly configure it.

Step 5 — Cross-check against aggregate reports

Your rua= reports show every source claiming your domain, with per-source SPF and DKIM results and the corresponding alignment outcomes. Do not read raw XML by hand at volume — use a DMARC reporting platform. What you’re looking for is the pattern: does this source never align, or did it start failing on a specific date? A sudden change usually means a vendor rotated infrastructure or a DNS record was overwritten.

Step 6 — Fix at the source, not at the policy

The tempting shortcut is loosening the DMARC record. Resist it. Correct the sending platform’s DKIM or Return-Path configuration so the message aligns properly. Weakening policy to accommodate one misconfigured vendor degrades protection for every other stream on the domain.

How Third-Party Platforms Change the Picture

Almost every organization sends mail from systems it does not run: marketing automation, help desks, e-signature services, HR and payroll portals, monitoring and alerting tools, invoicing systems, appointment reminders. Each one is an alignment decision.

By default, these platforms authenticate as themselves. Their bounce handling uses their domain and their DKIM keys carry their d=. Mail leaves with your brand in the From: header and none of your domains proven — a guaranteed DMARC failure.

The remedy is the same everywhere, even when the vendor’s documentation names it differently:

1. Custom Return-Path / custom bounce domain. You publish a CNAME such as bounce.example.com pointing into the vendor’s infrastructure, and they use it as the envelope sender. SPF then authenticates a domain under your organizational domain.
2. Custom DKIM signing. You publish selector CNAMEs (typically sel1._domainkey.example.com and sel2._domainkey.example.com) and the vendor signs with d=example.com or a subdomain of it.

Note what both fixes produce: a subdomain. That is fine under relaxed alignment and fails under strict. If your domain runs aspf=s, a vendor bounce domain of bounce.example.com will not align — you would need the vendor to use example.com itself as the envelope domain, which many platforms cannot do.

This is precisely why the mixed configuration adkim=s; aspf=r shows up in mature deployments. It tightens the mechanism you fully control (your own signing domains) while leaving room for the envelope behaviour that third parties impose on you.

Subdomains Deserve Their Own Plan

Subdomains interact with alignment in two ways that catch people out.

First, policy inheritance. A DMARC record on example.com applies to subdomains that have no record of their own. You can override this with the sp= tag — for example p=reject; sp=quarantine while a subdomain’s senders are still being cleaned up. Publishing a DMARC record directly on a subdomain overrides the parent entirely for that subdomain, including its own alignment tags.

Second, the honest security trade-off in relaxed mode. Because relaxed alignment accepts any subdomain of your organizational domain, whoever controls a subdomain can produce mail that aligns for the parent. If you have delegated status.example.com to a SaaS vendor, or you have dangling CNAMEs pointing at decommissioned cloud resources, that delegation carries alignment authority with it.

This is a real consideration, not a theoretical one — but keep it proportionate. It requires the attacker to already control DNS or infrastructure inside your domain. If that is true, alignment mode is not your most urgent problem. Subdomain takeover hygiene, DNS record auditing and tight delegation controls address this risk far more effectively than switching a one-character tag.

The constructive approach is architectural: give distinct mail streams their own subdomains (notify.example.com for transactional, bulletin.example.com for marketing), publish DMARC and DKIM on each, and keep reputational damage from bulk mail away from your corporate domain.

Choosing Between Strict and Relaxed

Alignment mode is an environment-specific decision, and any guidance that declares strict the superior choice across the board is selling certainty rather than describing reality. Weigh these factors:

• Email architecture. A single Microsoft 365 tenant with two vendors is a very different problem from a decentralized estate where regional offices onboard their own SaaS tools.
• Number of legitimate sending platforms. Every additional platform multiplies the effort of maintaining exact matching.
• Use of subdomains. If your mail is deliberately segmented across subdomains while the From: header stays on the parent domain, strict alignment is architecturally incompatible with your design until you change the From: headers too.
• Third-party capability. Some vendors cannot sign with an arbitrary exact domain. Check before committing.
• Security requirements. Regulated sectors and high-value transactional domains have a stronger case for exactness.
• DMARC maturity. Strict alignment on a domain still at p=none provides no security benefit at all — nothing is being enforced. Get to enforcement first.
• Visibility. If you cannot confidently name every system that sends as your domain, you are not ready to tighten alignment. Reporting comes before restriction.

A practical default: relaxed alignment on both tags for general-purpose corporate domains, combined with p=reject. Enforcement is what stops spoofing; alignment mode is a refinement on top of it.

Where strict earns its place: dedicated single-purpose domains where you control the entire pipeline. A domain used exclusively for transactional notifications, sent from infrastructure you operate, with no third parties in the path, is an excellent candidate for adkim=s; aspf=s.

A Rollout That Won’t Break Mail Flow

For an organization new to DMARC, alignment is not the first decision — it is roughly the fifth.

1. Publish p=none with rua=. Change nothing else. You are buying visibility, not protection.
2. Collect four to six weeks of aggregate reports. Build a definitive inventory of every source sending as your domain, and note which ones align and how.
3. Fix each source. Configure custom DKIM and custom Return-Path everywhere the platform supports it. Retire shadow IT senders. Target aligned DKIM on every legitimate stream.
4. Move to p=quarantine, ramped. Use pct= to phase in — 25%, then 50%, then 100% — watching reports at each step.
5. Move to p=reject. Only when reports show no legitimate source failing.
6. Then, and only then, consider alignment mode. Treat tightening as a separate change with its own validation window.

For organizations already at p=reject with clean reporting, tightening alignment is a controlled exercise:

• Tighten one tag at a time. adkim=s first, because your own signing domains are the identifiers you control most directly.
• Before publishing, query your reports for any legitimate source whose d= is a subdomain rather than an exact match. Those are the streams that will break.
• Publish the change, then monitor aggregate reports closely for at least two full reporting cycles before touching aspf.
• Add fo=1 to receive failure reports for messages that fail either mechanism, giving you faster signal than aggregate data alone.
• Have the rollback ready. Reverting a tag is a single DNS edit; the damage done by a week of silently rejected invoices is not so easily undone.

Configuration Mistakes That Cause Real Outages

• Enabling strict alignment during initial deployment. Alignment mode is a refinement for mature deployments. Tightening it before you have full source visibility converts an unknown into an outage.
• Assuming an SPF pass equals DMARC protection. It is entirely possible to hold a perfect SPF record, see spf=pass on every message, and provide zero anti-spoofing value because the envelope domain never aligns.
• Leaving Microsoft 365 default DKIM in place. Signing as tenant.onmicrosoft.com never aligns with your public domain. If SPF alignment is then lost to forwarding, the message fails DMARC completely.
• Publishing more than one DMARC record. Two TXT records at _dmarc.example.com is a permanent error condition — receivers treat the policy as undefined. The same applies to malformed tags and stray whitespace.
• Putting the record in the wrong place. DMARC lives at _dmarc.yourdomain.com, not at the domain apex. An apex TXT record starting v=DMARC1 does nothing.
• Forgetting subdomain policy. p=reject covers subdomains by default. Administrators who publish reject on the parent and then discover an application sending from app.example.com learn this at the worst possible moment. Plan sp= deliberately.
• Confusing the two alignment tags. aspf and adkim are independent. Setting one does not affect the other, and a mixed configuration is a legitimate, often optimal, choice.
• Treating DMARC as fire-and-forget. Vendors change infrastructure. Business units buy new tools. Without ongoing report monitoring, alignment failures accumulate invisibly until something important stops being delivered.

Final Recommendations

Alignment is where DMARC stops being a checkbox and becomes an actual control. The mechanics reduce to a handful of durable points:

• DMARC protects the domain your recipients see — the RFC5322.From header — and nothing else.
• SPF authenticates the envelope domain. DKIM authenticates the d= signing domain. Neither is bound to the From: header without DMARC.
• DMARC passes when at least one mechanism both authenticates and aligns. One aligned pass suffices; two unaligned passes are worth nothing.
• Relaxed alignment requires a shared organizational domain. Strict requires an exact match. Relaxed is the default when the tags are absent, and it is not a wildcard for arbitrary subdomains — it is a shared-parent test.
• Prioritize aligned DKIM on every sending platform. It survives forwarding, it is fully within your control, and it is the most reliable route to a DMARC pass.
• Reach p=reject under relaxed alignment before you consider tightening. Enforcement delivers the security outcome; alignment mode refines it.
• Reserve strict alignment for domains where you control the entire sending path, and change one tag at a time with reporting in place.

Get to enforcement, keep visibility, and treat every new sending platform as an alignment decision at onboarding rather than an incident later.

If you would like help building that inventory or moving a domain safely to enforcement, our managed security services cover email authentication as part of ongoing operations, and you can talk to our team about a review of your current DMARC posture.

Frequently Asked Questions

What does DMARC alignment mean?

Alignment is DMARC’s requirement that authentication must belong to the domain shown in the visible From: header. SPF proves a domain in the SMTP envelope and DKIM proves a domain in a signature — alignment is the check that ties one of those proven domains back to the one your recipients actually see. Without it, an attacker could authenticate their own domain perfectly while displaying yours.

What is the difference between strict and relaxed DMARC alignment?

Strict alignment (adkim=s, aspf=s) requires an exact domain match: example.com only aligns with example.com. Relaxed alignment (r, and the default when the tags are omitted) requires both domains to share the same organizational domain, so mail.example.com aligns with example.com. Relaxed does not trust arbitrary subdomains of unrelated domains — it only accepts domains under the same registrable parent.

Does SPF passing guarantee DMARC will pass?

No. SPF validates the Return-Path domain, which for most third-party platforms is the vendor’s own bounce domain. That produces spf=pass while the From: domain remains entirely unproven, and DMARC fails unless DKIM aligns instead. This is the most frequent misunderstanding in DMARC deployments.

Does DKIM passing guarantee DMARC will pass?

No. DKIM validates whatever domain appears in the signature’s d= tag. If a platform signs with its own domain, or if Microsoft 365 signs with the default tenant.onmicrosoft.com because custom DKIM was never enabled, the signature verifies but does not align — and DMARC fails.

Should an organization use strict or relaxed alignment?

For most corporate domains, relaxed alignment combined with p=reject is the right balance. Enforcement is what actually blocks spoofing; strict mode is a refinement that mainly closes internal subdomain exposure. Strict alignment fits dedicated single-purpose domains where you control every sending system and no third parties are involved.

Can third-party email services work with strict DMARC alignment?

Sometimes, but it requires deliberate effort. Most vendors implement custom Return-Path and custom DKIM using CNAMEs that land on a subdomain of your domain — which satisfies relaxed alignment but not strict. Achieving strict alignment usually means either finding a vendor that will sign with your exact From: domain, or moving that mail stream’s From: header onto the subdomain the vendor uses.

How can I troubleshoot a DMARC alignment failure?

Pull a failing message with full headers and compare three fields in Authentication-Results: header.from=, smtp.mailfrom=, and header.d=. If the mechanisms pass but DMARC fails, you have an alignment problem. Query _dmarc.yourdomain.com to confirm which mode is published, then fix the sending platform’s DKIM signing domain or Return-Path so the identifiers align. Use aggregate reports to confirm the fix and to catch whether the failure is chronic or newly introduced.

How long should we run p=none before enforcing?

Four to six weeks is typical — long enough to capture monthly billing runs, quarterly campaigns and other periodic senders. Time matters less than completeness: move forward when your reports account for every legitimate source, not when the calendar says so.