SPF Alignment Explained: Why SPF Passes But DMARC Still Fails

SPF alignment is the DMARC check that trips up more senders than any other. Your SPF record can be perfectly configured, your sending IP fully authorized, and your emails can still fail DMARC — because the domain that passed SPF doesn't match the domain your recipients see in the From: address.

Here's what SPF alignment is, why it fails even when SPF itself passes, and how to fix it.

What SPF Alignment Actually Checks

When a receiving mail server evaluates your message under DMARC, it runs SPF authentication and SPF alignment as two separate steps:

1. SPF authentication — Does the sending server's IP appear in the SPF record for the envelope return-path domain? This checks whether the sender is authorized.
2. SPF alignment — Does the domain in the envelope return-path match the domain in the visible From: header? This checks whether the sender is consistent.

Both must pass for DMARC to use the SPF path. If SPF authentication passes but alignment fails, DMARC falls back to DKIM. If DKIM alignment also fails, DMARC fails entirely — and your p= policy (quarantine or reject) takes effect.

The return-path, explained

The envelope return-path (also called the MAIL FROM or bounce address) is a hidden technical address that mail servers use to route bounces and delivery errors. It is not the address your recipient sees. The address they see is the From: header.

These can be — and frequently are — different domains. That difference is what breaks SPF alignment.

SPF Authentication vs SPF Alignment

This distinction is the source of most confusion, so it's worth being precise:

You can have SPF authentication pass and SPF alignment fail in the same message. In fact, with most email service providers, that's the default behavior.

Why SPF Alignment Fails

Your ESP sets the return-path to its own domain

This is the most common cause. SendGrid, Mailgun, Amazon SES, HubSpot, Postmark, and most other ESPs set the envelope return-path to a domain they control — bounce.sendgrid.net, mailgun.org, amazonses.com, and so on.

SPF authentication passes because the sending IP is authorized by the ESP's SPF record. But SPF alignment fails because bounce.sendgrid.net does not match yourcompany.com in your From: header.

You're using strict alignment (aspf=s)

DMARC's aspf= tag controls how strict the alignment comparison is. With aspf=s (strict), the return-path domain must exactly match the From: domain. With aspf=r (relaxed, the default), a subdomain of the From domain — or the From domain being a subdomain of the return-path domain — still passes.

If you set aspf=s and your ESP sends from a subdomain like mail.yourcompany.com while your From: is user@yourcompany.com, alignment fails. Switch to aspf=r (or omit the tag, since relaxed is the default) to fix this.

Email forwarding

When a message is forwarded, the forwarder's mail server typically rewrites the envelope return-path to its own domain (this is called SRS, or Sender Rewriting Scheme). The original SPF alignment is lost because the return-path now belongs to the forwarder, not you. This is a known, unfixable limitation of SPF alignment with forwarded mail — and a primary reason DKIM alignment is preferred.

Multiple sending sources with different return-paths

If you send from multiple platforms — say, your own mail server for 1:1 email and Mailchimp for newsletters — each may use a different return-path domain. Without a custom return-path on each, SPF alignment will fail for some or all of them.

How to Diagnose SPF Alignment Failures

Check your DMARC aggregate reports

DMARC aggregate reports (RUA reports) are the authoritative source. Each report lists every message sent from your domain and shows:

• Which authentication passed (SPF, DKIM, or both)
• Whether alignment passed or failed for each
• The sending IP and return-path domain

Look for rows where spf_result = pass but dmarc_result = fail. That's an SPF alignment failure. The report shows you the return-path domain that didn't match your From: domain.

If you don't have RUA reports set up yet, add rua=mailto:reports@yourdomain.com to your DMARC record:

_dmarc.yourdomain.com.  TXT  "v=DMARC1; p=none; rua=mailto:reports@yourdomain.com"

Keep p=none while you're diagnosing — you want to collect data without blocking mail.

Inspect email headers

Send a test email to a Gmail address, click the three dots, and select Show original. In the authentication results, you'll see:

Authentication-Results: mx.google.com;
   spf=pass (domain: sendgrid.net) smtp.mailfrom=bounce.sendgrid.net;
   dmarc=fail (p=quarantine) header.from=yourcompany.com

This tells you SPF passed (for sendgrid.net) but DMARC failed because the header.from domain (yourcompany.com) didn't align with the SPF domain (sendgrid.net).

