我们有一个Web应用程序，就像一个CRM应用程序。 人们可以login并与其他人pipe理业务。 作为该pipe理的一部分，我们的应用程序可能会将电子邮件发送给被pipe理的人员。 这里的皱纹是，我们的客户喜欢这些电子邮件的“发件人”地址是他们自己的。 这样收件人就可以收到他们认识的人的电子邮件，而不是从我们自己的域名的“不回复”地址。
对于许多邮件服务器来说，这不是一个问题，但是有一些反弹这些邮件。 出于好奇，我有一封testing邮件发送给我，并检查标题。 这是什么谷歌应用程序添加：
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]了真正的“from”地址）
所以，当电子邮件发送给我时，我当然可以看到为什么其他服务器可能会拒绝它。 我们的应用程序不会解决clientdomain.com。
我在这里有什么select？
1）我可以build议所有“发件人”地址设置为客户的友好名称，但用户自己的“无回复”电子邮件地址。 然后我可以得到spf和所有的连线。
2）我可以build议客户端configurationspf /反向DNS匹配我的服务器的IP（这看起来像一个可怕的select…）
还有什么。 这类事情的最佳做法是什么？
你可以做的一件事就是将发件人的“姓名”设置为客户的姓名，然后设置一个回复标题转到他们的电子邮件地址。
这样看起来他们收到了他们所知道的“Bob Johnson”的电子邮件，当他们点击“回复”时，将发送到[email protected]
虽然我知道像Paypal这样的公司可以有电子邮件来自你的真实的电子邮件地址，我不知道这是头脑的欺骗，或所有的电子邮件提供商“信任”贝宝的电子邮件服务器。
所有SPF /域密钥都可以在收件人看到的电子邮件中使用信封发件人地址而不是发件人地址。
因此，您可以简单地使用Envelope From作为您域中的有效电子邮件ID，并将From作为您的客户电子邮件ID。
这样SPF /域密钥仍然会通过。
至于其他最佳做法去看看这个电子邮件服务器testing 。
见http://www.openspf.org/Best_Practices/Webgenerated
egreetings.com这样做：
在您的域中select一个通用地址（[email protected]）。
将“MAIL FROM”更改为该地址。
添加一个“发件人”标题，以显示发送该邮件的收件人。 “发件人”是一个标准的领域; 请参阅RFC 5322。evite.com这样做：
在您的域名中select一个通用地址（[email protected]）。
将“MAIL FROM”更改为该地址。
将“发件人”标题更改为该地址。
添加一个包含用户电子邮件地址的“Reply-To”标题。
SPF和DomainKeys旨在防止你在做什么 – 使用你不属于的地址发送邮件。
我不相信你可以做的很多事情，因为它不打算得到。
你可以给每个用户一个本地的电子邮件地址，只是转发到适当的Gmail或其他帐户，所以答复工作，并使用它作为起始地址。 这是你的更多的工作。
此外，您可能可以使用“重新发送”标题。
据我所知，至less对于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检查。 接收者看到的是数据命令后给出的内容。
他们不需要是一样的。