我们有一个类似于 CRM 应用程序的 Web 应用程序。人们可以登录并与其他人一起管理他们的业务。作为该管理的一部分，我们的应用程序可能会向被管理的人发送电子邮件。这里的问题是我们的客户喜欢这些电子邮件的“发件人”地址是他们自己的。这样，收件人就会从他们认识的人那里收到电子邮件，而不是来自我们自己域中的“不回复”地址。
对于许多邮件服务器，这不是问题，但是有一些会退回这些电子邮件。出于好奇，我收到了一封测试电子邮件并检查了标题。以下是谷歌应用程序添加的内容：
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]
（我用 [email protected] 替换了真正的“发件人”地址）
因此，当电子邮件发送给我时，我当然可以看到为什么其他服务器可能会拒绝它。我们的应用永远不会解析到 clientdomain.com。
我在这里有什么选择？
1）我可以建议将所有“发件人”地址设置为客户的友好名称，但使用我们自己的“无回复”电子邮件地址。然后我可以得到 spf 和所有的连接。
2）我可以建议客户端配置 spf / reverse dns 以匹配我的服务器的 IP（这似乎是一个可怕的选择......）
还有什么。这种事情的最佳实践是什么？
SPF/域键都适用于信封发件人地址，而不是收件人看到的电子邮件中的发件人地址。
因此，您可以简单地将信封发件人用作域中的有效电子邮件 ID，并将发件人保留为您的客户电子邮件 ID。
这样 SPF/Domain Keys 仍然会通过。
至于其他最佳实践，请查看此电子邮件服务器测试。
您可以做的一件事是将发件人的“姓名”设置为您客户的姓名，然后设置一个回复标题以转到他们的电子邮件地址。
这样一来，他们看起来就像收到了一封来自他们认识的“Bob Johnson”的电子邮件，当他们点击回复时，邮件将被发送至 [email protected]
虽然我知道像 Paypal 这样的公司可以让电子邮件来自您的实际电子邮件地址，但我不确定这是否是标题的诡计，或者所有电子邮件提供商都“信任”paypal 的电子邮件服务器。
见http://www.openspf.org/Best_Practices/Webgenerated
SPF 和 DomainKeys 旨在防止您正在做的事情——使用您不拥有的发件人地址发送邮件。
我不相信你可以做很多事情来绕过它，因为它是为了不被绕过。
您可以为每个用户提供一个本地电子邮件地址，该地址仅转发到相应的 gmail 或其他帐户，以便回复工作，并将其用作发件人地址。你需要做更多的工作。
此外，您也许可以使用“重新发送”标题。
据我了解，至少对于 SPF，他们需要将您的邮件服务器添加到允许的服务器列表中。
这就是 foo.com 的所有者说您是 foo.com 的授权电子邮件服务器的全部意义所在
您不需要对他们的邮件服务器使用反向 DNS，但您的邮件服务器应该正确地 HELO 并且反向 DNS 应该是正确的。所以 HELO 可以接受 bar.com，反向 bar.com 并为 foo.com 发送邮件，只要 foo.com 的 SPF 允许 bar.com 作为中继。
请参阅http://blogs.crsw.com/mark/archive/2006/07/06/2032.aspx。
“MAIL FROM”的内容是 Envelope From，用于 SPF Checking。接收者看到的是 AFTER DATA 命令给出的内容。
它们不需要相同。