Reference

DMARC alignment: how SPF and DKIM align, with worked examples

What DMARC alignment compares, relaxed vs strict, how RFC 9989 finds the Organizational Domain, and six worked SPF and DKIM examples.

By Updated Last verified

On this page
  1. What alignment compares
  2. Relaxed and strict alignment
  3. How the Organizational Domain is found
  4. The walk
  5. Which domain it picks
  6. Worked examples
  7. Case 2: DKIM signed with mail.example.com
  8. Case 3: a sending service's own domains
  9. Case 4: SPF on a bounce subdomain
  10. Case 5: a forwarded message
  11. Cases 1 and 6: identical domains
  12. When strict alignment is worth it
  13. Check your alignment
  14. Sources

DMARC alignment means a domain that SPF or DKIM authenticated has to match the domain in the message's From header (opens in a new tab): the MAIL FROM domain for SPF, the d= domain of the signature for DKIM (RFC 9989 section 4.4 (opens in a new tab)). Relaxed alignment accepts two domains that share the same Organizational Domain; strict alignment accepts only identical domains (section 3.2.10 (opens in a new tab)). One aligned pass, from either SPF or DKIM, is enough for DMARC to pass (section 5.3.5 (opens in a new tab)).

What alignment compares

RFC 9989 (opens in a new tab), which obsoletes RFC 7489, defines DMARC (Domain-based Message Authentication, Reporting, and Conformance). Every alignment check compares one domain on each side:

A pass on its own is not enough: DMARC requires alignment between the From domain and an authenticated domain for a DMARC pass (section 3.2.10 (opens in a new tab)). Any domain owner can publish an SPF record for its own domain and get an SPF pass, and a message can carry a valid DKIM signature from any domain (section 4.4 (opens in a new tab)). A message can carry several DKIM signatures, and any one aligned signature produces a DMARC pass. For how SPF, DKIM and DMARC fit together in general, see SPF, DKIM and DMARC.

Check your domain now

See the SPF, DKIM and DMARC records your domain publishes and what to fix first. Free, no account needed.

Create a free account

Relaxed and strict alignment

RFC 9989 defines two alignment states (section 3.2.10 (opens in a new tab)):

  • Relaxed. The From domain and the authenticated domain have the same Organizational Domain.
  • Strict. The From domain and the authenticated domain are identical. news.example.com aligns strictly only with news.example.com.

DemiSignal's DMARC record generator puts it in practical terms: relaxed accepts a subdomain of your domain, for example mail.example.com for example.com, and strict requires an exact match.

The domain owner picks the mode in its DMARC record, and in practice nearly all domain owners have found relaxed alignment sufficient (section 4.4 (opens in a new tab)). Two optional tags set it, separately for each check: adkim for DKIM and aspf for SPF, each r for relaxed or s for strict, and both default to r (section 4.7 (opens in a new tab)).

So a record without either tag already uses relaxed alignment for both:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Strict alignment for both checks adds the two tags:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s

The generator offers that choice separately for DKIM (adkim=s) and SPF (aspf=s). The other tags are covered in DMARC record tags.

How the Organizational Domain is found

Relaxed alignment (opens in a new tab) compares Organizational Domains, so it depends on knowing each domain's Organizational Domain: the domain at the top of the namespace hierarchy that still has the same administrative authority (RFC 9989 section 3.2.14 (opens in a new tab)).

RFC 7489 discussed using a Public Suffix List (PSL) as the list of parent domains for Organizational Domains, and acknowledged that receivers choosing different lists could cause interoperability issues (RFC 9989 section 4.10 (opens in a new tab)). RFC 9989 replaces the list with a discovery technique known as the "DNS Tree Walk" (appendix C.3 (opens in a new tab)). What RFC 9989 changed covers the rest of the update.

The walk

Policy discovery starts with a query for a DMARC record at the name made by putting _dmarc in front of the From domain. A walk then removes the left-most label and queries again, one label at a time, until it stops or no labels remain. If one name returns several DMARC records, they are all discarded. The walk is capped: a domain with more than eight labels does not result in more than eight DNS queries.

Starting from a.mail.example.com, a search for the Organizational Domain queries _dmarc.a.mail.example.com, then _dmarc.mail.example.com, then _dmarc.example.com, and finally the top-level domain.

Which domain it picks

The psd tag flags public suffix domains (PSDs) (section 4.7 (opens in a new tab)), domains that allow independent organizations to register subdomains under them (section 3.2.15 (opens in a new tab)). Their operators set it to y; n marks a domain that is not a PSD but is the Organizational Domain for itself and its subdomains.

From the names where the walk found a valid DMARC record, longest first:

  1. A record with the psd tag set to n marks its own domain as the Organizational Domain.
  2. A record with the psd tag set to y, other than the one where the walk started: the Organizational Domain is the domain one label below it.
  3. Otherwise, the record at the name with the fewest labels marks the Organizational Domain.

If this process does not determine one, the domain the walk started from is the Organizational Domain.

The standard's own example: if DMARC records exist at _dmarc.mail.example.com and _dmarc.example.com, but not at _dmarc.a.mail.example.com or at the top-level domain, the Organizational Domain of a.mail.example.com is example.com. If the record at _dmarc.mail.example.com carries the psd tag set to n, it is mail.example.com instead. In the first case, the record at _dmarc.mail.example.com does not make mail.example.com an Organizational Domain.

With strict alignment, the check is a simple string comparison of the From domain and the authenticated domain. When the From domain and every authenticated domain are the same domain with its own DMARC record, that domain is treated as the Organizational Domain.

