Alignment is the conceptual heart of DMARC — the check that closes the From:-header gap left by SPF and DKIM individually. This article explains what alignment means, the difference between relaxed and strict modes, how the organisational-domain lookup works, and how alignment interacts with third-party senders, forwarders and multi-domain organisations.
Consider an attacker targeting a UK business. They want to send a phishing message displaying From: [email protected] in the recipient's mail client. Without DMARC alignment, they can:
evil-attacker.com and publish valid SPF and DKIM on it.MAIL FROM: [email protected] (their own envelope sender).d=evil-attacker.com.From: [email protected] in the visible header.SPF passes (their server IP is in their own SPF). DKIM passes (their signature verifies against their own public key). Both authentication checks succeed — and the user sees From: [email protected], trusting a forged message.
Alignment is DMARC's answer: the domain that passed SPF or DKIM must match the From: header domain. The attacker's evil-attacker.com does not match firm.co.uk, so DMARC fails. The policy kicks in — the message is quarantined or rejected.
DMARC defines two independent alignment checks:
The envelope sender's domain (from the SMTP MAIL FROM command) must align with the From: header domain. SPF alignment passes when:
From: header (per the alignment mode).The DKIM signing domain (the d= tag of any valid DKIM-Signature header) must align with the From: header domain. DKIM alignment passes when:
d= tag aligns with the From: header.A message can carry multiple DKIM-Signature headers. DMARC passes if any one of them produces an aligned pass. This is important because third-party signers and mailing lists can add their own signatures alongside yours.
Both SPF and DKIM alignment can be configured independently via the aspf and adkim tags in the DMARC record:
The organisational domains must match. Subdomains count as aligned with the parent:
bounce.firm.co.uk aligns with firm.co.uk ✓mail.firm.co.uk aligns with firm.co.uk ✓firm.co.uk aligns with mail.firm.co.uk ✓The domains must match exactly. No subdomain substitution is allowed:
firm.co.uk aligns with firm.co.uk ✓bounce.firm.co.uk does not align with firm.co.uk ✗mail.firm.co.uk does not align with firm.co.uk ✗Strict alignment is more secure but less forgiving. Many legitimate mail flows (particularly those using bounce-handling subdomains or outsourced relays) fail strict alignment. Use strict only after you have verified every legitimate sender aligns exactly.
Relaxed alignment depends on identifying the "organisational domain" — the registrable part of a domain. DMARC uses the Public Suffix List maintained by Mozilla to determine this. Examples:
| Full domain | Organisational domain |
|---|---|
firm.co.uk | firm.co.uk |
bounce.firm.co.uk | firm.co.uk |
firm.ltd.uk | firm.ltd.uk |
firm.london | firm.london |
mail.firm.london | firm.london |
www.firm.gov.uk | firm.gov.uk |
The algorithm walks up the domain until it finds a name not listed as a public suffix. co.uk, gov.uk, ac.uk, org.uk, ltd.uk, plc.uk are all UK public suffixes. The domain immediately below is the organisational domain.
For most UK businesses, the organisational domain is "your domain ending in .co.uk, .uk, .com, .org.uk, etc." Subdomains of that domain share the organisational domain and therefore align under relaxed mode.
DMARC passes if at least one of these is true:
Both conditions are not required. A message with DKIM aligned pass but SPF fail passes DMARC. A message with SPF aligned pass but DKIM fail passes DMARC. Both failing means DMARC fails.
This redundancy is deliberate. SPF breaks on forwarding; DKIM usually survives. Requiring either alone means forwarded mail from a well-DKIM-signed sender still passes DMARC.
A Bristol accountancy sends from their own server, which is in the firm's SPF and signs with DKIM.
[email protected][email protected]d=firm.co.ukSame firm, but the mail server uses VERP on a bounce-handling subdomain.
[email protected][email protected]d=firm.co.ukfirm.co.uk) aligns under relaxed but not strict[email protected]d=firm.co.uk still intact (content unchanged)Marketing sent via a service that signs with its own domain.
[email protected][email protected]d=mcsv.netp=reject, the message is rejected.This is the pattern where custom sending domain authentication is essential. The service must be configured to sign with d=firm.co.uk.
[email protected][email protected]d=evil-attacker.com (attacker's own key)evil-attacker.com ✓ but does not align with From ✗evil-attacker.com ✓ but does not align ✗p=reject, the message is rejected.Any third-party service sending as your domain must produce at least one aligned authentication pathway. The two options:
d=firm.co.uk via CNAME-delegated DKIM. See DKIM for Third-Party Senders.Services that cannot do either cannot produce DMARC-aligned mail for your domain. Choosing such a provider means either accepting deliverability failure or routing mail via a subdomain with relaxed DMARC.
Forwarders change the sending IP, so SPF alignment typically fails after forwarding. DKIM alignment survives if the forwarder does not modify signed content. This is why:
The practical implication: a well-DKIM-signed message with relaxed canonicalisation survives typical UK forwarding. Strict canonicalisation or aggressive forwarder modification breaks alignment.
| Scenario | Recommendation |
|---|---|
| New UK deployment, simple sender list | Relaxed (default). Tighten to strict later if audit shows exact alignment. |
| Mature deployment, audited sender landscape | Strict. Maximum protection against subdomain spoofing. |
| Complex organisation with bounce subdomains | Relaxed. Strict would break legitimate bounce handling. |
| Regulated sector (finance, health) | Strict if feasible. Maximum assurance. |
| Domain running its own mail only, no third parties | Strict immediately. No complexity to accommodate. |
The epost.plus production record publishes adkim=s; aspf=s — strict on both. This is the hardened end state for a domain with fully controlled sender infrastructure.
DMARC aggregate reports surface alignment outcomes per source IP. In the XML report, each record shows:
d= of each signature.When investigating an alignment failure, look for:
From: — third-party senders not configured for custom domain auth.d= — same problem.d=yourdomain — DKIM alignment passes under both relaxed and strict modes. Envelope senders use your domain too, so SPF alignment is clean. Strict DMARC (adkim=s; aspf=s) works out of the box.
A UK holding company with several trading brands — firm.co.uk, firm-consulting.co.uk, firm-capital.co.uk — treats each domain as an independent authentication entity. DMARC alignment is checked per-domain per-message. There is no shortcut that lets one domain's authentication satisfy another's alignment.
The operational consequence:
For groups with shared infrastructure, this feels like duplication — but it is the correct security posture. Cross-domain authentication would let any compromised brand authenticate as every other brand.
They are different checks. SPF can pass on the envelope sender's domain without aligning to From:. DMARC aggregate reports show both results separately — do not conflate them.
Some mail servers (particularly Microsoft 365 inbound filters and certain gateways) rewrite envelope senders for bounce handling without operator awareness. Check aggregate reports to see what envelope sender your messages actually carry.
VERP (Variable Envelope Return Path) rewriting changes the envelope sender's local part but keeps the domain. Usually fine for relaxed alignment; breaks strict if the rewriting uses a different subdomain.
The "I set up Mailchimp and it works" problem — Mailchimp does send mail but signs with d=mcsv.net. Alignment fails. Fix: configure custom sending domain authentication in Mailchimp's admin.
If mail.firm.co.uk has its own DMARC record at p=none while firm.co.uk has p=reject, mail from [email protected] goes through mail.firm.co.uk's (weak) policy — not the parent's. Audit subdomain DMARC records regularly.
Q: Does DMARC ever require both SPF and DKIM to align?
A: No — only one aligned pass is sufficient. DMARC was designed this way to allow forwarding (which breaks SPF) to pass via DKIM.
Q: What if my SPF passes but is aligned on a subdomain while my DMARC is in strict mode?
A: SPF alignment fails. DMARC falls back to DKIM — if DKIM aligns, DMARC still passes. If both fail alignment, DMARC fails.
Q: Does the From: display name affect alignment?
A: No — only the domain part of the From: header is used for alignment. The display name is not authenticated by DMARC at all, which is a known limitation (attackers use display-name spoofing with legitimate email addresses to evade DMARC).
Q: If my domain has multiple From: headers (uncommon but possible), which is used?
A: Multiple From: headers are technically an RFC 5322 violation; most receivers pick the last one, some reject the message outright. Never send with multiple From headers.
Q: Can I test alignment without sending live mail?
A: Send a test to a verifier service such as [email protected], which emails back a detailed DMARC evaluation including alignment results.
Q: Does the Sender: header affect alignment?
A: No. DMARC only considers the From: header for alignment. Sender: is irrelevant to the authentication decision.
Q: Are there UK-specific rules for alignment?
A: NCSC guidance leans toward strict alignment for high-assurance deployments but does not mandate it. Most UK SMEs successfully deploy at relaxed mode.
Q: Can alignment partially pass (e.g. SPF aligned but SPF verification failed)?
A: No — the alignment check only matters when the underlying authentication passed. SPF failing means no SPF pathway can align.
Q: Does alignment apply to attachments and content?
A: No. Alignment is a domain-matching concept. Content integrity is DKIM's responsibility.
Q: If I tighten from relaxed to strict, will any legitimate mail break?
A: Only if legitimate mail relies on subdomain-level authentication that does not exactly match the From: domain. Monitor DMARC reports for at least two weeks before switching, identify any non-exact alignments, fix them (change d= to match, or route through different sender), then tighten.
Q: Can alignment pass when the From: domain is not mine?
A: No — DMARC applies to the From: domain. If the From: is someone else's domain, that domain's DMARC record is what matters. Your record only governs messages claiming to be from your domain.
Q: Does alignment consider DNSSEC?
A: No — alignment is a domain-name equality check. DNSSEC integrity of the SPF/DKIM/DMARC records themselves is a separate concern (and a good practice, but orthogonal to alignment).
Q: If my DKIM has multiple signatures with different d=, which one is used for alignment?
A: Any one that aligns produces a DMARC pass. Receivers check each DKIM-Signature independently and consider the message aligned if any passes alignment.
Q: Is alignment the same as matching?
A: Close but distinct. Matching is "do the strings equal?" Alignment is "do the domains agree under the chosen mode?" — which under relaxed mode allows subdomain-to-parent agreement. In strict mode, alignment and matching are equivalent.
Q: What does "aligned pass" mean precisely?
A: It means both (a) the authentication mechanism (SPF or DKIM) produced a "pass" result, and (b) the relevant domain aligned with the From: header. One without the other is not an aligned pass.
Q: Can alignment be evaluated by the sender before sending?
A: Partially. The sender knows the From: domain, the envelope sender, and the DKIM d= at signing time. They can compute whether those would align — and most senders that care about DMARC compliance do. The SPF pass result, however, depends on the receiver's view of the sending IP at delivery time.
Q: How often do alignment failures represent genuine attacks vs legitimate configuration issues?
A: In the first few weeks of a DMARC deployment, the overwhelming majority of alignment failures are legitimate configuration issues — missed senders, third parties signing with their own domains, forwarders breaking DKIM. Genuine attacks are rarer but easily distinguished in aggregate reports (IPs in suspicious countries, volumes inconsistent with your mail flow, rapid bursts).