DMARC fails on SPF: return-path (envelope-from) misalignment explained and fixed

SPF can pass and DMARC can still fail because the two checks look at different domains. SPF authenticates the envelope sender, the `MAIL FROM` return-path; DMARC requires that domain to align with your visible `From:` header. Most ESPs set their own bounce domain as the return-path, so SPF passes for the ESP and never aligns with your `From`. The fix is to make the return-path your own domain through a custom `MAIL FROM`, not to weaken your DMARC policy.

Quick answer

SPF can pass and DMARC can still fail. The two checks look at different domains. SPF authenticates the envelope sender, the MAIL FROM identity defined in RFC 7208 §1.1.3 as the RFC5321.MailFrom reverse-path. DMARC then asks a second question: does that authenticated domain align with the domain in the visible From: header? RFC 7489 §3.1.2 requires the SPF-authenticated domain and the RFC5322.From domain to share an Organizational Domain. Most ESPs set their own bounce domain as the return-path, so SPF passes for the ESP and the MAIL FROM never aligns with your From. The fix is to make the return-path your own domain through a custom MAIL FROM, not to weaken your DMARC policy.

Two identities: what SPF checks versus what DMARC needs

Every message carries two separate sender addresses. The RFC5321.MailFrom is the envelope sender, also called the return-path, the bounce address, or the envelope-from. It travels in the SMTP MAIL FROM command and the receiving server uses it to route bounces. SPF verifies this identity and nothing else: RFC 7208 §2.4 says verifiers apply the check_host() function to the MAIL FROM identity. The RFC5322.From is the header your recipient reads in their mail client. These two domains are independent and frequently differ.

They differ most often at an ESP. When you send through a marketing or transactional platform, the platform usually sets the return-path to its own bounce domain so it can process your bounces and complaints. SPF then evaluates that bounce domain, finds the platform's sending servers authorized, and returns spf=pass. The pass is real, but it authenticates the platform's domain, not yours.

DMARC adds the alignment requirement on top of that pass. RFC 7489 §3.1.2 defines two modes. In relaxed mode, the default, the SPF-authenticated domain and the From domain must have the same Organizational Domain, so a return-path of bounce.yourbrand.com aligns with a From of you@yourbrand.com. In strict mode, set with aspf=s, only an exact DNS domain match counts. The aspf tag defaults to relaxed per RFC 7489 §6.3. Either way, an ESP bounce domain such as bounces.esp-mail.com shares no Organizational Domain with yourbrand.com, so the SPF path produces a pass that does not align, and it contributes nothing to DMARC.

DMARC does not need both paths to align. A message passes DMARC if at least one supported mechanism produces a pass on an aligned identifier (RFC 7489 §3.1). So an unaligned SPF pass is harmless on its own, provided DKIM is aligned and passing. The misalignment becomes a real DMARC failure when DKIM is also unaligned, or on forwarded mail where the forwarding hop rewrites the return-path and leaves you with no aligned path at all. The DKIM side of this same alignment story is covered in DKIM passes but DMARC fails.

How to diagnose return-path misalignment

Read the Authentication-Results header of a real delivered message. The SPF result and the domain it authenticated are both reported there as spf=pass smtp.mailfrom=<domain>, using the token vocabulary from RFC 8601. The smtp.mailfrom value is the return-path domain SPF checked.

Compare two things:

The smtp.mailfrom value, which is the envelope domain SPF authenticated.
The domain in the From: header, which is the domain your recipient sees.

If smtp.mailfrom is your ESP's bounce domain, or any domain whose Organizational Domain differs from your From domain, SPF passed but did not align. Your DMARC aggregate (rua) reports show the same per source: each sending IP lists its SPF result and whether that result was in alignment, so you can confirm the gap across every stream rather than from one test message.

How to fix return-path misalignment

Identify the sending platform behind the unaligned SPF pass from smtp.mailfrom and your aggregate reports.
Configure that platform to use a custom return-path, sometimes called a custom MAIL FROM or bounce domain, on a subdomain you own. Amazon SES documents this directly: by default messages use a subdomain of amazonses.com, and a custom MAIL FROM domain makes the envelope-from a subdomain of your own domain instead (Amazon SES: Using a custom MAIL FROM domain).
Publish the DNS records the platform generates for that subdomain. Providers vary: SES requires an MX record plus an SPF TXT record on the return-path subdomain, while other ESPs delegate the lookup with a CNAME. Either way the published SPF record at the return-path domain must authorize the platform's sending servers.
Re-send a test message and re-read Authentication-Results. You want spf=pass with smtp.mailfrom now sharing your Organizational Domain (relaxed) or exactly equal to your From domain (strict). Confirm the change holds across every sending platform in your aggregate reports before treating it as resolved.

Do not change p= or switch aspf=s to aspf=r to make the failure disappear. Relaxing alignment only helps when the return-path already shares your Organizational Domain; it never rescues a MAIL FROM that belongs to your ESP.

What this does not prove

A public check reads the DMARC policy and SPF records your domain publishes. It cannot read the Authentication-Results header of a specific message you sent, because that header is written by the receiving server and lives in the delivered message, not in DNS. So a public tool cannot tell you which smtp.mailfrom a given platform actually used, whether a past delivery failed for alignment or for a different reason, or whether every one of your sending streams aligns.

For those answers you need real message headers from each platform and your DMARC aggregate report feed. Fixing one platform's return-path closes one alignment gap; it does not guarantee DMARC passes everywhere, because another stream may still send from a non-aligned return-path, and DKIM alignment is a separate question handled on the signing side.

Frequently asked questions

How can SPF pass but DMARC still fail?

SPF authenticates the envelope sender, the `RFC5321.MailFrom` return-path. DMARC then requires that authenticated domain to align with the visible `From:` header. When your ESP sets its own bounce domain as the return-path, SPF passes for the ESP but the return-path does not share an Organizational Domain with your `From`, so the SPF path does not align and contributes nothing to DMARC.

What is the difference between the MAIL FROM and the From header?

The `RFC5321.MailFrom` is the envelope sender, also called the return-path or bounce address, carried in the SMTP `MAIL FROM` command; SPF checks this per RFC 7208 §2.4. The `RFC5322.From` is the header address your recipient sees in their mail client. The two are independent, and at an ESP they usually point to different domains.

Does relaxed or strict alignment change whether the return-path aligns?

Relaxed mode, the `aspf` default, only requires the return-path and `From` domains to share an Organizational Domain, so `bounce.yourbrand.com` aligns with `you@yourbrand.com`. Strict mode (`aspf=s`) demands an exact DNS domain match. Neither mode rescues an ESP bounce domain like `bounces.esp-mail.com`, which shares no Organizational Domain with yours.

Should I switch aspf to relaxed or lower my policy to fix this?

No. Relaxing `aspf` only helps when the return-path already shares your Organizational Domain, and lowering `p=` hides the failure instead of fixing it. The correct fix is to make the return-path your own domain by configuring a custom return-path (custom `MAIL FROM`) on the sending platform.

If SPF is unaligned, can DMARC still pass overall?

Yes. DMARC passes if at least one mechanism produces a pass on an aligned identifier (RFC 7489 §3.1). An unaligned SPF pass is harmless when DKIM is aligned and passing. The misalignment becomes a real DMARC failure when DKIM is also unaligned, or on forwarded mail where the forwarding hop breaks the remaining aligned path.

References

Browse all guides →