Skip to main content

​
What is the Return-Path?

The Return-Path (also called the envelope sender, bounce address, or MAIL FROM) is the email address where bounce notifications are sent when an email can’t be delivered. It’s a hidden header — recipients don’t see it, but mail servers use it for routing bounce messages. It’s separate from the From header that recipients see in their inbox.

​
Return-Path vs From

HeaderWho sees itPurposeExample
FromThe recipientDisplays the sender in the inboxhello@acme.com
Return-PathMail servers onlyReceives bounce notificationsbounces@send.acme.com
These are often different addresses. When you send through SendKit, the From address is your sender (e.g., hello@acme.com), but the Return-Path is set to a SendKit address on the send subdomain so we can process bounces for you.

​
How it works

1

You send an email

The email has From: hello@acme.com and Return-Path: bounces@send.acme.com.
2

Recipient's mail server receives it

If delivery succeeds, the process is complete.
3

If delivery fails (bounce)

The bounce notification is sent to the Return-Path address: bounces@send.acme.com.
4

SendKit processes the bounce

The email is marked as bounced, the email.bounced webhook fires, and the address is added to the suppression list (if hard bounce).

​
Return-Path and SPF

SPF authentication checks the Return-Path domain, not the From domain. This is an important distinction. When SendKit sends an email from hello@acme.com with a Return-Path of bounces@send.acme.com, the receiving server checks the SPF record of send.acme.com — not acme.com. This is why SendKit asks you to add the SPF record on the send subdomain:
Header checkedDomain checkedDNS record location
Return-Path: bounces@send.acme.comsend.acme.comSPF TXT record on send.acme.com
And why DMARC’s alignment check matters — it verifies that the Return-Path domain and the From domain are related. Since send.acme.com is a subdomain of acme.com, relaxed alignment passes.

​
Custom Return-Path

By default, SendKit uses the send subdomain for the Return-Path (e.g., bounces@send.acme.com). This is automatically configured when you verify your domain. The send subdomain was chosen because:
  • It clearly identifies the purpose (sending email)
  • It keeps bounce handling separate from your main email
  • It doesn’t interfere with your root domain’s email configuration

​
Why the Return-Path matters

​
1. Bounce processing

Without a proper Return-Path, bounce notifications have nowhere to go. You’d lose visibility into delivery failures, and your list would accumulate invalid addresses — destroying your reputation over time.

​
2. SPF alignment

SPF checks the Return-Path domain. If the Return-Path domain doesn’t have an SPF record or it doesn’t include the sending server, SPF fails.

​
3. DMARC alignment

DMARC checks that the Return-Path domain (SPF) or DKIM domain aligns with the From domain. For SPF alignment, the Return-Path domain must match or be a subdomain of the From domain.

​
FAQ

The Return-Path subdomain is send by default when you verify a domain in SendKit. This is configured automatically when you add the required DNS records.
This is normal and expected when using an email service like SendKit. The Return-Path is set to a SendKit-managed address so that bounce notifications are routed to SendKit for processing. DMARC alignment ensures the two domains are related (via subdomain matching).
No. The Return-Path is part of the email’s hidden headers. Recipients only see the From address. Some email clients let you view full headers (which includes the Return-Path), but this is not shown by default.