下流 DMARC pass は、メッセージを開始した人がその可視の送信者を使用する権限を持っていたことを証明するものではありません。 Engage Security による 2025 年 12 月の LaunDroMARC 調査では、リメールによって評価された ID が変更される間接的なルートについて説明されています。 SPF。結果を普遍的なDMARCバイパスとして説明したり、すべての Microsoft テナントが現在同じように動作すると仮定したりする前に、個々のホップを理解してください。
2 つの証拠ソースを分離する
元の研究者は、独自のエンベロープ ドメインに対してはSPFに合格したが、模倣された可視 From ドメインに対してはDMARC失敗した受信メッセージについて説明しました。報告されたケースでは、 Microsoft 365転送パスによってエンベロープが転送ドメインに書き換えられ、このドメインは表示されている From ドメインとも一致しました。最終的な受信機は、整列されたSPFを観測しました。研究者らは、オリジナルと転送されたコピーの処理が異なると報告しています。これらは彼らの調査から得られたと考えられる結果であり、このレビューのために行われた観察ではありません。 セキュリティ調査に取り組む.
Microsoft のドキュメントには次のように説明されています SRS 変化 メール送信元、表示される From フィールドではなく、適用可能な転送ルートの書き換えパターンを提供します。また、SRS は通常DMARCを解決しないことも警告します。 アライメント 転送メールの場合。これらのステートメントは、研究の特別なアイデンティティの一致と互換性があります。通常、元の From ドメインはフォワーダーのドメインとは異なります。報告されたケースには意図的に同じドメインが関与しています。 Microsoft SRS ドキュメント.
下流の評決を理解する
参考文献: RFC 9989 §4.4, RFC 8601 §5.
SPF 、接続ホストがそのホップでエンベロープ ID に対して承認されているかどうかを尋ねます。 DMARC 、認証されたドメインと表示されている From ドメインを比較します。どちらの結果も、単独では、元の攻撃者が転送ワークフローへのアクセスをどのように取得したかを再構築するものではありません。したがって、下流で調整された結果は、評価されたアイデンティティに関しては正しい可能性がありますが、依然としてビジネス認可の証拠としては不十分である可能性があります。
SRS っぽいものを解釈しないでください Return-Path Microsoft が作成した証拠として。最終的な受信者の信頼された結果、ピア情報、メッセージ トレースを保存し、受信境界と転送境界からの証拠を比較します。任意の埋め込み Authentication-Results テキストは信頼できる判定ではありません。 RFC 8601では信頼境界の要件について説明しています。 RFC 9989 ドメイン調整コンテキストを提供します。
同一性比較のみを再現する
プライベート レビュー パッケージの不配信モデルには、2 つの架空のケースが含まれています。通常の場合、元の表示可能な author.test ドメインは書き換えられた forwarder.test エンベロープとは異なるため、想定されるダウンストリームSPFパスは整列されていないままになります。 2 番目のケースでは、表示されるドメインは forwarder.test です。同じ書き換えられたエンベロープが整列します。どちらも異なる元のエンベロープ ドメインで始まり、調整されていません DKIM.
保持されたフィクスチャ入力は、この正確なドメイン比較を使用して、2026 年 11 月 8 日にオフラインで再計算されました。なりすましメールの送信、転送ルールの作成、 Exchange Online実行、SRS ハッシュの実装、または現在のテナントがルートを受け入れることの証明は行いません。その目的は、実際のサービスに対する攻撃を再現することなく、2 つの評決が異なる理由を説明することです。過去のベンダーの動作、現在のテナントの動作、および抽象的な比較は、個別にラベル付けされたままになります。
防御的に調査する
認可された外部転送業者とその事業主の在庫を確認します。インシデントの疑いがある場合は、元のコピーと転送されたコピー、タイムスタンプ、ルーティング方法、事前転送認証、および最終結果を保存します。ルールを変更する前に、プロバイダーの現在のドキュメントとメッセージ トレースを確認してください。 Microsoft のソースでは、該当する転送をリレー プールおよびオンプレミスの場合と区別しているため、単一の構成要求だけではすべてのパスをカバーするのに十分ではありません。
組織の承認されたメール セキュリティ プロセスを通じて変更を適用し、その後、正当なワークフローをテストします。プロバイダーのインフラストラクチャまたはダウンストリーム パスの結果のみに基づいた広範な許可ルールは避けてください。この記事では、メカニズムと調査の質問を確立します。未検証の修復日、普遍的な暴露、悪用の成功、または現在の Microsoft サービスの欠陥を主張するものではありません。