A receiver whose DMARC implementation follows RFC 7489 and relies on a Public Suffix List might arrive at a different answer than the Tree Walk. RFC 9989 notes that strict alignment, plus an explicit DMARC record for every From domain you use, avoids that issue entirely.

Worked examples

Each case below assumes a single DMARC record at _dmarc.example.com, so the Tree Walk gives example.com as the Organizational Domain for example.com and its subdomains (RFC 9989 section 4.10 (opens in a new tab)). SPF alignment exists only when SPF passes, and DKIM alignment only when the signature validates (appendix B.1 (opens in a new tab)). The relaxed and strict definitions come from section 3.2.10 (opens in a new tab), and one aligned identifier is enough for a pass while none means a fail (section 5.3.5 (opens in a new tab)).

Case From domain SPF pass for MAIL FROM Valid DKIM d= Relaxed result Strict result
1. Your own server example.com example.com example.com Pass: both identical Pass: both identical
2. DKIM on a subdomain example.com none mail.example.com Pass: same Organizational Domain Fail: mail.example.com is not identical to example.com
3. Service defaults example.com bounces.example.net example.net Fail: different Organizational Domain Fail
4. Bounce subdomain example.com bounce.example.com none Pass: same Organizational Domain Fail: not identical
5. Forwarded message example.com fails at the final mailbox example.com Pass on DKIM Pass on DKIM
6. One of two aligns example.com example.com example.net Pass on SPF Pass on SPF

Case 2: DKIM signed with mail.example.com

mail.example.com and example.com have the same Organizational Domain, example.com, so the signature is in relaxed alignment with the From domain. With adkim=s, strict DKIM alignment (section 4.7 (opens in a new tab)), it fails, because the two are not identical, and with no aligned SPF either, the message fails DMARC.

Case 3: a sending service's own domains

Here a sending service signs with its own domain and uses its own bounce domain. The DKIM d= domain, example.net, is neither the same as, a parent of, nor a child of example.com, so it is not in alignment, and the same holds for the MAIL FROM domain bounces.example.net. SPF and DKIM can both pass while DMARC fails. DMARC fail covers reading this in a message header and fixing it at the service.

Case 4: SPF on a bounce subdomain

The standard's own SPF example has the From domain example.com as the parent of the MAIL FROM domain, and calls the two relaxed-aligned because they share the Organizational Domain example.com. bounce.example.com works the same way. With aspf=s, strict SPF alignment, it fails, because strict alignment requires identical domains.

Case 5: a forwarded message

When an alias or forwarding address relays a message, it will most likely fail SPF at the final mailbox, unless the relaying server rewrites the MAIL FROM, because the forwarder's IP address is not one the original MAIL FROM domain authorized (RFC 9989 section 7.4 (opens in a new tab)). DKIM signatures will generally remain valid in these relay situations, so an aligned d=example.com signature can still carry the DMARC pass. Domains that publish p=reject must not rely on SPF alone and must apply valid DKIM signatures. If a signature stops verifying, DKIM fail covers the reasons.

Cases 1 and 6: identical domains

When the MAIL FROM domain and the From domain are identical, they are in strict alignment, and so are a DKIM d= domain and a From domain that are identical. Identical domains also share an Organizational Domain, so case 1 passes in either mode. In case 6, only SPF aligns, and one aligned identifier is enough for a pass; that pass rests on SPF alone, which case 5 shows can break when the message is forwarded.

When strict alignment is worth it

If someone else can control the SPF record or the DKIM selector records of a subdomain under your Organizational Domain, that subdomain can produce a DMARC pass for mail from your main domain (RFC 9989 section 11.8 (opens in a new tab)). The standard's advice is to avoid delegating control of subdomains if this matters to you, and to consider strict alignment where it fits. Strict alignment, together with an explicit DMARC record for every domain you send from, avoids the issue entirely.

Google (opens in a new tab) suggests considering strict alignment when mail is sent for your domain from a subdomain outside your control, or when another entity manages some of your subdomains. It also notes that relaxed alignment typically provides sufficient spoofing protection, and that strict alignment can send mail from your own subdomains to spam or rejection. Strict alignment needs the authenticated domain to be identical to the From domain (RFC 9989 section 3.2.10 (opens in a new tab)), so before switching to s, check that every service that sends as your domain uses that exact domain in its MAIL FROM or its DKIM d= value.

Check your alignment

Paste a DMARC aggregate report into DemiSignal's DMARC report analyzer to read it as a table: which sources sent email as your domain, how many messages, whether SPF and DKIM aligned, and what the receiver did. The report is parsed in your browser and never sent to DemiSignal.

The DMARC record generator builds a record one step at a time, starting with monitoring, with the alignment choice for DKIM and SPF, and saves nothing you enter. DemiSignal's free check reads the public DNS records of the domain you enter, with no account needed. A DNS finding shows how your domain is set up; it does not show where a particular message landed.

Sources

Tools for this

Frequently asked questions

What is DMARC alignment?

It is the match DMARC requires between the domain in the From header and a domain that SPF or DKIM authenticated: the MAIL FROM domain that passed SPF, or the d= domain of a DKIM signature that validated. Without at least one aligned identifier, the message fails DMARC.

What is the difference between relaxed and strict alignment?

Relaxed alignment needs the two domains to share the same Organizational Domain, so mail.example.com aligns with example.com. Strict alignment needs them to be identical. Both adkim and aspf default to relaxed.

Do both SPF and DKIM have to align for DMARC to pass?

No. If one or more authenticated identifiers align with the From domain, the message passes DMARC. It fails only when none of them aligns.

Check your domain now

See the SPF, DKIM and DMARC records your domain publishes and what to fix first. Free, no account needed.

Create a free account