我想知道让我的邮件服务器代表客户的域发送电子邮件的最佳方法,而不会被列入灰名单,同时也避免退回问题。
我一直在阅读其他一些问题这里,这里和这里但没有一个能探索所有可能的解决方案。以下是我想比较的一些可能性:
A。
HELO mymailserver.com
MAIL FROM<[email protected]> # mymailserver.com same IP as myapp.com
DATA
From: <[email protected]>
Sender: <[email protected]>
问题:这是 gmail 所做的。消息标题“发件人:”具有不同的域,而不是信封发件人。emailclients
将显示“从:[电子邮件保护]通过[电子邮件保护]“或者
“从:[电子邮件保护]代表[电子邮件保护]“,即不是对我来说是个问题。
那么,标题“发件人:”有不同的域名,这会严重影响我的域名声誉吗?(如果不是 Google 做的...)
B.
HELO mymailserver.com
MAIL FROM<[email protected]>
DATA
From: <[email protected]>
# same as A, but no "Sender:"
谷歌似乎曾经这样做过,并称这是一个错误
http://groups.google.com/group/Gmail-Help-Message-Delivery-en/browse_thread/thread/f651cb1db5d9dd23/3a8bcd0548487863?lnk=gst&q=%22on+behalf+of%22&pli=1
一个错误从他们的消息中删除了“发件人:”,并且“通过”未显示在电子邮件客户端中。(RFC 规定,如果它与“发件人:”不同,则必须存在)
C。
HELO mymailserver.com
MAIL FROM<[email protected]>
DATA
From: <[email protected]>
就好像 client.com 正在发送消息(MAIL FROM 也是“伪造的”)。但是,如果 client.com 域是众所周知的或在其 DNS 中有一个 SPF 条目,我必须更改其 DNS,允许 mymailserver.com 代表他们发送消息。(这对我来说是不可能的,因为客户数量有限,而且我的一些客户无法控制他们的域名,即他们自己使用 @gmail.com)
D.
HELO mymailserver.com
MAIL FROM<[email protected]>
DATA
From: <[email protected]>
Reply-to: <[email protected]>
问题:这是最简单的一个,我只会添加“回复:”标头。电子邮件客户端真的会一直考虑到这一点吗?这是否也会被视为欺骗,将不同的域添加到“回复”标头,并对我的域声誉产生不良影响?
- RFC 只说“如果回复字段存在,那么回复应该转到该字段中指示的地址,而不是发件人字段中指示的地址。”。-
只有“发件人:”标题标签会被“欺骗”:
“发件人:myclient.com(通过 myapp.com)<[电子邮件保护]> "。
答案1
好问题。我刚刚花了几个小时研究同样的事情。
我之前曾部署过许多使用选项 C电子邮件表单(主要是出于天真),但我们遇到的交付问题越来越多。电子邮件提供商正在逐渐收紧。例如Yahoo 最近更改了其 DMARC 政策要求接收者拒绝所有没有有效 DKIM 签名的电子邮件From: [email protected]
. 接收遵循 DMARC 的 SMTP 服务器(包括 Gmail,可能还有 Hotmail/Outlook.com 和 Yahoo)将硬退回这些邮件。我认为 eBay 和 Paypal 也有类似的严格政策,旨在减少网络钓鱼。不幸的是,指定“发件人”标头无济于事。
(我想知道 Gmail 在发送“发件人” Yahoo 别名时如何解决这个问题?!)
选项 A如果您知道“发件人”电子邮件没有严格的 DMARC 策略(您可以通过简单的 DNS 查询来确认这一点),这将是一个更好的选择。
尽管视觉上最不吸引人,选项 D 确实是最安全的这也是我将为我们未来的大多数项目推荐的方法。值得注意的是,PayPal 之前使用过选项 A,但现已转向选项 D。
为了获得更多的可信度和增加投递机会,我会考虑实施 SPF 和/或 DKIM。这些和其他事项在Google 的群发邮件发件人指南我觉得这很有帮助。
答案2
我不确定你想要什么。没有“安全”或“不安全”的方式来做你想做的事。
我总是更喜欢 D)。此外,我会添加 SPF 记录。但正如我所说,这并不比其他的更安全或不安全(无论您的意思是什么)。
Reply-To 标头不会以任何方式影响声誉。它仅建议客户端使用该地址进行回复(呃,也许这就是名称的由来?!)。如果客户端遵循此建议,则无法保证。
答案3
两种可靠的解决方案:
- 要求客户将您的邮件服务器添加到他们的 SPF 域记录中
- 要求客户向您提供电子邮件帐户凭据(他们的邮件服务器 IP、用户名、密码),并在您的应用程序中使用这些凭据连接到他们的邮件服务器并发送电子邮件(您实际上在您的应用程序中创建了一个电子邮件客户端)。