Exchange – Office 365的所有外部邮件都失败了SPF,在混合部署中

简而言之：合法电子邮件登陆垃圾文件夹,因为EOP(Exchange Online Protection)将电子邮件标记为垃圾邮件(SCL5)和SPF失败.所有外部域(例如gmail.com/hp.com/microsoft.com)都发生在客户端域(contoso.com)上.

背景资料：

我们正处于将邮箱迁移到Office 365(Exchange Online)的开始.这是混合部署/ Rich-Coexistence配置,其中：

>内部部署= Exchange 2003(旧版)& 2010(安装混合部署)
> Off-Premises = Office 365(Exchange Online)
> EOP配置为SPF检查.
> MX记录指向内部部署,因为我们尚未完成将所有邮箱从内部部署迁移到Exchange Online.

问题是当外部用户向组织中的Office 365邮箱发送电子邮件时(邮件流：外部 – >邮件网关 – >本地邮件服务器 – > EOP – > Office 365),EOP执行SPF查找和硬/软失败消息,其中包含从其接收邮件的邮件网关的外部IP地址.

(内部部署邮箱不显示此问题;仅迁移到Office 365的邮箱.)

举例说明：

示例1：从Microsoft到O365

Authentication-Results: spf=fail (sender IP is 23.1.4.9) 
smtp.mailfrom=microsoft.com; contoso.mail.onmicrosoft.com;
dkim=none (message not signed) header.d=none;
Received-SPF: Fail (protection.outlook.com: domain of microsoft.com does not designate
23.1.4.9 as permitted sender) receiver=protection.outlook.com; client-ip=23.1.4.9; 
helo=exchange2010.contoso.com; X-MS-Exchange-Organization-SCL: 5

例2：从HP到O365

Authentication-Results: spf=none (sender IP is 23.1.4.9) 
smtp.mailfrom=hp.com; contoso.mail.onmicrosoft.com; dkim=none 
(message not signed) header.d=none; Received-SPF: None 
(protection.outlook.com: hp.com does not designate permitted sender hosts) 
X-MS-Exchange-Organization-SCL: 5

示例3：从Gmail到O365

Authentication-Results: spf=softfail (sender IP is 23.1.4.9) 
smtp.mailfrom=gmail.com; contoso.mail.onmicrosoft.com; 
dkim=fail (signature did not verify) header.d=gmail.com; 
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning 
gmail.com discourages use of 23.1.4.9 as permitted sender)  
X-MS-Exchange-Organization-SCL: 5

有关X-Forefront-Antispam-Report的邮件标题,请参阅http://pastebin.com/sgjQETzM

注意：23.1.4.9是Exchange Online的本地混合Exchange 2010服务器连接器的公共IP地址.

在混合部署的共存阶段,我们如何阻止外部电子邮件被EOP标记为垃圾？

[2015-12-12更新]

此问题已由Office 365支持(升级/后端团队)修复,因为它与我们的设置无关.

我们被建议如下：

>将EOP允许列表中的公共IP列入白名单(已尝试.它没有帮助.)
>为我们的域添加SPF记录：“v = spf1 ip4：XXX.XXX.XXX.XXX ip4：YYY.YYY.YYY.YYY include：spf.protection.outlook.com -all”(不要认为这个建议是有效的EOP不应该检查gmail.com与我们的SMTP IP地址,因为它没有在gmail.com的SPF记录中指定.这似乎不是SPF的工作方式.)
>确保启用TLS(见下文)

关键部分是第三点. “如果没有启用TLS,来自本地Exchange的传入电子邮件将不会被标记为内部/信任电子邮件,EOP将检查所有记录,”支持人员说.

该支持通过以下行确定了我们邮件标题中的TLS问题：

> X-MS-Exchange-Organization-AuthAs：匿名

这表示EOP收到电子邮件时未启用TLS. EOP没有将收到的电子邮件视为信任电子邮件.正确的应该是这样的：

> X-MS-Exchange-Organization-AuthAs：内部

但是,这不是由我们的设置引起的;支持人员帮助我们通过验证来自Exchange 2010混合服务器的详细SMTP日志来确保我们的设置正确无误.

大约在同一时间,他们的后端团队解决了这个问题,但没有告诉我们究竟是什么导致了它(不幸的是).

修复后,我们发现邮件头有一些重大更改,如下所示.

对于从Exchange 2003到Office 365的内部源邮件：

> X-MS-Exchange-Organization-AuthAs：内部(它是“匿名”)
> SCL = -1(SCL = 5)
>收到SPF：SoftFail(它是一样的)

对于外部邮件(例如gmail.com)到Office 365：

> X-MS-Exchange-Organization-AuthAs：匿名(它是一样的)
> SCL = 1(SCL = 5)
>收到SPF：SoftFail(它是一样的)

虽然对于Office 365的gmail.com(外部)SPF检查仍然是软失败,但支持人员说它没问题,并且所有邮件都将转到收件箱而不是垃圾文件夹.

作为旁注,在后续处理过程中,后端团队发现了一个看似微不足道的配置问题 – 我们的IP入站连接器(即Exchange 2010混合服务器的公共IP)中的IP已在我们的IP允许列表中定义(由另一个Office 365支持建议)人作为故障排除步骤).他们让我们知道我们不应该这样做,事实上这样做会导致路由问题.他们评论说,在初次通过时,电子邮件没有被标记为垃圾邮件,因此这里也存在可能的问题.然后,我们从IP允许列表中删除了IP. (但是,在进行IP允许列表设置之前存在垃圾邮件问题.我们不认为允许列表是原因.)

总之,“应该是EOP机制,”支持人员说.因此,整个事情应该由他们的机制引起.

对于任何感兴趣的人,可以在此查看与其支持人员之一的故障排除主题：https://community.office365.com/en-us/f/156/t/403396

当您运行混合向导时,它应该在本地和O365中创建连接器,这将在林之间将邮件流作为内部邮件.这意味着它将绕过EOP /垃圾邮件检查,您永远不会看到这些SPF消息.

如果您的边缘设备正在修改标头,这可能会导致您的问题 – 在您的服务器和O365之间没有任何内容可以修改邮件标头.确保您没有可能覆盖Hybrid向导创建的连接器的现有连接器.您始终可以删除已创建的现有连接器,然后重新运行向导以重新创建它们.

检查Exchange中的传输规则,确保他们在转到O365之前没有修改消息,如果他们禁用它们并再次测试以确保这些不是您的问题.

最后(或者可能是第一次)检查您的联合配置是否正确.如果不是这就是为什么你的邮件没有得到正确处理.这是重新运行Hybrid向导的地方,您也可以帮助您.

（编辑：PHP编程网 - 黄冈站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!