Return-Path: The Address SPF Checks and Your Reader Never Sees

Every email carries two sender addresses. Your reader sees one of them. SPF checks the other one, and DMARC passes or fails on whether the two belong to the same domain.

The one your reader sees is the From header. The one SPF checks is the envelope sender, which the receiving server writes into the message as the Return-Path header when it accepts delivery. A message can pass SPF perfectly on a return path belonging to your sending platform and still fail DMARC, because the address in the From header is yours and the authenticated one is not.

Return-Path is the envelope sender, not the From address

SMTP has an envelope and a message, and they carry separate addresses. The envelope sender is given in the MAIL FROM command at the start of the transaction, before any headers are sent. The From header is part of the message, written by whatever composed it.

The receiving server is what turns one into the other: on accepting a message it stamps the envelope sender into a Return-Path header at the top. So a Return-Path in a message you received is a record of what the sending server claimed on the wire, written down by the receiver. It is not something the sender sets as a header, and a Return-Path added by a sender is meaningless.

Three addresses are routinely confused and each does a different job:

Field	Set by	Used for
Return-Path	The receiver, from MAIL FROM	SPF, and where bounces go
From	The composer	What your reader sees, and what DMARC protects
Reply-To	The composer	Where a reply is addressed

SPF authenticates the return path, which is why SPF alone does not stop spoofing

SPF asks whether the connecting server is authorized to send for a domain, and the domain it uses is the one in the envelope sender. RFC 9989 compares RFC5321.MailFrom and never the HELO name, so a tool that reports SPF alignment from the HELO identity is answering a different question.

That is the whole reason SPF on its own has never stopped display-name spoofing. Anyone can send a message with MAIL FROM: bounces@a-domain-they-own.example and a From header reading your company. SPF passes, because the sender really is authorized for the envelope domain they chose. The reader sees your name in the inbox. Nothing about that is a defect in SPF; it is SPF checking the identifier it was designed to check.

DMARC is the layer that closes it, by requiring the authenticated identifier to relate to the visible one.

DMARC needs the return path domain to align with your From domain

Alignment is the comparison DMARC performs. It does not ask whether SPF passed. It asks whether SPF passed for a domain that matches the one in the From header.

Your marketing platform can pass SPF on its own bounce domain every single time, and your DMARC result is still a fail on the SPF side, because the two identifiers do not relate. DKIM can rescue the message if the platform signs as your domain, and often it is the only thing doing so. Across the domains we test for the Unspam 2026 Email Deliverability Benchmark, only 48% publish a DMARC policy, and among those that do, an unaligned return path is one of the commonest reasons a domain stays at p=none for a year.

The visible symptom, before any report arrives, is the inbox telling on you. Gmail shows a message as sent "via" the platform's domain when the return path does not match the From domain, and other clients print something similar. If your mail says "via" somebody else, your return path is not aligned.

Relaxed alignment cannot be decided from headers alone

DMARC has two alignment modes, and the difference matters when you read a checker's output.

• Strict means the two domains are identical. That is decidable from the headers in front of you.
• Relaxed, the default, means the two share an organizational domain. That is not decidable from the headers, because working out where the organizational boundary sits is a DNS question.

RFC 9989 replaced the Public Suffix List with a DNS tree walk for exactly this. Under the old approach a tool could carry a copy of the list and answer offline, at the cost of being wrong whenever the list moved. Under the current one, the answer requires resolving the tree, so a header analyzer that reports "aligned" with no lookups has either only settled the strict case or guessed.

Our email header analyzer settles strict alignment from the headers and reports the relation between the two domains, one of identical, a subdomain of the author domain, the author being a subdomain, sharing an ancestor, or unrelated. Relaxed alignment is settled separately with the tree walk, because a result that has not been measured is not a result.

That distinction is practical, not pedantic. bounces.example.com against example.com is relaxed-aligned and strict-unaligned, which is the normal state of a correctly configured custom return path, and a tool that reports it as a failure will send you to fix something that is already right.

A custom return path is how a platform gets SPF alignment

The standard fix is a subdomain you delegate to the platform. You publish a CNAME at something like bounces.example.com pointing at the platform's infrastructure, the platform uses that name as the envelope sender, and SPF now passes on a domain that shares your organizational domain, which is relaxed-aligned.

Four details decide whether this works:

1. It has to be a subdomain of your From domain. A CNAME on a different domain you also own aligns with nothing.
2. The SPF record that matters is the one on the return path domain, not on your From domain. This is the step most often skipped, because people check the wrong record and see a pass.
3. The platform has to be configured to use it. Publishing the DNS is half of it; the sending platform has a setting, and an unset one means it carries on using its own bounce domain.
4. A subdomain inherits your DMARC policy through the tree walk, unless you publish sp to say otherwise, so it is covered by whatever enforcement you have.

The guide to SPF records covers the record itself, and our guide to DMARC records covers the policy and its tags.

Bounces go to the return path, and nowhere else

The other job of the envelope sender is where non-delivery reports are addressed. A server that cannot deliver your message sends the failure to the return path, not to your From address and not to Reply-To.

This is why a custom return path changes who sees bounces. Delegate it to a platform and the platform collects them, which is what lets it suppress dead addresses automatically. Point it at an unmonitored mailbox on your own domain and the reports pile up somewhere nobody reads, which is how a list quietly rots.

It is also why a return path of <>, the null sender, exists. Bounce messages themselves are sent with an empty envelope sender so that a bounce cannot bounce, and a message arriving with an empty return path is an automatic report rather than mail somebody wrote.

How to read the return path on a message you already sent

The fastest check is on a real message rather than in DNS, because the return path only exists once a receiver has written it down.

1. Send yourself a message through the platform you are checking, to a mailbox at a different provider.
2. View the original headers and find Return-Path. Gmail calls this "Show original"; most clients have an equivalent.
3. Compare its domain to the From domain. Identical is strict alignment, a subdomain of your From domain is the normal relaxed case, an unrelated domain means SPF cannot contribute to DMARC at all.
4. Read Authentication-Results on the same message. The smtp.mailfrom property is the domain the receiver actually authenticated, which is the authoritative answer when it is present.
5. Repeat for every platform that sends as you. Each one has its own setting, and they are configured at different times by different people.

Return path alignment is one of two ways a message can satisfy DMARC, and the other one is DKIM, which survives forwarding where SPF does not. Our guide to email authentication covers how the three records depend on one another, and the quiet failure mode on the SPF side is the subject of our guide to the SPF include mechanism.

To see both identifiers on a real message next to everything else a receiver scores, run a free spam test.