要するに、EOP（Exchange Online Protection）が電子メールメッセージをジャンク（SCL5）およびSPF失敗としてスタンプするため、正当な電子メールがジャンクフォルダーに到着します。これは、クライアントのドメイン（contoso.com）に対するすべての外部ドメイン（gmail.com/hp.com/microsoft.comなど）で発生します。
背景情報：
メールボックスをOffice 365（Exchange Online）に移行し始めています。これは、Hybrid Deployment / Rich-Coexistence構成です。ここで、
- オンプレミス= Exchange 2003（レガシー）および2010（ハイブリッド展開用にインストール）
- オフプレミス= Office 365（Exchange Online）
- EOPはSPFチェック用に構成されています。
- MXレコードは、オンプレミスからExchange Onlineへのすべてのメールボックスの移行が完了していないため、オンプレミスを指しています。
問題は、外部ユーザーが組織内のOffice 365メールボックスにメールを送信するとき（メールフロー：外部->メールゲートウェイ->オンプレミスメールサーバー-> EOP-> Office 365）、EOPはSPFルックアップとハード/ソフトを実行しますメールを受信したメールゲートウェイの外部向けIPアドレスを含む失敗メッセージ。
（オンプレミスのメールボックスにはこの問題は表示されません。Office365に移行されたメールボックスのみが表示されます。）
イラスト：
例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のSPFレコードで指定されていないため、SMTP IPアドレスに対してgmail.comをチェックするべきではありません。それはSPFが機能するようには見えません。）
- TLSが有効になっていることを確認してください（以下を参照）
重要な部分は3番目のポイントです。「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でした）
- Received-SPF：SoftFail（同じでした）
また、Office 365への外部メール（例：gmail.com）の場合：
X-MS-Exchange-Organization-AuthAs：匿名（同じでした）
SCL = 1（SCL = 5でした）
Received-SPF：SoftFail（同じでした）
gmail.com（外部）のOffice 365へのSPFチェックは依然としてソフト失敗しますが、サポート担当者はそれがOKであり、すべてのメールはジャンクフォルダーではなく受信ボックスに送信されると述べました。
補足説明として、トラブルシューティング中に、バックエンドチームは、一見小さな設定の問題を1つ発見しました-IP許可リスト（別のOffice 365サポートで推奨）で定義された受信コネクタのIP（Exchange 2010ハイブリッドサーバーのパブリックIP）がありましたトラブルシューティング手順としての担当者）。彼らは私たちにこれを行う必要はないことを教えてくれ、実際にそうするとルーティングの問題を引き起こす可能性があります。彼らは、最初のパスで電子メールがスパムとしてマークされていなかったので、ここでも問題がある可能性があるとコメントしました。次に、IPをIP許可一覧から削除しました。（ただし、IP許可リストの設定が行われる前にスパムの問題が存在しました。許可リストが原因であるとは考えていませんでした。）
結論として、「それはEOPメカニズムであるべきです」とサポート担当者は言いました。したがって、全体はそのメカニズムによって引き起こされるべきです。
興味のある方は、サポート担当者とのトラブルシューティングスレッドをこちらでご覧ください：https : //community.office365.com/en-us/f/156/t/403396