# Return-path: Definition and How It Works

Source: https://wraps.dev/glossary/return-path

Authenticationenvelope senderMAIL FROM address

The return-path is the envelope-level sender address SPF actually checks and where non-delivery bounces are sent — distinct from, and invisible next to, the visible From address a recipient reads.

## Two different senders exist on every message

Every email carries two sender identities: the visible \`From:\` header, rendered by the recipient's mail client, and the envelope sender established during the SMTP \`MAIL FROM\` command, which most mail clients never display at all. The return-path is that second, invisible address. They are frequently the same domain and sometimes not — a marketing platform sending on your behalf, for instance, commonly uses its own return-path while your domain stays in From:.

## This is the address SPF actually authenticates

SPF's DNS lookup is performed against the return-path domain, not the From domain — a detail that surprises people who assume SPF is checking the address they see in their inbox. This is exactly why DMARC alignment exists as a separate step: it is the mechanism that requires the return-path domain (when used for SPF) to actually relate back to the visible From domain, rather than trusting an SPF pass against an arbitrary, unrelated domain.

## A custom return-path needs its own DNS records

By default, SES sends bounces through its own shared MAIL FROM domain (something under \`amazonses.com\`), which works but means the return-path domain doesn't share reputation with your sending domain and can't itself be covered by your SPF record for alignment purposes. Configuring a custom MAIL FROM subdomain fixes that, but that subdomain needs its own MX record pointing at the region's SES inbound endpoint and its own SPF TXT record — separate records from the ones your main sending domain uses. SES reports the domain as pending until both resolve, and a message sent while pending fails with \`MailFromDomainNotVerifiedException\`.

## It's also literally where bounces go

When a recipient's mail server can't deliver a message, the non-delivery report goes to the return-path address, not to the visible From address — which is the entire reason it is sometimes also called the bounce address. A return-path that nobody monitors, or that points at a domain incapable of receiving mail, means bounce information is generated and then silently discarded rather than feeding back into list hygiene.

## Why it matters

Confusing the return-path with the From address is the single most common reason someone insists "SPF is definitely set up correctly" while a receiver's DMARC evaluation disagrees — both statements can be true at once, because they are checking two different addresses on the same message.

## How to check it

```
dig +short MX mail.example.com
```

## Common questions

### Is the return-path the same as the From address?

Not necessarily, and often not. The return-path is the invisible envelope-sender address established at the SMTP protocol level; the From address is what the recipient's mail client actually displays. They're commonly different domains when a third-party platform sends on your behalf.

### Why does SES need a custom MAIL FROM domain at all?

Without one, bounces and SPF checks run against SES's own shared MAIL FROM domain, which doesn't share reputation with your sending domain and can't be covered by your own SPF record. A custom MAIL FROM domain lets SPF alignment actually reflect your domain's reputation.

### What happens to bounce reports if nobody monitors the return-path?

They're generated and then effectively discarded — the non-delivery report has nowhere useful to go, so hard bounces never make it into list hygiene, and a sender keeps mailing addresses that are provably dead.