DMARC alignment: relaxed vs strict, and what adkim and aspf do

SPF and DKIM can both pass on a message and DMARC can still fail. The missing piece is alignment: the domain they authenticated has to match the domain in the From address your recipients see. Two tags, adkim and aspf, decide how close that match must be.

What is DMARC alignment?

DMARC protects the From header, the address people see. SPF and DKIM don't look at it at all:

• SPF authenticates the envelope sender, also called MAIL FROM or Return-Path.
• DKIM authenticates the domain in the signature's d= tag.

An attacker can pass both for their own domain while putting yours in From. RFC 9989, section 4.4.1 puts it plainly: "a message can bear a valid signature from any domain, even one used by a bad actor." Section 4.4.2 says the same of SPF: anyone "can publish an SPF record for its domain and send an email that will obtain an SPF 'pass' result."

So DMARC adds a rule: at least one of those authenticated domains must align with the From domain. Section 4.4.1 adds that a message with several DKIM signatures passes if any one of them aligns. If you need the basics first, read SPF vs DKIM vs DMARC.

Relaxed vs strict: what's the difference?

Section 4.4 defines the two modes:

• Relaxed (r, the default): the authenticated domain and the From domain have the same organizational domain.
• Strict (s): the two domains are identical.

You set them separately in your DMARC record:

A record with strict SPF alignment and relaxed DKIM alignment looks like this:

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; aspf=s; adkim=r; rua=mailto:dmarc@example.com"

Comparisons ignore letter case, per section 4.4. Microsoft's DMARC guide adds a point people miss: "A message passes DMARC if either alignment check succeeds, so a strict failure on one check doesn't matter if the other check passes with relaxed alignment."

What is the organizational domain?

Relaxed alignment depends on the organizational domain, so it's worth knowing how receivers find it.

Under RFC 7489, receivers used a Public Suffix List: example.com was the organizational domain of mail.example.com because .com is a public suffix. RFC 9989 replaced the list with a DNS tree walk. The receiver looks up _dmarc records from the domain upward. Without a psd tag, the organizational domain is the name with the fewest labels that has a valid DMARC record.

For a business with a record at _dmarc.example.com, the answer is example.com either way. Two edge cases:

• A record with psd=n on a subdomain makes that subdomain its own organizational domain. mail.example.com and example.com would then not align under relaxed mode.
• If the tree walk finds no DMARC record at all for a From domain, section 4.10.1 says receivers must not apply DMARC to that mail, so alignment is moot.

Our subdomain policy guide and RFC 9989 changes guide cover the tree walk in more depth.

Alignment examples: what passes and what fails?

Each row assumes the SPF or DKIM check itself passed. RFC 9989 Appendix B.1 notes that alignment can't exist for a result that didn't pass.

Relaxed alignment works in both directions. Appendix B.1 gives examples where the authenticated domain is the parent of the From domain and where it's a child; both align in relaxed mode. Strict alignment only accepts an exact match.

The last three rows fail in every mode. They're the usual cause of DMARC failures, and changing adkim or aspf won't fix them. You need the service to sign with your domain or use your domain as its bounce address. Our guide to why DMARC fails walks through those fixes.

How sending platforms affect alignment

Most email platforms let you set up two things on your domain:

1. A custom DKIM domain, usually through CNAME or TXT records the platform gives you. This makes d= your domain. Our DKIM records by provider pages show what each service asks for, for example Amazon SES and SendGrid.
2. A custom return-path or MAIL FROM domain, which is usually a subdomain. Amazon SES, for example, requires that "the MAIL FROM domain has to be a subdomain of the parent domain of a verified identity."

That second point is why strict SPF alignment so often breaks things. With aspf=s, a bounce address at mail.example.com doesn't align with From example.com. DMARC can still pass through DKIM, but only if d= is exactly example.com when adkim=s.

When does strict alignment make sense?

Strict alignment closes a specific gap. RFC 9989, section 11.8 describes it: if someone gains control of the SPF record or DKIM keys of any subdomain, they can send mail that passes DMARC for your main domain. Its example is an attacker who controls DNS for evil.example.com, publishes SPF there, and sends as foo@example.com. Under relaxed alignment, that passes.

The RFC's advice is to be careful about delegating control of subdomains and to "consider using the strict alignment option if appropriate." Strict alignment fits when:

• You delegate subdomains to other teams, agencies or vendors who manage their own DNS, and you don't want their mistakes to pass DMARC for your main domain.
• Dangling DNS is a risk. Old subdomains that point at cloud services you no longer use can be taken over. Strict alignment limits what an attacker gains from one.
• You send everything yourself, from a small number of systems that sign with d=example.com and bounce from example.com.
• You want to avoid tree-walk differences. RFC 9989 Appendix C.3 says disagreements between receivers using the tree walk and those using a Public Suffix List are "entirely avoided" by strict alignment plus explicit DMARC records for every From domain.

For most small businesses, none of these apply strongly, and the cost is high: a single newsletter or help-desk tool that bounces from a subdomain starts failing. RFC 9989 section 4.4 notes that "nearly all Domain Owners have found relaxed alignment sufficient."

A good middle ground is adkim=s with aspf=r, if every service signs with your exact domain. DKIM is the identifier that survives forwarding, so that's where an exact match does the most good.

How do you check alignment and switch modes safely?

1. Look at real headers. Send a message from each service to an outside mailbox and open it in the Email Header Analyzer. In Authentication-Results, compare smtp.mailfrom (SPF), header.d or header.i (DKIM) and header.from.
2. Read your aggregate reports. Each row shows the From domain, the SPF and DKIM domains, and whether each aligned. The DMARC Report Analyzer turns the XML into a table, and our guide on how to read DMARC reports explains each field.
3. List every source that relies on a subdomain. Any row where DKIM d= or the SPF domain is a subdomain of yours will fail under strict mode for that identifier.
4. Fix those sources first. Ask each service to sign with your exact domain. If it can't, keep relaxed alignment.
5. Change one tag at a time. Add adkim=s first, watch reports for at least two weeks, then decide about aspf=s.
6. Roll back quickly if needed. Lower the TTL on your DMARC record before the change so that removing a tag takes effect fast.

Check the result with the DMARC Checker, which flags invalid adkim and aspf values.

What the big mailbox providers require

Bulk sender rules require alignment, not strict alignment. Google's sender guidelines say "the domain in the sender's From: header must be aligned with either the SPF domain or the DKIM domain," and suggest SPF and DKIM "aligned with each other at the organizational level." Relaxed alignment meets that. See our bulk sender requirements guide for the full list.

Next steps

• Check your record with the DMARC Checker. No adkim or aspf tag means relaxed, which is right for most domains.
• Confirm every service signs with your domain using the DKIM Checker.
• If you delegate subdomains, audit who controls their DNS and remove records that point at services you no longer use.
• Alignment protects how your domain looks in other people's inboxes. For mail arriving at yours, an inbound filter such as iBlockSpam checks spoofing and phishing before delivery; see how it works.

Browse our other SPF, DKIM and DMARC guides.