我为其中一个域设置了Google Apps帐户。 所有电子邮件都会在此域中启用通配符电子邮件传递（即[email protected]将电子邮件传递到[email protected]），并且与电子邮件传递相关的loggingconfiguration如下（据我所知，已configuration根据Google的build议）：
MX: ASPMX.L.GOOGLE.COM with priority 10 TXT: v=spf1 include:_spf.google.com ~all TXT: v=DKIM1; k=rsa; p=xxxxxxxxxxxxxxxxxxxxxxxxx 然而，最近我已经开始接收到来自我的域名的使用电子邮件地址的人显然被垃圾邮件发送的反弹/“不在办公室”电子邮件数量的增加。 从反弹，一些标题：
Return-Path: <[email protected]> Received-SPF: softfail (google.com: domain of transitioning [email protected] does not designate 41.230.231.130 as permitted sender) client-ip=41.230.231.130; Authentication-Results: gmr-mx.google.com; spf=softfail (google.com: domain of transitioning [email protected] does not designate 41.230.231.130 as permitted sender) [email protected] From: "Secure.Message" <[email protected]> To: <[email protected]>
（如果需要，我可以提供额外的标题。）
我看着软弱，但我不完全确定我明白这一点。 我做通配符的电子邮件到域，所以简单地禁用通配符可能不是一个解决scheme。 因为到这个域名的电子邮件然后被转发到不同的电子邮件地址（尽pipe在Google Apps中），但是我最好还需要能够使用Google的“发送电子邮件为”（“代表”）function发送电子邮件。
任何想法现在要做什么？ 最重要的是我关心我的领域的声誉; 我非常想保留它的任何垃圾邮件名单。
当您在SPF机制中使用SoftFail限定符（ ~ ）时，您指示匹配的发件人应该被怀疑处理 ，但不能被直接拒绝。
另一方面， Fail限定符（ - ）鼓励接收MTA通过5.1.7 DSN 立即拒绝SMTP传输 。
因此，当您在logging末尾使用〜all时，您只是部分地阻止垃圾邮件发送者滥用您的域名和声誉。
请阅读更多关于如何根据RFC规范对check_host（）结果进行处理的内容： IETF RFC 4408§2.5“解释结果”
除了马蒂亚斯所说的（这是好的）之外，请注意关键词在他的第二个句子鼓励 ：“失败限定词…鼓励接收MTA拒绝电子邮件”。
我也build议调查DMARC 。 一旦您拥有了SPF和DKIMlogging，听起来就像您一样，DMARC是一种告诉接收邮件服务器如何处理电子邮件的方式， 这既可以防止SPF和DKIMtesting。
当一封电子邮件通过这些testing失败，并且接收MTA授予DMARClogging，那么您可以控制他们对该电子邮件的处理方式：彻底拒绝，将其标记为垃圾邮件或发送。
我处于完全相同的情况，并改变了我的SPFlogging，以执行严重失败。 这没有帮助。 发送反弹回复的域的pipe理员似乎查看了spflogging，发现失败，然后忽略它。 我不担心我的域名，因为他们会继续发送这些邮件，不pipe我是否在这里看到反弹。 没有什么可以做的，但是做一个规则来忽略回复的地址模式。