プロバイダーのペアではなくルールのチェーンをモデル化する
混合プロバイダー転送の問題は、「メールはあるシステムでは機能するが、他のシステムでは機能しない」とよく言われます。その説明はルートを隠します。同じアドレスは、最終メールボックスがメールを認識する前に、エイリアス、メールボックス ルール、セキュリティ ゲートウェイ、および別の転送ルールを介してメールを受信できます。各段階では、異なるエンベロープ ID、メッセージ変換、またはローカル決定が導入される可能性があります。
認証結果を比較する前に、バージョン管理されたルート インベントリを構築します。元の送信者、各仲介者、および最終受信者の名前を指定します。自動リダイレクトと、新しい転送を作成する人を区別します。各ルールの所有者と入手できる証拠を記録します。プロバイダー名は便利なラベルですが、実際のルール タイプ、アカウント構成、および処理シーケンスによって、検証が必要な動作が決まります。
ホップごとに比較契約を確立する
ハンドオフごとに、同じ証拠フィールド（観察時間、接続元、 封筒の差出人 既知の場合、作成者ドメイン、署名の存在、対象となるコンテンツの変更、および受信システムの結果。直接サンプルが間接パスの別のブランチと混同されないように、ルート識別子を含めます。意図した構成と観察された動作は一致しない可能性があるため、両方を維持してください。
プロバイダーのエクスポートまたはコントロール パネルのスクリーンショットには構成が説明されていますが、受信メッセージを生成したトランザクションは必ずしも説明されません。サービスが中間エンベロープを公開できない場合は、そのフィールドを不明としてマークし、受信者の最終的な観察を保持します。転送と呼ばれるすべてのルールが同じSMTPメソッドを使用すると仮定してギャップを埋めないでください。
代表的な形式と既知の受信者を含む小規模で承認された比較セットを使用します。実際には、一度に 1 つの計画変数のみを変更します。プレーン テキスト、マルチパート メール、および添付ファイルのあるメッセージは、異なる処理パスを実行できます。目的は、依存関係を分離することであり、少数の例から全体的な配信可能性のパーセンテージを算出することではありません。
転送境界ごとにアイデンティティを再度評価する
最終接続サーバーは、元の送信者のサーバーと異なる場合があります。 RFC 7208セクション 10.3 それがなぜ重要なのかを説明する SPF。仲介者は封筒を保管したり、交換したりすることができます。その行動には証拠が必要です。後の書き換えによって、以前の書き換えドメインが置き換えられる可能性があるため、最終的な Return-Path それだけでは、以前のすべてのアイデンティティの完全な履歴ではありません。
下 RFC 9989セクション 4.4、渡す識別子も通常の作成者のドメインと一致する必要があります。 DMARC 成功。書き換えられたローカル部分の中に元のアドレスを入れても、そのドメイン関係は作成されません。また、すべての仲介者の署名が必ずしも役立つわけではありません アライメント: 各署名ドメインは、作成者との関係について評価する必要があります。
生き残ったオリジナルを扱う DKIM 別のパスとして。によると RFC 6376セクション 3.4 および 5.4、検証は署名されたフィールドと正規化された対象コンテンツに依存します。プロバイダーは、必ずしも署名を無効にすることなく未署名のトレース ヘッダーを追加できますが、変更された署名済みの件名やカバーされた本文は重要になる可能性があります。チェーン内の最後のプロバイダーに責任を負わせるのではなく、実際の資料を比較してください。
プロバイダーのガイダンスを文書化された製品にローカルに保つ
Googleの 転送推奨事項 そしてマイクロソフトの SRSの説明 さまざまな製品の観点から関連する問題に対処します。 Microsoft のドキュメントには、ルート依存の例外が含まれています。正確な製品と流れの方向に対してそれぞれを読み取り、プロバイダーのロゴから予測するのではなく、結果のエンベロープを検証します。
同じ注意が受信者の評価にも当てはまります。マイクロソフトの 複合認証の説明 通常のプロトコルの結果とは異なる追加の結果について説明します。その値を扱うユニバーサル パス列を作成しないでください。 ARC チェーンの結果とDMARC同等です。元のラベルを保管し、ラベルが製造された場所でその意味を文書化します。
ARC以前の評価を実行できますが、 RFC 8617 信頼と処理を受信者のポリシーに任せます。このレビュー日時点ではまだ実験段階です。の 2026年10月の再分類提案 はアクティブなドラフトであり、採用された代替品ではありません。プロバイダー間の計画は、各受信者が各仲介者を信頼するという未検証の約束に依存すべきではありません。
2 つの独立した障害が発生した架空の例
example.comからexample.netの組織メールボックス、アーカイブ サービス、個人メールボックスを経由する架空のルートを考えてみましょう。意図された比較には、直接対照と、観察可能な各段階からの 1 つのサンプルが含まれます。考案されたシナリオでは、最初の転送では署名されたメッセージが保存され、アーカイブ サービスはチケット ラベルを署名された件名フィールドに追加します。
最後のエンベロープがアーカイブ サービスに属し、そのSPF評価に合格したとします。この結果自体はexample.comと一致しません。主題の変更により、元の調整されたDKIMパスの損失が説明される可能性がありますが、レビュー担当者はそれを確立するために実際の前後の資料が必要になります。提案された変更は、最初のメールボックスのDNSに自動的に属するのではなく、アーカイブ変換に属します。
これとは別に、インベントリにより、以前のアドレスに返信を送り返す可能性がある古いルールが明らかになりました。これは、単独で検討する必要があるルーティングのリスクです。認証パスはループ防止を証明するものではありません。この例では、メッセージ ループ、ヘッダーの変更、プロバイダーの判定は実際には観察されませんでした。
ルールが変更された場合でも運用上の所有権を維持する
正確なルールの違い、サービス所有者、対象となる宛先、および変更を受け入れるために必要な証拠を記録します。認証と並行して、重複コピー、古い宛先、プライバシーへの期待、失敗通知を確認します。認証はするものの、メッセージが意図しないメールボックスに公開されるルートは、移行が成功したとは言えません。
承認された実行後、比較を繰り返し、残りの未知数を保存します。カタログには、ルート、エンベロープ、署名、および信頼できる結果を比較した直接および間接配信サンプルが必要です。その門は開いたままです。この記事は、独自の診断フレームワークと架空のルートの演習を提供するものであり、プロバイダーのライブ テスト、承認されたルールの変更、サービス全体での同等の動作の証明ではありません。