What Is DMARC Alignment? Relaxed vs Strict Explained

DMARC alignment is the check that decides whether a passing SPF or DKIM result actually counts. It is the piece most guides skip, and it is the reason an email can pass SPF and still fail DMARC.

If you have ever seen a DMARC failure on mail that authenticated fine, alignment is almost always why. This guide explains what DMARC alignment is, how relaxed and strict modes differ, and which one to use.

What DMARC alignment actually checks#

SPF and DKIM each prove that some domain is responsible for a message. DMARC adds one more rule: the domain they proved has to line up with the domain a person reads in the From address. That lining-up is alignment.

Without it, a sender could pass SPF on a domain they own and still put your bank in the From line. DMARC passes when at least one of SPF or DKIM both passes and aligns. It fails when neither is aligned, even if the authentication itself succeeded.

Alignment comes in two strengths, relaxed and strict, and you set them separately for SPF and DKIM. The short version: almost every domain should use relaxed, which is the default. Strict is a niche, higher-maintenance choice, and the rest of this guide shows when it is worth it.

How DMARC uses the visible From domain#

The address a recipient reads is the RFC5322.From header, the From your mail app shows. DMARC exists to protect that exact identity, because it is the one humans trust and attackers forge.

On their own, SPF and DKIM never look at that header. SPF checks the envelope sender, the Return-Path, technically the RFC5321.MailFrom. DKIM checks whatever domain signed the message, the d= value. Either can pass for a domain that has nothing to do with what the reader sees.

This split is deliberate: the envelope and the signature are plumbing that intermediaries touch, while the From header is the label a person acts on. A well-configured spammer can own a domain, publish a valid SPF record for it, and pass SPF cleanly, all while forging a bank in the From line.

Alignment is DMARC's bridge between those under-the-hood identifiers and the visible From. It asks one question: is the domain that authenticated the same as, or part of the same organization as, the From domain? If yes, the authentication counts for DMARC. If no, it is ignored.

Relaxed vs strict alignment at a glance#

Both SPF and DKIM alignment can run in relaxed mode or strict mode, and you set them independently. Here is the difference side by side.

What aspf and adkim mean#

You control alignment with two optional tags in your DMARC DNS record. aspf sets the alignment mode for SPF; adkim sets it for DKIM. Each takes a single letter: r for relaxed, s for strict.

Both default to relaxed. A record with no aspf or adkim tag is running relaxed alignment on both mechanisms, which is what most domains want and never need to change. RFC 9989, the current DMARC standard, states the default is r for each.

DKIM alignment vs SPF alignment#

Alignment is worked out separately for each mechanism, and the two behave differently in practice.

SPF alignment compares the envelope-sender domain (RFC5321.MailFrom) with the From domain. Because the envelope sender is often set by whoever relays the mail, an ESP, a mailing list, or a forwarder, SPF alignment is the more fragile of the two.

DKIM alignment compares the signing domain (d=) of a valid signature with the From domain. A message can carry more than one DKIM signature, and DMARC passes if any valid one aligns. Because the signature travels inside the message, DKIM alignment survives forwarding that would break SPF.

For DMARC you need only one of them aligned and passing. In real deployments, aligned DKIM is what most senders lean on, and it is the half to get right first.

Why your email passes SPF but fails DMARC#

This is the most common alignment surprise. Your mail passes SPF, the logs look healthy, and DMARC still reports a failure. The cause is almost always that SPF passed for a domain that is not aligned with your From.

It happens when you send through a service that uses its own domain as the envelope sender. SPF checks that service's domain and passes. But that domain is not your From domain, so SPF alignment fails. If you also have not set up DKIM signing under your own domain, there is nothing aligned to fall back on, and DMARC fails.

The fix is not to touch SPF. It is to add DKIM signing under your own domain, usually a CNAME your provider hands you, so an aligned DKIM signature carries DMARC even when the envelope sender does not.

How to fix a pass-SPF, fail-DMARC message#

The fix is almost always about DKIM, not SPF. Work through it in order so you change one thing at a time and can see the effect in your reports.

