DMARC alignment

Alignment is the rule that makes DMARC useful. An SPF or DKIM pass only counts towards DMARC if the domain it authenticated matches the domain in the From: header. In relaxed mode (the default), "matches" means both domains belong to the same organizational domain, so mail.example.com aligns with example.com. In strict mode the two must be identical. DMARC passes when any one passing check is aligned.

The three domains in play

Every message carries up to three domains that matter here:

Alignment compares the second and third against the first. RFC 9989 §4.4.1 and §4.4.2 explain why: anyone can register a domain, publish SPF for it and sign with it, so a pass for some domain proves nothing about the sender you see.

Organizational domains

Relaxed alignment needs a notion of "the same organization". RFC 9989 §3.2.14 defines the organizational domain as the highest domain in the tree that is still under the same administrative control. For most mail that is the registered domain: example.com for a.b.mail.example.com. Under a country registry level such as .co.uk, it is the name one label below that level, not co.uk itself.

How it is found has changed:

• RFC 7489 §3.2 (2015) told receivers to use a public suffix list, in practice the community-maintained Public Suffix List, to know, for example, that co.uk is a registry level and the registered name sits one label below it.
• RFC 9989 §4.10 (2026) replaces the list with a DNS Tree Walk: the receiver queries for _dmarc records at the domain and at each parent, up to a fixed limit, and picks the organizational domain from which records exist and from an optional psd= flag (§4.10.2). Appendix C.3 notes the two methods can disagree for unusual setups.

Receivers have used the PSL method for about a decade, and some will keep using it for a while.

How the analyser does it: MailDingo runs entirely in your browser and cannot query DNS, so it approximates the organizational domain with the Public Suffix List, the way RFC 7489 did. For ordinary domains the answer is the same as the Tree Walk. If a domain publishes DMARC records on its subdomains or uses psd=, the two can differ, and the dmarc= verdict your provider wrote into Authentication-Results is the authoritative one.

Relaxed vs strict

The domain owner chooses the mode per mechanism in its DMARC record with adkim= and aspf= (r or s, both defaulting to r).

• Relaxed (RFC 9989 §3.2.10.1): same organizational domain.
• Strict (RFC 9989 §3.2.10.2): identical domain names, compared case-insensitively.

RFC 9989 §4.4 notes that nearly all domain owners find relaxed sufficient. Strict is for organizations that delegate subdomains to other parties and do not want those parties to be able to pass DMARC for the parent. §11.8 describes the risk: if an attacker controls the DNS of evil.example.com, relaxed alignment lets them pass DMARC as example.com.

Worked examples

All with From: someone@example.com unless stated.

And with From: alerts@news.example.com:

Two things to notice. Alignment ignores direction: a parent and a child align under relaxed mode either way round. And a check has to pass before alignment is even considered; an aligned SPF fail contributes nothing.

Email service providers

This is where most real-world alignment failures come from. Say example.com sends its newsletter through a bulk email service. Out of the box, many services use their own domains for the technical identities. Using SendGrid as the example (the bounce address and selector are illustrative):

From: Example News <news@example.com>
Return-Path: <bounce-8f2a@sendgrid.net>
DKIM-Signature: v=1; a=rsa-sha256; d=sendgrid.net; s=smtpapi; ...
Authentication-Results: mx.example.net;
 spf=pass smtp.mailfrom=sendgrid.net;
 dkim=pass header.d=sendgrid.net;
 dmarc=fail header.from=example.com

Both checks pass, but both are for sendgrid.net, so neither aligns with example.com and DMARC fails. The service is real; it simply has not been configured to authenticate as the customer.

The fix every major service supports is a custom or "authenticated" sending domain: the customer adds DNS records so the service signs with d=example.com (or a subdomain) and uses a bounce domain such as em.example.com:

Return-Path: <bounce-8f2a@em.example.com>
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; ...
Authentication-Results: mx.example.net;
 spf=pass smtp.mailfrom=em.example.com;
 dkim=pass header.d=example.com;
 dmarc=pass header.from=example.com

Now both align (SPF relaxed, DKIM strict and relaxed). The service hostnames in Received lines are unchanged, and that is fine: DMARC does not care which servers carried the message, only which domains were authenticated.

Why one aligned pass is enough

DMARC is deliberately an OR. RFC 9989 §4.4.1 says a message passes if any DKIM identifier aligns; the evaluation steps in §5.3 pass the message if any authenticated identifier aligns. This is what makes forwarding survivable: forwarding breaks SPF, but an aligned DKIM signature usually survives a plain forward and carries DMARC on its own. Mailing lists tend to break both, which is the problem ARC tries to address; see forwarding and mailing lists.

Paste headers into the analyser to see each SPF and DKIM domain side by side with the From domain, labeled aligned or not under both relaxed and strict rules.