我们有一个类似于 CRM 应用程序的 Web 应用程序。人们可以登录并管理与其他人的业务。作为管理的一部分，我们的应用程序可能会向被管理的人发送电子邮件。这里的问题是，我们的客户喜欢这些电子邮件的“发件人”地址是他们自己的。这样，收件人就会收到来自他们认识的人的电子邮件，而不是来自我们自己域中的“请勿回复”地址。
对于许多邮件服务器来说这不是问题，但是有一些邮件服务器会退回这些邮件。出于好奇，我收到了一封测试邮件并检查了邮件头。以下是 Google Apps 添加的内容：
Received-SPF: softfail (google.com: best guess record for domain of transitioning [email protected] does not designate 99.99.184.164 as permitted sender) client-ip=99.99.184.164;
Authentication-Results: mx.google.com; spf=softfail (google.com: best guess record for domain of transitioning [email protected] does not designate 99.99.184.164 as permitted sender) [email protected]
（我将真正的“发件人”地址替换为[电子邮件保护]）
因此，虽然电子邮件已发送给我，但我当然可以理解为什么其他服务器可能会拒绝它。我们的应用程序永远不会解析到 clientdomain.com。
我在这里有什么选择？
1) 我可以建议将所有“发件人”地址设置为客户的友好名称，但使用我们自己的“无回复”电子邮件地址。然后我就可以获取 spf 和所有相关内容。
2）我可以建议客户端配置 spf / 反向 dns 以匹配我的服务器的 IP（这似乎是一个糟糕的选择......）
还有什么？这种事情的最佳做法是什么？
答案1
您可以做的一件事是将发件人的“姓名”设置为您的客户的姓名，然后设置回复标头以转到他们的电子邮件地址。
这样，他们就会觉得好像收到了一封来自他们认识的“鲍勃·约翰逊”的电子邮件，当他们点击“回复”时，邮件地址就会变成[电子邮件保护]
虽然我知道像 Paypal 这样的公司可以从您的实际电子邮件地址发送电子邮件，但我不确定这是否是标题的欺骗，或者所有电子邮件提供商都“信任”paypal 的电子邮件服务器。
答案2
SPF/域密钥均适用于信封发件人地址，而不是收件人看到的电子邮件中的发件人地址。
因此，您可以简单地使用信封发件人作为您域中的有效电子邮件 ID，并将发件人保留为您的客户端电子邮件 ID。
这样，SPF/域密钥仍然会通过。
至于其他最佳实践，请查看此电子邮件服务器测试。
答案3
看http://www.openspf.org/Best_Practices/Webgenerated
egreetings.com 的做法是：
在你的域名中选择一个通用地址（[电子邮件保护])。
将“MAIL FROM”更改为该地址。
添加“发件人”标题以显示发送邮件的收件人。“发件人”是标准字段；请参阅 RFC 5322。evite.com 的做法是：
在您的域中选择一个通用地址（[电子邮件保护])。
将“MAIL FROM”更改为该地址。
将“发件人”标题更改为该地址。
添加包含用户电子邮件地址的“回复”标题。
答案4
据我了解，至少对于 SPF，他们需要将您的邮件服务器添加到允许的服务器列表中。
这就是 foo.com 所有者所说的重点，即您是 foo.com 的授权电子邮件服务器
您不需要有到其邮件服务器的反向 DNS，但您的邮件服务器应该正确 HELO，并且该反向 DNS 应该正确。因此，只要 foo.com 的 SPF 允许 bar.com 作为中继，就可以接受将 HELO 为 bar.com，具有 bar.com 的反向并为 foo.com 发送邮件。