DMARC alignment explained: SPF and DKIM alignment in practice

DMARC alignment is the requirement that the domain which passed SPF or DKIM matches the domain in the message's visible From header. A message passes DMARC only if at least one of SPF or DKIM both passes its own check and aligns with the From domain. This is why mail can pass SPF and DKIM individually yet still fail DMARC.

Why does DMARC need alignment at all?

SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) each authenticate a domain, but not necessarily the domain your recipient sees. SPF validates the domain in the Return-Path (the RFC5321.MailFrom, used for bounces). DKIM validates whichever domain appears in the signature's d= tag. Neither check looks at the From header on its own.

That gap matters because the From header is the identity a human actually reads. Without alignment, an attacker could send mail from their own infrastructure, pass SPF for a domain they control in the Return-Path, sign with DKIM for a domain they control, and still display accounts@yourbank.example in the From header. Both checks would pass, and the recipient would see a forged identity.

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) closes the gap by tying authentication to the visible identity. It takes the From header domain as the anchor, then asks: did SPF or DKIM produce a pass for a domain that aligns with it? Only an aligned pass counts. This is the concept most people miss when they first deploy DMARC, and it explains almost every confusing result in DMARC aggregate reports.

How does SPF alignment work?

SPF alignment compares two domains:

• The domain in the From header (what the recipient sees).
• The domain SPF actually checked: the Return-Path domain, also called the envelope from or RFC5321.MailFrom.

If SPF passes and those two domains align, you have an aligned SPF pass and DMARC is satisfied. If SPF passes but the domains differ, the pass is real for SPF's own purposes but contributes nothing to DMARC.

A worked example. A marketing platform sends on your behalf:

• From header: news@example.co.uk
• Return-Path: bounce.12345@mailer.espvendor.example

The platform publishes a correct SPF record for mailer.espvendor.example, so SPF passes. But the SPF-checked domain is espvendor.example, not example.co.uk. The domains do not align, so this message cannot pass DMARC via SPF. It must rely on DKIM instead, which is exactly why reputable providers offer a custom DKIM signing domain, and some also offer a custom Return-Path (often a CNAME like bounce.example.co.uk pointing at their infrastructure). The general pattern is covered in getting third-party senders to align, and the distinction between the two from addresses in envelope from vs header from.

How does DKIM alignment work?

DKIM alignment compares the From header domain with the domain in the DKIM signature's d= tag. A message can carry several DKIM signatures; DMARC needs just one signature that both verifies and aligns.

Continuing the example, suppose the platform signs every message twice:

DKIM-Signature: v=1; a=rsa-sha256; d=espvendor.example; s=platform; ...
DKIM-Signature: v=1; a=rsa-sha256; d=example.co.uk; s=esp1; ...

The first signature (d=espvendor.example) verifies but does not align with the From domain example.co.uk. The second signature uses your domain, made possible because you published the provider's public key at esp1._domainkey.example.co.uk. If it verifies, it aligns, and the message passes DMARC. This is why setting up the custom DKIM records a provider issues is usually the single most important step in fixing alignment, and why DKIM tends to be the more reliable path to DMARC compliance: it also survives forwarding, which usually breaks SPF, provided the forwarder does not modify the message.

What is relaxed vs strict alignment?

Alignment comes in two modes, set independently for DKIM and SPF with the adkim and aspf tags in your DMARC record. Both default to relaxed.

Mode	Rule	Example that aligns	Example that does not
Relaxed (r)	The two domains must share the same organisational domain	From example.co.uk, DKIM d=mail.example.co.uk	From example.co.uk, DKIM d=espvendor.example
Strict (s)	The two domains must match exactly	From example.co.uk, DKIM d=example.co.uk	From example.co.uk, DKIM d=mail.example.co.uk

The organisational domain is, roughly, the registrable domain: example.co.uk is the organisational domain for mail.example.co.uk, bounce.example.co.uk and so on. RFC 7489 determines it using a public suffix list, which is how it knows that co.uk is a suffix rather than someone's domain.

In practice, relaxed alignment is the right choice for almost everyone. It lets you delegate subdomains to sending services (a common and safe pattern) while still requiring the organisational domain to match. Strict alignment is a niche hardening option for organisations that want each exact domain to authenticate for itself; it buys little extra protection under DMARC alone and breaks the subdomain delegation patterns most third-party senders rely on. If you are weighing the trade-off, see adkim and aspf: strict vs relaxed for the details, and note that an explicit DMARC record on a subdomain, or the sp tag, is usually a better tool for controlling subdomain behaviour than strict alignment.

Why can mail pass SPF and DKIM but fail DMARC?

Because both passes can be unaligned at the same time. This is the classic pattern in aggregate reports: a report row shows spf=pass and dkim=pass, yet the DMARC result is fail. Reading the domains in the row explains it:

<record>
  <row>
    <source_ip>203.0.113.25</source_ip>
    <count>142</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.co.uk</header_from>
  </identifiers>
  <auth_results>
    <spf><domain>espvendor.example</domain><result>pass</result></spf>
    <dkim><domain>espvendor.example</domain><result>pass</result></dkim>
  </auth_results>
</record>

In auth_results, both SPF and DKIM passed, but each passed for espvendor.example. The header_from is example.co.uk. Neither pass aligns, so policy_evaluated shows DKIM and SPF as fail: those are the DMARC-evaluated, alignment-aware results, not the raw authentication results. Once you know to compare the domains, rows like this stop being mysterious. The pattern and its fixes are explored further in why mail passes SPF and DKIM but fails DMARC.

Other common causes of the same symptom:

• Forwarding. The forwarder's IP is not in your SPF record, so SPF fails or passes only for the forwarder's own bounce domain. DKIM normally survives and keeps the message aligned, unless the forwarder rewrites the body or headers.
• Mailing lists. Lists often modify the subject or body (breaking DKIM) and resend from their own infrastructure (breaking SPF alignment), leaving no aligned identifier.
• Internal tools sending as the parent domain through a service that only authenticates its own domain, with no custom DKIM configured.

How do you check and fix alignment?

A practical sequence:

1. Publish DMARC at p=none with reporting. This is monitoring only; it does not affect delivery. You will start receiving aggregate reports that show, per source, which identifiers passed and whether they aligned.
2. Inventory your senders. For each legitimate source in the reports, note the From domain it uses, the Return-Path domain, and the DKIM d= domain.
3. Fix DKIM first. For every third-party service, configure the custom signing domain it offers (usually a pair of CNAME records or a TXT record it issues) so its signatures carry your domain in d=. An aligned DKIM pass is sufficient on its own for DMARC.
4. Fix SPF where offered. Some services support a custom Return-Path subdomain; set it up where available. Where a service cannot align SPF, an aligned DKIM signature still carries the message.
5. Re-check the reports. When every legitimate source shows at least one aligned pass, you are ready to consider moving towards enforcement.

Two details worth knowing while you work through this. First, alignment is evaluated per message, so a source can be partially aligned: its transactional mail aligned via DKIM, its notification mail unaligned because it uses a different signing configuration. Second, you never need both mechanisms aligned; one is enough. Aiming for both gives you resilience (SPF covers a DKIM key mistake, DKIM covers forwarding), but do not delay enforcement waiting for a service that structurally cannot align SPF.

If either underlying mechanism is unfamiliar, it is worth understanding how SPF and DKIM each work on their own before layering alignment on top; the checks themselves are unchanged by DMARC, which only interprets their results.

Setting alignment modes in your DMARC record

The adkim and aspf tags control the modes. Both are optional and default to relaxed, so this record:

_dmarc.example.co.uk. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.co.uk"

is equivalent to:

_dmarc.example.co.uk. IN TXT "v=DMARC1; p=quarantine; adkim=r; aspf=r; rua=mailto:dmarc@example.co.uk"

To require exact matches, set adkim=s or aspf=s. Before tightening either, check your reports carefully: any sender currently aligning through a subdomain (a custom Return-Path like bounce.example.co.uk, or a DKIM d= on a delegated subdomain) will stop aligning under strict mode. Tightening alignment without that check is a common way to break mail that was previously compliant.

Working out which sources align and which do not is largely a reporting exercise, and raw aggregate reports are XML files that arrive by the hundred. A DMARC monitoring service such as DMARCHub turns them into per-source alignment views so you can see exactly which sender needs a custom DKIM domain before you tighten your policy.

Frequently asked questions

Does DMARC need both SPF and DKIM to align?

No. DMARC passes if either SPF or DKIM produces an aligned pass; one is sufficient. Having both aligned is good practice because it gives redundancy (for example, DKIM keeps forwarded mail passing after SPF breaks), but it is not required by RFC 7489.

What is the organisational domain in relaxed alignment?

It is the registrable part of a domain name, determined using a public suffix list: for mail.example.co.uk the organisational domain is example.co.uk, because co.uk is a public suffix. Relaxed alignment passes when the From domain and the authenticated domain share the same organisational domain.

Can a message have multiple DKIM signatures for alignment?

Yes, and it is common. Many services sign once with their own domain and once with yours. DMARC only needs one signature that both verifies and aligns; extra unaligned signatures are harmless and do not count against you.

Does strict alignment make DMARC more secure?

Only marginally, and it can break legitimate mail. Under relaxed alignment an attacker would still need to pass SPF or DKIM for a domain within your organisational domain, which they cannot do without access to your DNS or keys. Strict mode mainly matters in unusual delegation setups; for most organisations, relaxed alignment with a strong policy is the better position.