SPF alignment: why SPF passes and DMARC still fails

SPF alignment means the domain SPF authenticated — the envelope sender, which you read as Return-Path — belongs to the same organisational domain as the From header the recipient sees. SPF can pass perfectly and DMARC can still fail, because SPF never looks at the From header at all.

The two domains in every message

Every email carries two sender identities:

A message can have Return-Path: <bounce@mail.esp-domain.com> and From: you@yourdomain.com. SPF evaluates mail.esp-domain.com's record against the connecting IP and passes. DMARC then asks: does mail.esp-domain.com align with yourdomain.com? It does not. SPF contributes nothing to DMARC for that message.

Relaxed vs strict

DMARC's aspf tag controls how exact the match must be:

• `aspf=r` (relaxed, the default). The two domains need only share an organisational domain. bounce.yourdomain.com aligns with yourdomain.com. This is what you want in almost every case.
• `aspf=s` (strict). Exact string match. bounce.yourdomain.com does not align with yourdomain.com.

adkim does the same for DKIM's signing domain (the d= tag in the DKIM-Signature header). Strict alignment is for organisations that have audited every sender and want to stop subdomain abuse; it is not a general upgrade, and switching it on casually breaks mail that was passing yesterday.

Read your own alignment in 30 seconds

Send a message to a mailbox you control, open the raw source, and compare two lines:

Return-Path: <bounces@mail.yourdomain.com>
From: Sales <you@yourdomain.com>
Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=mail.yourdomain.com;
  dkim=pass header.i=@yourdomain.com;
  dmarc=pass (p=NONE) header.from=yourdomain.com

smtp.mailfrom is the domain SPF authenticated. header.from is what DMARC compared it with. If smtp.mailfrom is on a domain you do not own, SPF alignment is failing and your DMARC pass is riding entirely on DKIM. That is fine — but you should know it, because it means a DKIM problem takes you to dmarc=fail with no fallback.

The five causes, and the fix for each

1. The platform uses its own bounce domain. Standard behaviour for hosted ESPs. The fix is not to change SPF; it is to make sure DKIM is aligned (signed with a key published under your domain) or, if the platform supports it, to configure a custom Return-Path on a subdomain of yours — usually a CNAME such as bounce.yourdomain.com pointing at the platform. That single change converts an unaligned SPF pass into an aligned one.

2. Forwarding. When a recipient auto-forwards your message, the forwarding server connects from its own IP, which is not in your SPF record. SPF fails, permanently and unfixably from your side. Some forwarders implement SRS (Sender Rewriting Scheme) and rewrite the envelope so SPF passes for *them*, which does not align with you either. This is the strongest practical argument for DKIM: a valid DKIM signature survives forwarding as long as the body is not rewritten, so DMARC still passes.

3. Missing or broken SPF record. No v=spf1 record, two of them (which yields PermError and disables SPF), or more than 10 DNS-querying mechanisms (also PermError). Check:

dig +short TXT yourdomain.com | grep spf1

Exactly one line should come back.

4. Third-party tools sending as you. Helpdesks, invoicing systems, calendar tools and survey platforms all like to put your address in From. Each needs either an aligned DKIM key or an envelope on your domain. Find them from DMARC aggregate reports under p=none before you enforce.

5. A DMARC policy that enforces what you have not fixed. p=reject with aspf=s on a domain whose main platform uses its own bounce domain will reject your own campaigns. Alignment mode is a statement about your infrastructure; make the infrastructure true first.

The three real fixes

1. Align the Return-Path. Configure a custom bounce subdomain at your sending platform. This is the only fix that gives you aligned SPF on hosted mail.
2. Get DKIM aligned and keep it that way. Publish the key under your domain, use a distinct selector per platform, and use 2048-bit keys. DKIM alignment is more durable than SPF alignment because it survives forwarding.
3. Publish SPF that is correct and small. One record, every genuine sender included, dead includes removed, ~all while you learn and -all once reports are clean. Subdomain-per-service keeps each SPF budget separate:

yourdomain.com      TXT   "v=spf1 include:_spf.google.com -all"
mg.yourdomain.com   TXT   "v=spf1 include:mailgun.org -all"

What not to do

• Do not switch to aspf=s to "tighten security" without checking that every sender uses the exact domain. It is the fastest way to fail DMARC on your own mail.
• Do not try to fix forwarding failures by adding forwarders' IPs to your SPF record. You cannot enumerate them, and you would be authorising third-party servers to send as you.
• Do not flatten your SPF record into raw IP ranges to buy lookup headroom unless you have a process to re-flatten when providers renumber. A stale flattened record fails silently.
• Do not rely on SPF alone for DMARC. One aligned mechanism is the minimum, two is the resilient configuration.

MailPilot checks SPF, DKIM and DMARC for every connected mailbox's sending domain and measures per-provider inbox placement with a seed-inbox network, so an alignment problem shows up as a failing check and a visible drop in placement rather than as silent filtering.