Scan your DNS records

Run your domain through a free DNS scanner to confirm your SPF, DKIM, and DMARC records are all published and correctly formatted. A missing or malformed SPF record can cause authentication failures that look like alignment problems.

How to Fix SPF Alignment

Option 1: Rely on DKIM alignment (most common fix)

This is what most senders do. DMARC passes if either SPF alignment or DKIM alignment passes — you only need one. If your ESP breaks SPF alignment (and most do), configure DKIM signing with your own domain so DKIM alignment carries DMARC instead.

To do this:

1. Generate a DKIM key pair (or use the one your ESP provides for custom DKIM).
2. Publish the public key as a DNS TXT record at selector._domainkey.yourdomain.com.
3. Configure your ESP to sign outgoing mail with d=yourdomain.com.

When the DKIM signature's d= domain matches your From: domain, DKIM alignment passes and DMARC passes — regardless of whether SPF alignment fails.

Option 2: Configure a custom return-path

Some ESPs let you set a custom return-path subdomain on your own domain. The ESP publishes a CNAME pointing their bounce handling to your subdomain:

bounce.yourdomain.com.  CNAME  bounce.sendgrid.net.

Now the return-path is bounce.yourdomain.com, and under relaxed alignment (aspf=r), yourdomain.com in the From: header aligns with bounce.yourdomain.com. SPF alignment passes.

ESP support for custom return-paths:

• SendGrid — Supports custom return-path via authenticated domain setup
• Mailgun — Supports custom return-path domain
• Amazon SES — Supports custom MAIL FROM domain (requires MX and SPF records on the subdomain)
• Postmark — Sets a custom return-path automatically when you verify your domain

Option 3: Switch to relaxed alignment (aspf=r)

If you've set aspf=s and are seeing failures, check whether your sending sources use subdomains. If they do, switch to relaxed:

_dmarc.yourdomain.com.  TXT  "v=DMARC1; p=quarantine; aspf=r; rua=mailto:reports@yourdomain.com"

Omitting the aspf= tag entirely has the same effect — relaxed is the default.

Which fix should you choose?

For most senders: Option 1 (DKIM alignment). It's the simplest, works with every ESP, and isn't affected by forwarding. Set up custom DKIM signing, verify alignment passes in your DMARC reports, and you're done.

Custom return-path (Option 2) is worth setting up if you want SPF alignment as a backup path — but it's not necessary if DKIM alignment is working.

SPF Alignment for Common ESPs

SendGrid

SendGrid sets the return-path to bounce.sendgrid.net by default. SPF passes but alignment fails. Fix: either set up authenticated domain (custom return-path via CNAME) or configure custom DKIM signing with your domain.

Mailgun

Mailgun sets the return-path to mailgun.org by default. Custom return-path is supported via domain-level configuration. DKIM signing is available with a custom selector.

Amazon SES

Amazon SES sets the return-path to amazonses.com. You can configure a custom MAIL FROM domain — this requires adding an MX record and SPF record to the subdomain you choose. SES also supports DKIM signing via Easy DKIM with a custom domain.

Google Workspace

Google Workspace sets the return-path to your domain automatically when you send from Google's servers. SPF alignment typically passes without extra configuration — the return-path is on your domain, not Google's.

Microsoft 365

Microsoft 365 (Exchange Online) sets the return-path to your domain by default. SPF alignment passes for mail sent through Exchange Online. If you use a third-party sending service alongside Microsoft 365, that service may break alignment — configure DKIM for the third-party sender.

Summary

SPF alignment fails when the domain that passed SPF authentication doesn't match the domain in your From: header. It happens most often because your ESP sets the return-path to its own domain. The fix is straightforward: either configure a custom return-path on your domain, or — more commonly — set up DKIM signing with your own domain so DKIM alignment carries DMARC instead.

Check your grade free

Don't guess what's broken — see it. Scan your domain free at emailsecuritygrade.com and get an instant A-F grade on your SPF, DKIM, DMARC, and MX records, with a plain-language fix for anything failing. No signup, no install — it runs in your browser.

If your emails are still landing in spam after fixing the records, a deliverability tool like InboxAlly can train mailbox providers to trust your sending — worth a look once your grade is solid.