简而言之：合法电子邮件登陆垃圾文件夹,因为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