範囲と準備
このガイドでは、Taguchi 送信ドメインのセットアップについて説明します。これは文書化された手順であり、実際のテナント テストのレポートではありません。管理者、 DNSアクセス、キャンペーン所有者を取得します。既存のレコードを保存し、キャンペーンで使用を許可される From ドメインを決定します。別途ご予約ください リターンパス 別のサービスをまだ持っていない名前。
送信ドメインを設定する
[設定] > [ドメイン] で、[From ドメインとリターンパス] コンポーネントを追加し、 セレクタ、保存します。を公開します CNAME ドキュメントの例ではなく独自の構成を使用して、 DNSレコード列に生成されたTXTエントリ。タグチは保留中、承認済み、設定済みを区別します。 DNS認証後、サポートは構成を完了する必要があります。次に、テンプレート テーマでドメインを選択します。プロバイダーは 24 時間の認証期間を説明しています。永続的な保留状態をエスカレートする前に、レコードの精度を確認してください。以下のTaguchi セットアップ ソースを参照してください。
オリジナルキャンペーン受付デザイン
同じキャンペーンの無害なバージョンを 2 つ用意します。1 つはテーマを変更する前、もう 1 つは変更後です。テーマ、From ドメイン、エンベロープ ドメイン、各署名ドメイン、および両方の信頼できる受信者の結果を記録します。これにより、 DNS内に存在するがキャンペーンでまだ使用されていない構成変更が分離されます。公認ラベルをキャンペーンが切り替わった証拠として解釈しないでください。
架空の From ドメインnotices.example.orgの場合、 bounce.notices.example.orgの下のエンベロープは、なぜ緩和されるのかを示しています。 SPF アライメント 厳密なSPF調整は異なる場合があります。これらは教育上のアイデンティティであり、タグチが発行した価値観や観察された結果ではありません。選択した配置モードを明示的にテストし、ダッシュボード ラベルに関する仮定よりも実際のメッセージからの証拠を優先します。以下の受け入れ計画には、観察された結果の行がありません。これは添付の測定ワークシートではなく、ガイダンスです。
受信側で身元を証明する
制御された外部メールボックスを使用し、無害なコンテンツと顧客データを含まない運用ワークフローを通じて送信します。生のメッセージ、タイムスタンプ、受信システムのデータを保存します。 Authentication-Results。信頼できない送信者によって挿入された認証アサーションを無視します。表示されている From ドメイン、 Return-Path 、または認証されたエンベロープ ID、およびすべての情報を記録します。 DKIM d= and s= pair. A display name or Reply-To address is not the DMARC 身元。
SPFパスは、評価されたエンベロープ ID に対して接続サーバーを承認します。 DKIMパスは、その署名ドメインの署名を検証します。 DMARCは、ドメインが表示されている From と一致する受け渡しメソッドが必要です。厳密な一致には同じドメインが必要です。緩和された調整により、適切な組織とドメインの関係が可能になります。プロバイダーが所有する署名は、表示されている From を認証せずに渡すことができます。 1つのパスが揃った DKIM署名 別の署名が失敗した場合でもDMARC満たすことができます。これらのプロトコル ルールは、 RFC 7208 、 RFC 6376 、および RFC 9989、以下にリストされています。
キャッシュを診断する前に、権威DNSを確認してください。権威サーバーに正確な名前とタイプを問い合わせて、キャッシュされた有効期間の経過後に再帰的リゾルバーを比較します。 DKIMの場合は、任意のCNAMEをたどって公開鍵TXT応答を取得します。秘密キーは決して公開しないでください。評価された名前ごとに 1 つのSPFポリシーを保持し、ネストされたインクルード全体で 10 個の DNS ルックアップの原因となる用語の制限を確認します。共有SPFポリシーをプロバイダーの例に置き換えないでください。
回復と受け入れ
テストで新たな後退が示された場合は、影響を受けるワークフローを一時停止します。変更されたレコードを保存されたバージョンと比較し、他の送信者を確認した後、その変更のみを元に戻します。 DNSを再チェックし、回復後に再送信します。値を元に戻しても、すべてのリゾルバーがすぐにフラッシュされるわけではありません。セキュリティインシデントによって取り消しが必要になる場合を除き、以前に署名されたメッセージがまだ転送されている可能性がある間は、古いDKIM検証レコードを利用可能な状態に保ちます。
DNS 、アプリケーションの状態、および実際に受信したメッセージが一致する場合にのみ、変更を受け入れます。フローの所有者、証拠のタイムスタンプ、および次のレビューのトリガーを記録します。受信箱の配置だけでは認証の証明にはならず、認証が成功しても受信箱の配置が保証されるわけではありません。 1 つのプロバイダーのテストの強度に基づいて、共有ドメインのDMARCポリシーを強化しないでください。最初に他の正当なソースのインベントリを作成します。
キャンペーンのリリース前に州台帳を使用する
記述されたケース TG-01 では、新しいドメインがnotices.example.org 、選択されたリターン パス コンポーネントが bounce 、セレクターが実際のアカウント発行値であると想定していますが、この例では指定されていません。 DNS認証は完了していると規定されていますが、ステータスは「構成済み」ではなく「認証済み」であり、キャンペーンのテーマでは依然として古いドメインが選択されています。サポート所有者はプロバイダーのアクティベーションを完了する必要があります。その後、キャンペーン所有者がテーマ内の承認済みドメインを選択し、制御されたテストを実行します。それまでは、変更されたキャンペーンの実際の From、エンベロープ、 DKIM結果は不明です。 DNSだけから準備完了としてマークしないでください。サポート リクエスト、テンプレートの編集、 DNSクエリ、キャンペーンの送信は行われませんでした。
施行境界を維持する
RFC 9989セクション 7.4 では、ドメイン公開にSPFのみではなく有効なDKIMが必要です p=reject、間接メールとメーリングリストの相互運用性について警告します。ダイレクト メッセージ テストが 1 回成功しただけでは、すべての正当なルートがより強力なポリシーに対応できるようになっているという証拠にはなりません。実際のギャップを診断しながら、既存の承認された保護を維持します。政策変更には独自の決定が必要です。