简而言之：当EOP（Exchange Online Protection）将电子邮件标记为垃圾邮件（SCL5）且SPF失败时，合法电子邮件将进入垃圾文件夹。所有外部域（例如gmail.com/hp.com/microsoft.com）到客户端的域（contoso.com）都会发生这种情况。
背景信息：
我们正开始将邮箱迁移到Office 365（Exchange Online）。这是混合部署/丰富共存配置，其中：
- 本地= Exchange 2003（旧版）和2010（为混合部署而安装）
- 本地= 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不应针对SMTP IP地址检查gmail.com，因为gmail.com的SPF记录中未指定SMTP IP地址。这似乎不是SPF的工作方式。）
- 确保启用了TLS（请参见下文）
关键是第三点。支持说：“如果未启用TLS，则来自本地Exchange的传入电子邮件将不会被标记为内部/信任电子邮件，并且EOP将检查所有记录。”
支持人员通过以下行从我们的邮件标题中确定了TLS问题：
- X-MS-Exchange-Organization-AuthAs：匿名
这表示EOP收到电子邮件时未启用TLS。EOP并未将传入电子邮件视为信任电子邮件。正确的应该是这样的：
- X-MS-Exchange-Organization-AuthAs：内部
但是，这不是由我们的设置引起的。支持人员通过验证Exchange 2010 Hybrid服务器上的详细SMTP日志来帮助我们确保设置正确。
大约在同一时间，他们的后端团队解决了这个问题，而没有让我们知道到底是什么原因（不幸的是）。
修复它们后，我们发现消息头有一些重大变化，如下所示。
对于从Exchange 2003到Office 365的内部起源的邮件：
X-MS-Exchange-Organization-AuthAs：内部（“匿名”）
SCL = -1（以前为SCL = 5）
- 收到的SPF：SoftFail（相同）
对于发送到Office 365的外部邮件（例如gmail.com）：
X-MS-Exchange-Organization-AuthAs：匿名（相同）
SCL = 1（之前为SCL = 5）
收到的SPF：SoftFail（相同）
尽管SPF检查仍然对Office 365的gmail.com（外部）仍然失败，但支持人员表示还可以，并且所有邮件都将转到收件箱，而不是垃圾文件夹。
附带说明，在故障排除过程中，后端团队发现了一个看似较小的配置问题-我们在IP允许列表（由另一个Office 365支持建议）中定义了来自入站连接器的IP（即Exchange 2010 Hybrid服务器的公共IP）人员作为故障排除步骤）。他们让我们知道我们不需要这样做，实际上这样做会导致路由问题。他们评论说，最初通过时，该电子邮件并未被标记为垃圾邮件，因此这里也可能存在问题。然后，我们从IP允许列表中删除了IP。（但是，垃圾邮件问题在设置IP允许列表之前就已经存在。我们认为不是允许列表的原因。）
最后，支持人员说：“这应该是EOP机制。” 因此，整个事情应该由它们的机制引起。
对于任何有兴趣的人，可以在这里查看其支持人员之一的故障排除线程：https : //community.office365.com/en-us/f/156/t/403396