Return-Path: the address you never see that decides your bounces
The campaign goes out at nine. The open chart climbs, the panel shows green bars, and at the same moment a few hundred messages come back to the server with an error message nobody reads. Those returns are addressed to Return-Path – the address you cannot see in a mail client, the one most senders remember only once deliverability drops. And no, it is not the same address the recipient sees in the “from” field.
Return-Path is not the address the recipient sees
Every message carries two independent sender addresses. The first is From: a message header, the one displayed in the list in your mail program. The second is Return-Path, the SMTP envelope – the MAIL FROM command sent during the session with the recipient server. They can point at two completely different domains and nobody will notice with the naked eye.
The difference is functional, not cosmetic. From addresses a human. Return-Path addresses a machine: that is where bounces go back, along with full mailbox notices and block messages. Servers talk to each other on that channel and they do not look inside the content while doing it.
Mail clients hide this header by default. Gmail, Outlook, Thunderbird – everywhere you have to open the message source separately. The result? The configuration sits on the platform defaults for years, bounces land in a mailbox that does not exist, and the problem surfaces only when deliverability falls or at the first authentication audit.
Below we show what to check in your own sending, how to tie the return address to SPF, DKIM and DMARC, and what to do with bounces so they do not damage sender reputation. No theory you cannot implement right away.
SMTP envelope versus message headers
The simplest model: the envelope is the address written on the envelope of a letter, the headers are what is printed on the sheet inside. The postman reads the envelope. The content is read only by the addressee.
In the SMTP protocol it works like this. The MAIL FROM command sets the return address, the future Return-Path. The RCPT TO command sets the envelope recipient. Only after that, following the DATA command, does the server receive the From, To and Subject headers and the whole body. And those headers are plain text inside the shipment – you can put anything in them, transport still follows the envelope.
The order has consequences. The recipient server makes its first decisions before it sees a single line of headers: it checks the sender IP address, the name from HELO, the domain from MAIL FROM. A rejection at that stage means your carefully chosen sender name did not matter at all. Not at all.
The Return-Path header itself is added by the receiving server at delivery, copying into it the value from MAIL FROM. That is why the address in the “from” field can be perfect, consistent with the brand and signed with DKIM, and the campaign still goes to rejections.
Tip: open any message from your sending platform, choose “show message source” and read the header section. If Return-Path holds the provider domain instead of yours, you have the answer to why SPF does not work the way you assumed.
SPF checks Return-Path, not the sender address
This is the most common misunderstanding we see in audits. The client added an SPF record to the domain from the From field, saw a green result in an online tool and considered the subject closed. But SPF verifies the domain from MAIL FROM, that is from Return-Path. The record has to sit at that domain, not at the one the recipient sees.
DKIM works differently. It signs the content and selected headers with a key whose public part sits in DNS. The envelope is none of its business, so the signature passes regardless of what was set in MAIL FROM.
DMARC ties it all together, and its core is alignment. SPF counts towards DMARC only when the Return-Path domain matches the domain from From. Same with DKIM: the signature has to come from a domain aligned with From. The default return address of a sending platform breaks SPF alignment – technically SPF passes, but for DMARC it is useless. The whole weight then falls on DKIM, and one badly copied value in DNS overturns authentication completely.
The practical conclusion is short. Return-Path on your own subdomain plus DKIM on the main domain gives you a setup that passes DMARC by two routes. One can fail and the sending still authenticates. The cheapest redundancy you can buy with a DNS entry.
Your own return address: subdomain, records, PTR
Implementation is a few steps in this order:
- Carve out a technical subdomain, for example bounce.yourdomain.com, dedicated exclusively to sending.
- Point it with records at the sending infrastructure that will receive the returns.
- Add an SPF record at that subdomain, listing the real sending sources in it.
- Set DKIM on the main domain, the same one that stands in the From field.
- Add a DMARC record with a policy and an address where the reports should go.
A separate subdomain keeps the reputation of bulk sending apart from company mail. When the newsletter takes a hit for a messy list, sales correspondence from the main domain still gets through. Without that separation one bad import can make life hard for the whole company.
On the sending server side there are PTR and rDNS. The IP address has to resolve to a name, and that name back to the same address. Plus consistent naming: HELO/EHLO, PTR and the Return-Path domain should belong to one world. A mismatch here is read by the big filters as a warning sign.
We run our own fleet of sending servers and after years of configuration we keep seeing the same thing: the work is done by DNS records and consistency in naming, not by tricks. We described the technical details in the sending authentication setup in MailCraft. The full procedure is in the description of setting up SPF, DKIM and DMARC step by step.
Tip: after changing the return address, send a test campaign to your own mailboxes at several large providers and read the headers. The Authentication-Results section will tell you straight away whether SPF passed on the right domain.
Bounces: what comes back to Return-Path and what to do with it
All the diagnostics of a campaign come back to the return address. Three situations have to be told apart.
A hard bounce means a permanent state: the address does not exist, the domain does not answer, the mailbox was deleted. You remove such a record from the list immediately, with no second chance. A soft bounce is a temporary problem: full mailbox, overloaded server, a limit on the recipient side. Here you retry and count the failed attempts, and after a series of further failures you exclude the address as well. A reputation rejection concerns not the addressee but you: a block on the whole IP or domain, usually with a code and a description in the body of the return. Each of these cases needs a different reaction, which we take apart in the text on the differences between a hard bounce, a soft bounce and a reputation block.
The first piece of diagnostic information is the SMTP code. The 4xx range says “try later”, 5xx says “do not come back”. The second is the text of the message, because that is where providers write the specifics: unknown user, limit exceeded, address on a blocklist, a link to a page with an explanation.
A Return-Path mailbox without automatic processing is a rubbish bin. Bounces are supposed to feed the suppression list, otherwise the same dead list rides along in the next campaign. The industry standard for matching a return to a specific recipient is VERP, a unique return address generated for every sending-recipient pair. Then you do not have to parse the text of the message to know who to exclude. You will find bounce handling and suppression lists in the platform feature overview.
A high share of hard bounces lowers sender reputation faster than weak content. Filters will forgive a boring newsletter. They will not forgive sending to addresses that have not existed for two years.
When Return-Path saves a campaign and when it is no longer enough
A correct return address puts authentication and list hygiene in order. But it is not a switch to the inbox and it will not replace what you do with your recipient list.
A new domain and fresh IP addresses need warming up. Volume grows gradually, and you start with the most active recipients, the ones who open and click. Their behaviour builds the history filters use to judge the next campaigns.
Blocks at large providers have happened to us too. Getting out of them looks the same every time: cut the volume, clean the list, file a request with the provider, be patient. There is no shortcut and no phone call to a friend. No configuration bypasses spam filters and nobody serious promises that, us included.
The foundation remains the recipient’s consent. GDPR requires a legal basis for processing, and PKE article 398 requires consent for sending commercial information. This applies to B2B contacts as well, contrary to the popular belief that a company address is a free-for-all.
Honestly about where we stand: part of the bounce handling automation is in the panel, part is on the roadmap. We would rather write that than add a feature to the description and then explain ourselves during onboarding.
Summary: a short checklist
To check today:
- where your Return-Path points – your own domain or the provider’s,
- whether that domain has an SPF record with the real sending sources,
- whether DKIM signs a domain aligned with the From field,
- whether DMARC sees alignment by at least one route,
- whether PTR matches the server name and the HELO,
- whether bounces go onto the suppression list automatically.
Final tip: turn on DMARC reports even with a none policy. It is the only source of information about who sends in your name, and usually the first place where you see unknown servers using your domain.
If you send from your own CRM or shop, check as well how the return address is set by your connection with external systems – the default settings of plugins tend to be the weakest link here.
The address you cannot see decides whether your mail arrives at all. If you want someone to go through the headers and DNS records with you before the next campaign, write to us.
