我为我的一个域设置了一个 Google Apps 帐户。此域上的所有电子邮件均启用了通配符电子邮件传递功能(即。[电子邮件保护]发送电子邮件至[电子邮件保护]),邮件投递相关的记录配置如下(据我所知,是按照Google的建议配置的):
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]>
(如果需要,我可以提供额外的标题。)
我研究了软故障,但并不完全确定我理解了它。我确实向该域发送了通配符电子邮件,因此简单地禁用通配符可能不是一个解决方案。由于发送到此域的电子邮件随后会被转发到另一个电子邮件地址(尽管也在 Google Apps 内),因此我最好还需要能够使用 Google 的“以...身份发送电子邮件”(“代表”)功能发送电子邮件。
现在有什么想法吗?最重要的是,我关心我的域名的声誉;我非常希望它不出现在任何垃圾邮件列表中。
答案1
在 SPF 机制中使用SoftFail
限定符(~
)时,表示匹配的发件人应该是受到怀疑,但并未断然拒绝。
另一方面,限定符( )鼓励接收Fail
MTA-
立即拒绝 SMTP 传输使用 5.1.7 DSN。
~all
因此,当您在记录末尾使用时,您只能部分阻止垃圾邮件发送者滥用您的域名和声誉。
在此处了解有关如何根据 RFC 规范处理 check_host() 结果的更多信息:IETF RFC 4408§2.5“解释结果”
答案2
除了 Mathias 所说的(这是很好的),请注意关键词鼓励在他的第二句话中:“失败限定符......鼓励接收 MTA 拒绝该电子邮件”。
我还建议研究DMARC。一旦你有 SPF 和 DKIM 记录,听起来你已经有,DMARC 是一种让你告诉接收邮件服务器如何处理失败的电子邮件的方法两个都SPF 和 DKIM 测试。
当电子邮件未通过这些测试,并且接收 MTA 遵守 DMARC 记录时,您可以控制他们对该电子邮件的操作:直接拒绝、将其标记为垃圾邮件或投递它。
答案3
我的情况完全一样,我更改了我的 SPF 记录以执行硬失败。这没有帮助。发送退回邮件的域的管理员似乎会查看 spf 记录,发现它失败了,然后忽略它。我并不担心我的域声誉,因为无论我是否在这里看到退回邮件,他们都会继续发送这些电子邮件。你什么也做不了,只能制定一条规则来忽略回复地址的模式。