Return-Path Header: What It Is and Why It Matters for SPF and DMARC

The email Return-Path header holds the envelope sender address, the one given in the SMTP MAIL FROM command (RFC5321.MailFrom). The receiving server writes it into the message at final delivery. Bounces are sent to it, and SPF authenticates its domain. For DMARC, that domain must also align with the visible From domain, which is why most email providers let you set a custom Return-Path on your own subdomain.

If your SPF check passes but DMARC still fails, this header is almost always where to look.

Return-Path vs From vs Reply-To vs Sender

Four addresses can sit on one message, and they do different jobs. The Return-Path starts in the SMTP envelope, while the other three are message headers.

Address	What it is	Who sets it	Recipient sees it?	Used for
Return-Path (envelope from, MAIL FROM)	Where non-delivery reports go	Sending system, in the SMTP transaction; recorded as a header at final delivery	Rarely, only in the full header	Bounces, SPF, DMARC SPF alignment
From	The author of the message (RFC 5322 section 3.6.2)	The sender or the application	Yes	DMARC (the Author Domain), display
Reply-To	Where replies should go instead of From	The sender or the application	Only after clicking reply	Human replies
Sender	The agent that actually transmitted the message, when different from the author	The sending agent	Sometimes, by client	Attribution, mailing lists

RFC 5322 defines the last three: the From field “specifies the author(s) of the message”, while the Sender field “specifies the mailbox of the agent responsible for the actual transmission of the message.” The Return-Path is defined by SMTP, in RFC 5321.

How the Return-Path gets set

During an SMTP transaction, the sending system announces the envelope sender with the MAIL FROM command. Nothing in the message headers needs to match it. The server that makes final delivery then copies that address into a Return-Path: header at the top of the message.

RFC 5321 section 4.4 is explicit about this: “When the delivery SMTP server makes the ‘final delivery’ of a message, it inserts a return-path line at the beginning of the mail data.” It also says “A message-originating SMTP system SHOULD NOT send a message that already contains a Return-path header field.” In practice, you do not write a Return-Path header yourself. You choose the envelope sender, and the receiving server writes the header.

The same section states its purpose: “The primary purpose of the Return-path is to designate the address to which messages indicating non-delivery or other mail system failures are to be sent.” Any bounce-back message goes there, whether it reports one of the soft and hard bounces or something else.

The null reverse-path

Bounce messages themselves are sent with an empty envelope sender, written MAIL FROM:<>. RFC 5321 section 3.6.3 says that “SMTP servers MUST NOT send notification messages about problems transporting notification messages,” and gives the null reverse-path as one way to prevent loops. Section 4.5.5 lists the other notifications that use it. If you see Return-Path: <> on a message, it is a bounce or delivery notice, not regular mail.

Why providers use addresses like bounce+id@

Email providers usually encode a message identifier into the local part of the envelope sender, a pattern often called VERP. When a bounce arrives at [email protected], the provider can match it to one recipient and one send without parsing the bounce text. This is also why the Return-Path rarely looks like your From address.

Return-Path, SPF and DMARC alignment

SPF checks the domain in the envelope sender. RFC 7208 section 2.4 says verifiers check the MAIL FROM identity, and when the reverse-path is null, “the mailbox composed of the local-part ‘postmaster’ and the ‘HELO’ identity” is used instead. The visible From address is not part of the check, which is covered in more detail in the SPF record guide.

DMARC adds the missing link. RFC 9989 says a DMARC pass “requires not only an SPF or DKIM pass verdict for the email message but also and more importantly that the domain associated with the SPF or DKIM pass be ‘aligned’ with the Author Domain.” Alignment is relaxed when both share an Organizational Domain, and strict when they are identical.

An SPF pass is not a DMARC pass. SPF can pass for the Return-Path domain while DMARC fails, because DMARC also requires that domain to align with the From domain.

Worked example: default vs custom Return-Path

Say you send from [email protected] through a provider. With the provider’s default bounce domain, the delivered headers look like this:

Return-Path: <[email protected]>
From: Example <[email protected]>
Authentication-Results: mx.recipient.test;
  spf=pass smtp.mailfrom=mail.esp-example.net;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

SPF passes, but for esp-example.net, so SPF contributes nothing to DMARC here. DMARC still passes in this example only because DKIM is signed with d=example.com. Remove or break that signature and the same message fails DMARC.

With a custom Return-Path on your own subdomain:

Return-Path: <[email protected]>
From: Example <[email protected]>
Authentication-Results: mx.recipient.test;
  spf=pass smtp.mailfrom=bounces.example.com;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

Now bounces.example.com and example.com share the Organizational Domain, so SPF aligns under relaxed mode. Either mechanism can carry DMARC. Under strict alignment (aspf=s) the subdomain would not align, so strict SPF alignment and a bounce subdomain do not mix.

Because DKIM alignment alone can satisfy DMARC, a custom Return-Path is not strictly required to pass. It gives you a second path if the DKIM signature breaks, and it puts bounce handling under a domain whose reputation you own instead of the provider’s shared one.

How to set a custom Return-Path with common providers

Each provider uses its own name for the feature and its own DNS records. The names below come from their current documentation.

Provider	What it calls it	DNS records	Where to configure
Amazon SES	Custom MAIL FROM domain	MX 10 feedback-smtp.region.amazonses.com and TXT "v=spf1 include:amazonses.com ~all" on the MAIL FROM subdomain	SES console, Identities, choose a verified domain identity (or the SetIdentityMailFromDomain API)
Postmark	Custom Return-Path	CNAME from your chosen alias (default pm-bounces) to pm.mtasv.net	Signatures, DNS Settings on the domain, Return-Path section
Twilio SendGrid	Domain authentication, with an optional custom return path	With automated security on: CNAME records, including one that supports SPF and DKIM. With it off: an MX record plus SPF and DKIM TXT records	Settings, Sender Authentication, Domain Authentication, Advanced Settings, “Use custom return path”

Amazon SES also offers a fallback if the MX record is wrong: you choose between “Use default MAIL FROM domain” and “Reject message” under “Behavior on MX failure”. Pick the default option only if you accept that SPF alignment is lost while the record is broken.

The steps are the same everywhere:

1. Pick a dedicated subdomain, for example bounces.example.com. Do not reuse the domain that receives your regular mail.
2. Publish exactly the records your provider shows for your account in your DNS zone.
3. Verify the domain in the provider’s dashboard.
4. Send a test message to a mailbox you control and read the headers.

How to check your Return-Path

Open the message and view the full header. Then:

1. Find the Return-Path: line and note its domain.
2. Compare it with the domain in From:. Same Organizational Domain means relaxed alignment is possible.
3. Find Authentication-Results: and read smtp.mailfrom=. That is the domain SPF evaluated, and it should match the Return-Path domain.
4. Check spf= and dmarc= in the same line.

Aggregate DMARC reports show the same alignment failures in bulk, across every receiver. If you manage a sending domain at scale, Google Postmaster Tools is where you verify the domain and watch its reputation.

Why SPF alone does not protect the From address

The Return-Path can be any domain an attacker controls. RFC 9989 section 4.4.2 puts it plainly: “any Domain Owner, even a bad actor, can publish an SPF record for its domain and send an email that will obtain an SPF ‘pass’ result.” A spoofed message can therefore pass SPF while showing your domain in From. That gap is the reason DMARC requires alignment: only an SPF-authenticated identifier that aligns with the Author Domain validates the use of that domain. For the wider picture, see email authentication.

Frequently Asked Questions