I was hoping to have a detailed post up today about the conditions where gmail presents the user with a “via” but time seems to have gotten away from me. But I can give you the conclusions.
- A via is presented to the user when you have a DKIM pass and the domain in the d= does not match the domain in the visible from address. In this case the interface shows via the d= domain.
- A via is presented to the user when you have a SPF pass, no valid DKIM (either a fail or no signature at all) and the domain in the return path is different than the domain in the visible from address. In this case the interface shows via the SPF domain.
This is an issue for ESP customers who are letting ESPs sign on their behalf. If your ESP is signing with their own domain, or their own domain is present in the return path, then all your mail will be displayed with “via” in the gmail interface.
In order to not have a via showing, you need to have either the return path or the d= value within the same domain as your visible from address. There are two ways to do this. Probably the easiest is to delegate a subdomain to your ESP so they can manage the signing and keys for you. Alternatively, you can manage DKIM keys yourself and just have your ESP sign with the private key you give them.
I have heard that recipients can remove the via by replying to a message or by adding the sender to their address books. My testing did not show that either method was effective in removing the “via” from the display.
Tomorrow, the work that went into these rather simple recommendations.
RSS - Posts
Thanks!
Do you know if the via is displayed if the DKIM d= matches the visible From but the SPF passes with a different domain? So first criteria you listed would not show a via, but since the second didn’t match, would the via display?
I’ll find out myself in the next couple of weeks, but thought I’d see if someone else knew already.
Via is not displayed in that case. As long as either SPF validation or DKIM validation point to the same domain in the visible From: there is no via. I’m working on the diagrams for that (those of you connected to be on FB have seen the chart).
Do you have these diagrams available? I am running into this issue where DKIM d= does not match but spf does and I am still seeing via.
The only time you should be seeing a via is when both domains are different from the domain in the visible from. You can see the condensed chart at https://skitch.com/wttwlaura/f5xf3/gmailauthentication.numbers
What does “domain match to display From” mean? Are you referring to the return-path/envelope sender domain?
My issue is sending with a return-path of x@xdomain.com with a DKIM d= of x@xdomain.com, but my display From is y@ydomain.com. y@ydomain.com does have the outgoing IP’s of x@xdomain.com published to y@ydomain’s SPF record, but I’m still seeing via. Did you test this specific scenario? (ie: am I just doing something wrong?)
Thanks for your research on this. You guys are a wonderful resource.
Display From is the address that the user sees when the look at the mail in their client. Domain match for DKIM means that the d= has the same domain. So if the user seems mail is from sender@wordtothewise.com and the d= is wordtothewise.com or foobar.wordtothewise.com then it matches. SPF focuses on the return path domain, and expects those to match as well.
Feel free to send an example mail to wttwlaura at gmail from the setup that’s causing the problems. Use “Blog and via” in the subject line (so I can find it 🙂 ). I’ll take a look at it and see if I can give you a hint as to what is broken.
Thanks for sharing this information, it’s really helpful. But there’s one thing I don’t understand: even though SPF authentication is passed, a via is added to mail sent from a webserver. The return-path is not the same as the visible from field, but there’s no way for me to change it. Does that mean I won’t be able to get rid of the via?
[…] was a question submitted today about the verification process at Gmail. even though SPF authentication is passed, a via is added to mail sent from a webserver. The […]