Gmailラベルではなく転送ルートから開始します
転送後にGmailに到着したメッセージは、Gmail に直接送信されたメッセージとは異なる配信履歴を持ちます。転送サービスは、 SMTPエンベロープを変更し、元のメッセージを保存または変更し、独自の認証監視を添付する場合があります。元の送信者にDNS変更を依頼する前に、その履歴を診断してください。直接配信が成功すると、有用な比較が確立されますが、間接ルートが同じ認証パスを保持していることは証明されません。
最終的なアカウントの種類と転送メカニズムを特定します。 Google の一般的な送信者ガイドラインでは個人のGmailアカウントに明示的に対処していますが、組織のGoogle Workspaceルーティングには追加の管理上の選択肢が含まれる場合があります。仲介者がエイリアス サービス、メールボックス ルール、ゲートウェイ、またはメール システムであるかどうかを記録します。両方の宛先に使い慣れたGmailインターフェースが表示されるという理由だけで、1 つの製品またはルートにルールを適用しないでください。
範囲内でプロバイダーのガイダンスを読む
Googleの現在 回送案内 の転送ドメインを使用することをお勧めします。 封筒の差出人、そのドメインの転送インフラストラクチャを承認します。 SPF ポリシー、スパム転送を制限し、妨げとなる変更を回避します。 DKIM。また、 Gmail独自の認証チェックを実行するとも述べています。これらの推奨事項は、受信トレイの配信を約束したり、以前のサーバーのパスがGmailで権限を持つようにしたりするものではありません。
そのガイダンスは、 個人のGmail送信者の要件。要件は送信量とメッセージの目的によって異なります。この記事は、実際の送信者にどの要件が適用されるかを判断するためのものではありません。また、適切な所有者の決定なしに、ユーザーのアカウント設定を変更したり、転送を有効にしたり、信頼できるリストにアドレスを追加したりすることも提案していません。
封筒と目に見える身元を別々に追跡します
最後のSMTP接続時に、 SPF接続サーバーのアドレスを使用して関連する ID を評価します。フォワーダーは新しい接続サーバーであるため、元のエンベロープを保持するとSPF結果が変わる可能性があります。 RFC 7208セクション 10.3 メディエーターの問題を説明します。メッセージに表示される差出人アドレスは別の ID であり、全体を通じて変更されない可能性があります。
フォワーダーのドメインで書き換えられたエンベロープは、そのドメインのSPF認証を取得できます。ローカル部分に元のアドレスが含まれているだけでは、元の作成者ドメインと一致するわけではありません。下 RFC 9989セクション 4.4, DMARC 必要なドメイン関係を持つ認証済み識別子を渡す必要があります。実際のドメインを記録し、 アライメント SPFパスを全体の答えとして扱うのではなく、このモードを使用します。
調査のために、入手可能な場合は信頼できる配送記録から元のエンベロープ ID を要求します。決勝戦 Return-Path 便利ですが、以前のすべてのSMTPトランザクションを独立して記述しているわけではありません。表示名または引用されたメッセージ テキストから値を再構築するのではなく、利用できない以前の値を不明としてマークします。
転送が許可されている場合は、整列された署名を保持します
DKIM 、対象のコンテンツがまだ検証されている場合、転送を継続できます。変更によって署名が無効になるかどうかは、署名されたヘッダー フィールド、本文のカバレッジ、 正規化 検証時の実際のバイト数。 RFC 6376セクション 3.4 および 5.4 それらのルールを提供します。追加されたすべてのヘッダーがDKIM破壊するとか、表示される本文が変更されていないすべてのメッセージを検証する必要があるなどとは主張しないでください。
元の署名の署名ドメインを検査し、 セレクタ、そのリストされた署名付きヘッダーと受信者の検証結果。件名のプレフィックス、フッター、 MIME変換、または添付ファイルの変換は、対象となるマテリアルに影響を与える可能性があります。疑わしい変換の前後のメッセージを比較します。無関係な転送ドメインから新しい署名を追加しても、元の署名は修復されず、元の作成者との整合性も確立されません。
受信者は次のように考えるかもしれません ARC 独自のポリシーに基づく証拠。 RFC 8617 その実験メカニズムを説明します。有効なチェーンは、自動DMARCパスや配信保証ではありません。このレビューの時点では、 ARCの再分類提案 まだ作業中です。提案草案をGmail有効化または無効化に関する主張に変えないでください。
直接受領書と転送受領書の架空の比較
架空の送信者 Example Tickets が、1 つの領収書を管理されているGmailメールボックスに直接送信し、もう 1 つの同等の領収書をexample.netのエイリアスを通じて送信すると想像してください。対象となる作成者ドメインはexample.comです。この発明されたシナリオでは、直接コピーには有効な位置合わせされた署名があり、転送されたコピーにはその署名が保持されますが、カバーされた本文を変更するフッターが取得されます。
最終的なエンベロープがexample.netで書き換えられ、その ID に対してSPF合格したとします。その仮想パスはexample.comと一致しません。次に、レビュー担当者は、他の有効な整合署名が残っているかどうか、および最終受信者が何を報告するかを検査します。この例では、 Gmail判定、 ARC上書き、または観察された拒否を表明していません。メッセージは送信または収集されませんでした。
提案されている修復の質問は狭いものです。認可されたフォワーダーは、サービスのニーズを満たしながら、関連するメッセージ素材を保存できるか?これは、ID と認可の結果を理解せずに元の送信者のポリシーにフォワーダーを追加するよりも便利です。
成功を宣言する前に証拠パッケージを保持する
同意されたテスト アカウントと承認された非機密メッセージを使用します。直接および間接の配信時間、ルート識別子、エンベロープの観察、完全な署名、および信頼できる最終認証結果をキャプチャします。実際の処理を個別に記録します。SMTP SMTP受け入れ、メールボックスの配信、スパムの配置、およびユーザーの可視性は、互換性のある結果ではありません。中間コピーが利用できない場合は、どの変換をローカライズできないかを示します。
1 つのプレーンテキスト メッセージだけでなく、代表的な形式とルートに対して提案された変更を評価します。以前の構成を保存し、回復をトリガーするものを定義します。正確なカタログ ゲートは開いたままです。ルート、エンベロープ、署名、信頼できる結果を比較した直接および間接配信サンプルです。この原稿には、架空の演習と最新の文書ガイダンスが含まれており、オリジナルのサンプルや検証済みのGmail展開は含まれていません。