I wanted to know the best way to make my mailserver send emails on behalf of my clients' domains, without being greylisted and also avoiding bounce problems.
I've been reading some other questions here, here and here but none explores all the possible solutions. Here are some possibilities that I would like to compare:
A.
HELO mymailserver.com
MAIL FROM<[email protected]> # mymailserver.com same IP as myapp.com
DATA
From: <[email protected]>
Sender: <[email protected]>
Question: This is what gmail does. It's the msg header "From:" that has a different domain, not the envelope sender.
emailclients will show "From:[email protected] via [email protected]" or
"From:[email protected] On Behalf Of [email protected]", which is not a problem for me.
Now, will this affect badly the reputation of my domain, the fact that the header "From:" has a different domain? (and if it's not Google who's doing it..)
B.
HELO mymailserver.com
MAIL FROM<[email protected]>
DATA
From: <[email protected]>
# same as A, but no "Sender:"
It looks like Google once did this and called it a mistake
http://groups.google.com/group/Gmail-Help-Message-Delivery-en/browse_thread/thread/f651cb1db5d9dd23/3a8bcd0548487863?lnk=gst&q=%22on+behalf+of%22&pli=1
A bug removed the "Sender:" from their messages and the "via" didn't show up in the emailclient. (The RFC says that it MUST be present if it's not the same as the "From:")
C.
HELO mymailserver.com
MAIL FROM<[email protected]>
DATA
From: <[email protected]>
It's as if client.com were sending the message (the MAIL FROM is "spoofed" too). But if the client.com domain is well-known or has a SPF entry in its DNS, I would have to alter its DNS, allowing mymailserver.com to send message in their behalf.. (This is impossible for me because of the nb. of clients, and also some of my clients don't have control over their domains, i.e., are using @gmail.com themselves)
D.
HELO mymailserver.com
MAIL FROM<[email protected]>
DATA
From: <[email protected]>
Reply-to: <[email protected]>
Question: This is the simplest one, I would only add a "Reply-to:" header. Is this really taken into account ALL THE TIME by email clients? Can this be perceived as spoof too, adding different domains to the "Reply-to" header, and be a bad influence to my domain's reputation?
- The RFC only says that "if the Reply-To field exists, then the reply SHOULD go to the addresses indicated in that field and not to the address(es) indicated in the From field.".
- Only the "From:" header label would be "spoofed":
"From: myclient.com (via myapp.com) < [email protected]> ".
Excellent question. I've just spent several hours researching the same thing.
I had previously deployed numerous websites that use Option C for email forms (mainly out of naivety), but we are experiencing an increasing number of delivery issues. Email providers are gradually tightening up on things. For example Yahoo recently changed their DMARC policy to ask receivers to reject all emails
From: [email protected]
without a valid DKIM signature. Receiving SMTP servers that follow DMARC (which includes Gmail, and probably Hotmail/Outlook.com and Yahoo) will hard bounce these messages. eBay and Paypal have similar strict policies I believe, in an attempt to reduce phishing. Unfortunately specifying a "Sender" header does not help.(I wonder how Gmail works around this when sending "From" a Yahoo alias?!)
Option A would be a better option if you know the "From" email does not have a strict DMARC policy (you could possibly confirm this via a simple DNS query).
Despite being the least visually-appealing, Option D is really the safest and is what I will recommend for most of our future projects. It's worth noting that PayPal previously used Option A, but have now switched to Option D.
To gain additional credibility and increased chance of delivery, I would look at implementing SPF and/or DKIM. These and other things are mentioned in Google's Bulk Sender Guidelines which I found helpful.
I'm not sure what you want. There is no "safe" or "unsafe" way to do what you want.
I would always prefer D). Additionally I would add SPF records. But as I said this is not safer or unsafer than the others (whatever you mean with it).
The Reply-To header does not influence the reputation in any way. It only advices the client to use that address for replies (Duh, maybe this is where the name comes from?!). If the client follows this recommendation is not guaranteed.
Two reliable solutions: