Glossary

Return-Path where bounces go, not the From address

An email actually has two 'from' addresses. The one users see and the one the protocol uses for bounces. The protocol one is the Return-Path. Most deliverability headaches that look weird trace back to confusing the two.

HomeGlossaryReturn-Path

Definition

The Return-Path is the email address where bounce messages and delivery failures are routed. It's set during the SMTP conversation as the envelope MAIL FROM address. The receiving server adds it as a Return-Path: header on the delivered message. Crucially, it is not the same as the From address users see.

Why email has two "from" addresses

Email separates the envelope from the message, like a paper letter separates the outside of the envelope from the letter inside. The envelope's MAIL FROM (the Return-Path) is what the SMTP protocol uses for routing failures back. The message's From header is what mail clients display to recipients. They can be the same address. They can also be different, and on bulk or transactional mail they almost always are.

A typical setup: recipients see [email protected] as the From address. Bounces are routed to a per-message Return-Path like [email protected] so the sending platform can match them back to the right send. That's normal and correct.

SPF checks the Return-Path, not the From

This is the part that catches people. SPF authenticates the envelope MAIL FROM, which is the Return-Path. It does not check the visible From header. So you can have a perfectly valid SPF setup on your Return-Path domain and still fail DMARC if the From domain doesn't align with it. That's why DMARC alignment matters and why "SPF passes but DMARC fails" is so common when transactional mail is sent from one domain but Return-Path bounces to another.

Bounce processing is the practical reason

Sending platforms use per-message Return-Paths so that when a bounce comes back, they can match it to the exact message that bounced and update suppression lists. Routing bounces back to your support inbox would lose that traceability and dump bounce messages on humans who can't act on them. So the Return-Path points to an automated bounce-processing endpoint, and the From address stays human-friendly. That's not a hack, it's how the protocol is meant to work.

How sendmsg.io handles it

Return-Paths are set automatically per message and routed back to the bounce-processing pipeline, which updates suppression and signals the reputation engine on each bounce. You don't see it because you don't need to. Your From address stays whatever you configure for your customers. If you want to use your own bounce subdomain for SPF alignment, that's a one-time DNS setup. The free deliverability check will tell you whether your current alignment is clean.

Related reading

Ready to send with confidence?

Dedicated sending infrastructure with 5-level reputation protection and live domain health scoring. Your reputation is managed for you.