何が失敗したかを判断する前にルートを分類する
受信者は、転送ホップ後、またはメーリング リストによる変更後に、発信元サービスから直接メールを確認できます。送信元 IP と認証の失敗だけでは、これらのパスと偽装を区別することはできません。調査者は、報告された結果を特定のルートに関連付け、ルートが欠落している部分の不確実性を維持する必要があります。そうしないと、正当な送信者を対象とした修復によって、無関係なインフラストラクチャが認証される可能性があります。
このガイドでは、 RFC 9989 そして RFC 9990 2026年5月からは、 SPF RFC 7208と実験的 ARC 仕様RFC 8617 。プロバイダーのガイダンスは 2026 年 11 月 8 日に見直されました。すべてのルートの例は架空の紙のケースです。メッセージは送信、インポート、検証されず、 DNSクエリも実行されず、転送や受信者信頼設定も変更されませんでした。
受信境界を基準にして直接送信を定義する
この調査では、直接送信とは、調査対象のルートに転送サービスを介さずに、目的のアウトバウンド サービスが受信境界に配信されることを意味します。これは、発信元の組織が内部サーバーを 1 つだけ使用するという意味ではありません。内部リレーと送信ゲートウェイは、観察された接続よりも前に存在する可能性があるため、ラベルを適用するときに使用される境界を記録してください。
RFC 7208 定義されたSMTP ID に対して接続ホストを評価します。直接ルートの障害は、構成の問題、予期しないパス、または不正な使用を示している可能性があります。結果だけから原因を特定するのは十分ではありません。承認の変更を提案する前に、評価されたドメイン、接続コンテキスト、エラー ステータスを保存してください。
転送によってSPF証拠が変更される理由を説明する
フォワーダーが元のメッセージを以降に配信すると、次の受信者はフォワーダーの接続アドレスを確認します。元のエンベロープ ID が保持されている場合、そのアドレスは元のドメインのSPFポリシーによって承認されない可能性があります。エンベロープが書き換えられた場合、代わりにSPFフォワーダーの ID を認証することがあります。どちらの状況でも、元の表示されている From ドメインに対して調整されたSPFパスが自動的に提供されるわけではありません。 RFC 9989.
そのため、観察されたすべてのフォワーダーを元のドメインのSPFに追加することは、健全なデフォルト応答ではありません。実際のルートや他の認証パスに対処することなく、認可を拡大できます。まず、転送が行われたかどうか、受信者が転送を予期していたかどうか、どの ID が変更されたかを確認します。転送のようなパターンは、代表的なルートの証拠がそれを裏付けるまでは仮説です。
元のDKIM署名が残っているかどうかを調べる
メッセージは有効なアラインメントを保持できます。 DKIM署名 署名されたマテリアルが検証との互換性を維持している場合、転送を通じて。 RFC 6376 署名の対象範囲とそのチェック方法を定義します。署名されたヘッダーまたは本文の内容を変更すると、その署名が壊れる可能性があります。単にメッセージを別のサーバー経由で移動するだけでは、必ずしもそうする必要はありません。 1 つの転送製品をすべてのルートに一般化しないでください。
メーリング リストでは、コンテンツを変更したり、フッターを追加したり、再配布する前にメッセージを変換したりすることができます。リストからの新しい有効な署名は、元の From ドメインと一致しないまま、リストのドメインを認証する可能性があります。 Aが報告した DKIM したがって、パスには署名 ID が必要であり、 アライメント コンテクスト。オリジナルの作者のドメインが通過したことの証拠として読み取ることはできません DMARC.
信頼性がまだ決定を必要としている証拠としてARC使用する
RFC 8617 は、メッセージ処理ステップ全体にわたって認証評価を実行するための実験的なプロトコルです。 ARCチェーンの検証とシーリング当事者への信頼は別の問題です。暗号的に有効なチェーンによってメッセージが安全になったり、すべてのシーラーが信頼できるかどうかが確立されるわけではありません。チェーンが失われたり壊れたりしても、メッセージが偽造されたことを証明することはできません。
受信者は、ローカルの配置決定にARC情報を使用できます。これを、 ARC基礎となるSPFまたはDKIMアライメントの失敗をプロトコル パスに変えるという普遍的なルールに書き換えないでください。観察された認証結果と報告されたポリシー オーバーライドを個別に保存します。 RFC 9990 DMARC で評価されたフィールドと生の認証結果を区別し、ポリシー オーバーライド レポートのコンテキストを提供します。受信者の受け入れと認証の結果は異なる事実のままです。
過剰分類せずに 4 つの架空のパスを比較する
保存文書の演習では、4 つの可能性を対比します。整列されたDKIMを保持する変更されていないフォワーダー。元の署名が検証されなくなった変更リスト。既知の承認されたルートを持たずに From ドメインになりすました送信者。これらは説明のための代替案であり、テストされた 4 つのメッセージではありません。実際のホスト、アカウント、ビジネス所有者は割り当てられていません。
最初の 3 つの可能性では、正規の観測トラフィックとして扱う前に、ルート固有の設定とメッセージの証拠が必要です。 4人目は依然として疑わしい スプーフィング 利用可能な証拠とセキュリティレビューがその分類を裏付けるまで。認証の失敗だけでは、リスト変更の場合と偽装を区別できません。逆に、認証に合格しても、無害なコンテンツや現在承認されているビジネス目的を確立することはできません。
受信者の実際の信頼構成を尊重する
マイクロソフトの 信頼できるARCシーラーのガイダンス はプロバイダー固有の例です。これは、 Microsoft 365の受信動作に必要な正当な仲介者の選択について説明しています。ユニバーサル ホワイトリスト、別のプロバイダーのポリシー、または顧客テナントの構成は確立されません。この草案は、名前がよく知られているという理由だけでシーラーを追加したり、仲介業者を信頼することを推奨したりするものではありません。
将来の調査のために、代表メッセージ、信頼できる受信トレース、関連するサービス構成、および受信者の予想されるルートを保存してください。 Authentication-Results フィールドは、次のように確立された受信信頼境界内で解釈される必要があります。 RFC 8601 と説明します。信頼できないコピーされたヘッダーは何でもアサートできます。メッセージの開示、受信者のセキュリティの変更、運用DNSアクションは、人間による承認に従ってください。
証明された解決策を呼び出す前に、観察されたルートを要求する
正確な吸気ゲートは開いたままです。現在の主な仕様を検証し、製図前に実際に動作した例を保存します。一次情報源と架空の比較は保持されていますが、依頼されたオリジナルの証拠はまだ存在しません。つまり、現在のプロバイダーの証拠と管理されたテスト メッセージを含むルートから要件へのマップです。
最終的な制御テストでは、承認された受信者とルートを使用し、関連する診断を保持し、配信、認証、およびローカル ポリシーの処理を区別する必要があります。普遍的な転送互換性を約束するのではなく、特定の不確実性に対処する必要があります。証拠が存在するまで、候補の分類と次の調査ステップを保存してください。文書の例だけから、修復の成功、なりすましの確認、または承認された送信者を主張しないでください。