送信ドメインを定義する連絡先電子メールから始めます
ControlShiftの公式 送信者認証構成ガイドは、2025 年 5 月 20 日に更新され、そのプラットフォームの送信 ID を組織の連絡先メールアドレスに結び付けます。ガイドによると、このアドレスは、行動を起こすサポーターや通知を購読している管理者へのプラットフォームメールに使用されるという。構成されたアドレスが目的のアドレスに属していることを確認します 組織ドメイン 認証レコードを作成する前に。この最初のステップでタイプミスや古いブランド ドメインがあると、間違った ID に対して技術的に一貫した構成が作成されてしまう可能性があります。
文書化されたパスは、管理者のホームページ、設定、連絡先であり、アドレスが入力され保存されます。そのアドレスの変更は、単なる認証修復ではなく、通信構成の変更として扱います。影響を受けるメッセージ カテゴリを特定し、保存する前に期待される内容と担当スタッフに返信します。この記事はアドレスを変更したり、サポーターに連絡したり、プラットフォーム通知を送信したりするものではありません。現在のアカウントの適用性と、代表メッセージで使用される実際のルートはオープンのままです。
配信可能性設定を使用してアカウント固有のレコードを取得する
連絡先電子メールを設定した後、ガイドは管理者を [設定]、[配信性] に案内します。表示されるドメイン名は連絡先メールアドレスから取得されます。間違っている場合は、意図しないドメインのレコードを公開するのではなく、まず連絡先メールアドレスを修正してください。提供されたフィールドに組織の技術連絡先の電子メールを入力し、承認されたアカウントのワークフローを通じて保存します。技術連絡先のアドレスは、適切な許可がある場合にのみ提供され、スタッフの責任が変更された場合でも最新の状態に保たれる必要があります。
保存後、ページには 3 つのメッセージが表示されます。 CNAME 記録。組織の権威あるDNSプロバイダーを通じて、発行された正確な所有者とターゲットを公開します。このガイドではマッピングの方向について説明しています。左側の名前は右側のターゲットを指します。これらのフィールドを逆にせず、代わりに置き換えます。 記録 別の組織からコピーするか、発行された構成を一般的なSendGrid例に置き換えます。 ControlShift のアカウント生成値は、このワークフローの実装入力です。
編集する前に、各完全な所有者名をDNSエディターのサフィックス処理および既存のゾーン データと比較します。あるパネルでは相対ラベルで十分ですが、別のパネルでは完全修飾名が必要な場合があります。現在の記録を保存し、承認された変更を記録します。 3 つの CNAME は、将来の移行、ドメインの変更、オフボードの際に確認できるように、このプラットフォーム構成に起因する依存関係を表します。
解釈する前にDNS可視性をチェックする
このガイドでは、 Cloudflareユーザーは電子メール配信記録をプロキシなしで保存する必要があると述べています。これは、これらの認証レコードに対する具体的なガイダンスであり、Web サイト全体でプロキシやセキュリティ制御を無効にする理由ではありません。 DNSホストがプロキシ機能を提供している場合は、承認されたDNS所有者とともに関連するレコード設定を確認し、発行されたエイリアスが必要に応じて公開されていることを確認します。この記事ではDNS設定は変更されません。
レコードを作成した後、[到達性] に戻り、[検証] を選択します。文書化された成功メッセージは、ControlShift のDNSチェックに合格したことを示します。その観察結果は、提出された変更や実際の公的記録とは別に保管してください。プロバイダーのチェックは、今後のすべてのメッセージが正しく署名されていること、または表示される作成者ドメインが一致していることを証明するものではありません。検証が失敗した場合は、構成を繰り返し待機または再構築する前に、正確な所有者、ターゲット、権限のあるゾーン、および関連するレコード設定を検査してください。
プロバイダーの簡単な伝播見積もりを普遍的な期限として扱うべきではありません。間違ったレコード所有者またはプロキシされたエイリアスは、経過時間だけでは修復されません。何が変更されたのか、いつ変更されたのか、プロバイダーが観察した内容を記録します。信頼できる回答とプロバイダーの最新のステータスがまだ一致していない場合は、不確実性を明示したままにしておきます。
別の送信者を上書きせずにセレクターの衝突を解決します。
ControlShift は、すでにSendGrid直接または別のツールを通じて使用している組織が s1 を持っている可能性があることを特に警告します。 _domainkeyと s2。 _domainkeyレコード。ガイドはカスタムを提供します DKIMセレクター このような衝突を回避するには、詳細設定を使用します。ここでは、[カスタムDKIMセレクターを使用する] をオンにし、最大 3 文字のセレクターを入力し、生成された CNAME に選択内容が反映されるように保存する方法について説明します。実装前に現在のインターフェースの受け入れられる値を確認してください。これは製品固有の制限であり、普遍的なものではありません DKIM セレクターの長さのルール。
新しいページのデフォルトのレコードを適合させるためだけに、既存のセレクターを上書きしないでください。既存の各レコードを所有するサービスと、そのサービスがまだメールに署名しているかどうかを特定します。構成がすでに発行されたレコードまで進んでいる場合、ガイドではそれを削除し、カスタム オプションを選択するために再度開始することが説明されています。これは既存の認証構成への変更であり、特に運用メールがすでに認証構成に依存している場合は、影響を検討する必要があります。
ソースには重要な警告が追加されています。構成を削除して再作成すると、最初のCNAMEも変更される可能性があります。セレクターを含む 2 つの名前だけでなく、新しく発行されたセット全体を確認してください。 DKIM に見えるレコードを更新しても、古い最初のエイリアスを保持する受け入れチェックリストでは、隠れた不一致が残る可能性があります。変更レコード内で古い値と新しい値を区別できるようにし、無関係な依存関係を削除しないでください。
新しい連絡先電子メール ドメインを構成の移行として扱う
このガイドでは、連絡先メールのローカル部分の変更とドメインの変更を区別しています。同一ドメインのアドレスを変更する場合、文書化されたワークフローに従って配信性設定を変更する必要はありません。別のドメインでも同様です。このガイドでは、古い配信性構成を削除し、連絡先電子メールを更新し、セットアップを再度完了する方法について説明しています。このシーケンスは、単なる表面的な編集ではなく、明示的な所有者とロールバックの決定を伴う移行として計画する必要があります。
新しいドメインが組織によって制御されていること、およびそのDNS所有者が発行されたレコードを公開できることを確認します。通常の使用を再開する前に、スケジュールされた通知のタイミングと必要な証拠を確認してください。以前のドメインが Verify に合格したという事実は、その結果を新しいドメインに転送しません。適切なチェックが完了するまで、新しい ID を未検証として明確にマークしながら、コンテキスト用に以前の構成の受け入れレコードを保存します。
配信を約束せずにメッセージのアイデンティティを検証する
別途承認された受け入れ演習では、無害な代表メッセージと信頼できる受信者の結果を検査する必要があります。表示されている作成者ドメイン、署名ドメインとセレクター、エンベロープ ID、および実際のプラットフォーム ルートを記録します。 RFC 6376 、セクション 3.5 を定義します DKIM署名 フィールド、および RFC 9989 、セクション 4.4 説明する アライメント。 DNSチェックが成功しても、メッセージ レベルの関係に代わるものではありません。
保存されているセットアップ ガイドでは、汎用的な CNAME ではなく 3 つの CNAME が提供されています。 SPF include を使用してすべての組織ルートに追加します。一般的なチェックリストでSPFが求められているという理由だけで、2 番目のSPFポリシーを含めたり追加したりしないでください。実際のルートで別のSPF変更が本当に必要な場合は、以下で確認してください。 RFC 7208 、セクション 3.2 および 4.6.4 責任のあるオペレーターと一緒に。認証は身元確認に対処できます。受信箱の配置、サポーターの関与、リンクされたすべてのリクエストの安全性を保証するものではありません。
架空の診断と白紙の合格ワークシート
架空のコミュニティ組織である Riverbank Neighbours には、別のプラットフォーム用のSendGridセレクターがすでにあります。管理者は ControlShift でカスタム セレクターを選択しますが、構成を再作成した後は 2 つのセレクター関連の CNAME のみを更新します。レビューの結果、最初に発行されたレコードも変更されていることがわかりました。提案された修正は、完全な新しいセットを権限のあるゾーンと比較し、他のプラットフォームのセレクターを保存し、新しい検証証拠を取得することです。このシナリオは架空のものであり、実際のDNS観察、サポーター情報、実行されたアクションは含まれません。
- 現在の連絡先電子メール ドメインと影響を受けるメッセージ カテゴリ: ______
- 配信可能性ドメイン名と認定技術連絡先: ______
- 3 つのレコードの所有者/ターゲット セットを完了し、発行時刻: ______
- 既存のセレクターの所有者とカスタム セレクターの決定: ______
- 最初のものも含め、再作成後に変更されたすべてのレコード: ______
- 権威DNSおよび関連するプロキシ設定のレビュー: ______
- 結果と信頼できる受信メッセージ ID の証拠を検証します: ______
- ドメイン移行のタイミング、ロールバック所有者、およびリリースの決定: ______
オリジナルの実装証拠、人による対象のレビュー、現在のソースの適用性、生産ルートのテスト、視覚的なアクセシビリティ、および所有者の公開は未解決のままです。連絡先アドレス、認証構成、 DNSレコードは変更されず、メッセージも送信されませんでした。より広範なカタログ実装要件は、実際の承認されたアカウントとメッセージの証拠に依存します。