How can the Return-Path header be different than the actual email bounce recipient?

I recently moved my transactional email sending to Mailgun

It works good so far however I am wondering about the return-path header.

Consider this email (I removed irrelevant header and replaced email/domain for privacy purposes)

Received-SPF: ...stripped...
DomainKey-Signature: ...stripped...
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Subject: ...stripped...
From: my-website <[email protected]>
To: [email protected]
Message-Id: <[email protected]>
Date: Wed, 04 Sep 2013 12:04:43 +0000
Sender: [email protected]
Content-Transfer-Encoding: base64

...email body...

This is the Raw email displayed from an actual mail in a gmail inbox. As you can see the Return-Path header contains an email address that ends in @my-website.com

But I have only set up dns records for outgoing email (spf, domainkey, etc). Not for incoming email. Meaning, my MX records still point to mailservers somewhere else (In my case google apps).

How is it possible then that the bounce email arrives at mailgun servers?

I would have expected to see an email address ending in @some-mailgun-server.com in the Return-Path header!

I have been using Amazon SES before, and there they had Return-Path header ending in amazonses.com

I asked the mailgun support and got this response:

Nick: your setup is correct, Mailgun will still automatically handle the bounces even though your mx records are pointing elsewhere

They just assured me that everything was fine but gave me no explanation (which is okay since their job is not to teach me things I don't know but to deliver reliable email service...)

So I hope somebody can explain this to me.

I hope the point is clear, if not please ask and I will try to clarify my question.

EDIT:

One theory of me is that the bounce email is indeed sent to google mail servers where it is discarded. However that this is redundant since the error response is also sent to the sending mailserver during the process (when it opens its tcp connection to the target mail server).

To test this theory and since the Return-Path email is in the form of [email protected], and google delivers all email, regardless of what comes after the + character, to the user in front of it, I went ahead and created the account [email protected] on google apps.

I also tried to send an email to [email protected].

It made it through to my inbox.

Now I expected to receive bounce traffic in my inbox. So I sent an email to an nonexistent hotmail address. I did not receive email on my google apps inbox, and mailgun successfully tracked the bounce.

So... It appears that it does indeed work. I just don't understand why.

One more theory I have is that the mailserver to which the bounce email is delivered is never resolved using its MX records. Rather always the delivering server, in this case luna.mailgun.net is chosen. The domain ending in the Return-Path address is just the name of the mailbox on the server, but the domain has nothing to do with the server where the mail is actually delivered.

Then it would also make sense to make it like this since it might improve deliverability if the domains of From and Return-Path address match.

However this is only a theory. And it would also mean that a mailbox which is able to receive bounces, must be on the same server that is used for sending.

In other words it would be impossible to have a mailbox to receive bounce email addresses that is hosted somewhere else than the actual server sending the mail. But this sounds strange to me as well...

I hope somebody can enlighten me.

Turns out that there are different kinds of bounces.

When bounces occur they are generally returned to the server that is sending the email, and do not follow the MX records.

Thats why they are sent to the mailgun servers and also arrive there.

However there are also so called "Delayed Bounces" that are sent to the server declared as mailserver using MX records in the domain.

Those delayed bounces are generally difficult to handle and there are opinions out there that they violate RFC.

Those bounces are however very, very rare. Thats why mailgun does not handle them. The reason they use the clients domain in the return-path address is so that they can assign it to the right account. They just encode it that way...

In fact, as I was setting up my mailbox for bounces on my google apps mail, I recieved one such delayed bounce.

It was this email that made proper debugging possible which lead to the understanding of this issue.

So to sum up:

Yes, the address is incorrect. That is no problem for most bounces since the server does not use MX records to send them, but sends them directly to the server that has initated the conneciton.

However in case of delayed bounces, that also some times happen, the bounce will indeed go to the server behind the mx records of the domain specified in the return path address.

Those emails are not properly recognised as bounces at mailgun servers.

Recommended topics

Hot tags