1. 1

   Confirm which identifier failed alignment

   Read the Authentication-Results header on a received copy, or a DMARC aggregate report. It tells you the SPF and DKIM domains and whether each aligned with your From.

2. 2

   Set up DKIM under your own domain

   Add the CNAME or TXT records your sending provider gives you so it signs with a d= value inside your organizational domain, not its own.

3. 3

   Send a test and re-check

   Confirm the d= domain now matches your From and that DMARC reports a pass. An aligned DKIM signature carries DMARC even when SPF alignment does not.

4. 4

   Only then tighten the policy

   Once reports show every legitimate source aligning, move from p=none toward quarantine or reject. Never tighten before the data is clean.

Organizational domain alignment, explained#

Relaxed alignment rests on one idea: the organizational domain. Two names are in relaxed alignment when they share the same organizational domain, even if they are not identical. So mail.acme.com and news.acme.com both align with a From of acme.com.

The hard part is deciding where the organizational boundary sits. Is co.uk an organization? Is acme.co.uk? For years the answer came from the Public Suffix List, a manually maintained file of these boundaries.

RFC 9989 (2026), the current DMARC standard, changes that. It obsoletes RFC 7489 and RFC 9091, drops the Public Suffix List in favor of a bounded DNS tree walk that discovers the boundary by querying DNS itself, and adds a psd tag for public-suffix operators. It also removes the old pct tag.

Where relaxed alignment wins#

Relaxed alignment is the pragmatic default because real sending is messy. Companies send from subdomains, mail.acme.com for marketing, notify.acme.com for receipts, and route through providers that add their own.

Under relaxed alignment, all of those align with a From of acme.com as long as they share the organizational domain. You get anti-spoofing protection on the visible domain without breaking every legitimate subdomain stream.

• Subdomain sending (mail., news., notify.) aligns with the parent From domain
• Most provider and transactional setups align once DKIM is signed under your domain
• Fewer false DMARC failures on mail you genuinely sent
• It is the default, so there is nothing to configure

Where strict alignment wins#

Strict alignment requires an exact match: the authenticated domain must be identical to the From domain, character for character. A subdomain no longer counts.

That is the whole point of it. If your domain sends only from itself, and you want to guarantee that no subdomain, including one delegated to a third party, can produce mail that aligns with your exact From, strict closes that door.

• A single, locked-down sending domain with no subdomain streams
• You want delegated or third-party subdomains excluded from alignment
• You have DMARC reporting in place to catch anything strict breaks

Which alignment mode should you use?#

For almost everyone, the answer is relaxed, which means doing nothing, since it is the default. It protects the From domain against spoofing while tolerating the normal complexity of subdomains and providers.

Choose strict only for a specific, narrow reason: a single exact sending domain, delegated subdomains you want excluded, and monitoring to catch breakage. If you cannot name that reason, relaxed is the right call. Alignment mode is also independent of policy strength, so you can run relaxed alignment with p=reject and still get firm anti-spoofing; strict is not a prerequisite for a tough policy.

Whichever you pick, the order is the same. Publish a DMARC record at p=none with reporting first, read the aggregate reports until you can see every legitimate source aligning, and only then tighten the policy. Alignment is something you verify from real data, not something you assume, and it is worth re-checking whenever you add a new sending service.

Where AI Emaily fits, and where it does not#

One honest boundary first: AI Emaily is a mail client, not a DMARC service. It does not publish or edit your DNS record, does not read your aggregate reports, and cannot change your domain's alignment mode. To set relaxed or strict alignment, or to monitor it, you use your DNS host and a DMARC report analyzer built for that job.

What it does do is on the receiving end. Alignment exists to expose a message whose authenticated domain does not match its From, which is the exact shape of a spoof. AI Emaily's spam and phishing protection parses the SPF, DKIM and DMARC result of every inbound message and weighs it as one signal among many, so that pattern gets caught before the mail reaches you. Clear-cut messages are handled by a deterministic scorer; only genuinely borderline ones get an AI second opinion. We build AI Emaily.