従来のアンバサダー製品の境界を確認する
アンバサダーの公式記事「メール送信ドメインのセットアップ方法」は、サポート センターに、従来のアンバサダー バージョン 1 および 2 用に明示的にラベル付けされています。この記事では、自動メールのドメイン セットアップ ワークフローと、それに続く個別の送信アドレス設定およびオプションのキャンペーン レベルのオーバーライドについて説明しています。このガイドは、文書化されたルートに適用されます。新しいアンバサダー エディションに同一のコントロールがあること、または検査されたアカウントがそれらのコントロールを完了していることを証明するものではありません。現在の製品の適用性と実際のテナント生成の記録はオープンなままです。 アンバサダー送信ドメインガイド
ルート インベントリから始めます。アカウント、紹介またはその他の自動メッセージ カテゴリ、意図された可視送信者ドメイン、責任のあるビジネス オーナー、およびDNS管理者です。どのアドレスが応答を受信するかを記録します。追跡リンクに適したドメインが自動的に電子メール配信に適するとは限らず、表示 ID として使用されるアドレスが必ずしも機能するメールボックスであるとは限りません。このインベントリは提案された準備であり、アカウントまたはドメインが検査されたことを示すものではありません。
既存の依存関係を上書きせずにドメインを選択します
文書化されたパスは、「設定」から始まり、「アカウント設定」、「電子メール設定」と続きます。 [ドメインの追加] では、ルート用のドメインまたはサブドメインを受け入れます。続行する前に、プロバイダーは既存の m1 を強調表示します。 _domainkeyエントリは、サブドメインを必要とする競合として検出されますが、DNS プロバイダーの取り決めによっては、エントリを割り当てずにエントリを追加できる場合があることにも注意してください。未使用のサブドメインを推奨し、「メール」または「電子メール」を使用しないことを明示しています。この曖昧さは、既存の認証依存関係を上書きする許可ではなく、サポートされているアカウント固有の取り決めを確認する理由として扱ってください。 アンバサダー送信ドメインガイド
提案されたレビューでは、既存のサービスを誰が使用しているかを特定する必要があります。 セレクタ 候補のサブドメインがすでに別の目的を果たしているかどうか。所有者が安全な移行を確認するまで、アクティブな認証レコードを保存します。製品チェックリストを満たすためだけに、競合する 2 番目のキーを製造しないでください。プロバイダーが指定した衝突ルールが適用される場合は、必要なサブドメインの決定をオプションの優先順位に弱めるのではなく、保持します。
DKIMセレクターは、署名ドメインと連携して、受信者が使用する公開検証マテリアルを識別します。 記録 見た目が似ている所有者は、署名で実際に参照されている所有者の代わりにはなりません。アプリケーションは、対応するプライベートマテリアルで署名する必要もあります。 DNSレコードだけではその動作を作成できません。これらのプロトコルの事実は、一見小さなセレクターの衝突が別の正当なルートに影響を与える可能性がある理由を説明しています。 RFC 6376 、セクション 3.5 および3.6.2.2
生成された完全なレコード セットを保存する
ドメインを追加した後、大使はアカウントに 3 つのTXTが提供されると述べています。 SPF、 MXおよびTXT用 DKIM。実際のレコード ウィンドウを利用可能な状態に保ち、指定された各ホスト/名前と値を承認された変更レコードに転送します。プロバイダーは、コピー制御と、オペレーターがDNSアクセスできない場合に同僚にレコードを送信するオプションを提供します。このドラフトに対してそのような電子メールまたはアカウントのアクションは実行されていません。 3 つのレコード要件が文書化されています。実際のテナント値はそうではありません。 アンバサダー送信ドメインガイド
別のアカウントに属するスクリーンショットからMXターゲット、設定、またはDKIM公開キーを推測しないでください。を代用しないでください CNAME 他の電子メール サービスが CNAME ベースのDKIM委任を使用しているためです。実際に提供されたタイプに従い、意図された完全な所有者名を確認してください。 MX変更には、個別のメール ルーティングのレビューも必要です。認証設定は、共有ドメインでの無関係な受信メール ルーティングを置き換えるための包括的な承認ではありません。
DNSオペレーターは、編集者の [名前] フィールドとは別に、完全修飾所有者を記述する必要があります。一部のインターフェイスではゾーン サフィックスが追加されますが、他のエントリ モードでは完全な名前が必要です。サフィックスを繰り返すと、完全にコピーされた値が間違った所有者の下に置かれる可能性があります。 DNSマスター ファイルの規則は、すべてのグラフィカル エディタが短縮表現を解釈する方法を確立しているわけではありません。フォームの外観だけに依存するのではなく、意図した名前と結果のパブリケーションを比較してください。 RFC 1035 、セクション 5.1
競合するポリシーを追加するのではなく、 SPFを調整する
生成された場合、 SPFレコード すでに適用可能なSPFポリシーを持つ所有者に属している場合は、変更する前に完全なポリシーと既存の正当な送信者を確認してください。 2 つの独立したSPFポリシーを公開すると、それらのアクセス許可が結合されず、永続的なエラーが発生する可能性があります。無関係なままにする TXTレコード 評価された ID に対して適用可能なSPFポリシーを 1 つ維持しながら。短いサービスの例は、承認された別の送信者を消去する権限ではありません。 RFC 7208 、セクション 3.1 ～ 3.3
SPF関連するSMTPを評価します メール送信元 アイデンティティとか HELOアイデンティティ 該当する場合には、単に受信者に表示されるアドレスではありません。承認された証拠が入手可能になったら、このルートで実際に使用されている ID を確認します。また、ネストされた依存関係全体で評価された DNS クエリ用語を確認します。プロトコルの制限は、ネットワーク パケットの数ではなく、単に最初のレコードに出力されるインクルード タームでもありません。 RFC 7208 、セクション 2.3 ～ 2.4 および 4.6.4
TXT形式では、推測に頼らずに注意する必要があります。いくつかの文字列が 1 つのTXTリソース レコードを形成する場合があり、目に見える折り返しや引用符は追加のコンテンツではなく表示される場合があります。意図した論理値を保持し、複数の独立したレコードから区別します。インターフェイスによって表現が変更された場合は、パブリケーションを受け入れる前に結果のデータを確認してください。 RFC 1035 、セクション 3.3.14
ドメインのステータスを 1 つのチェックポイントとして解釈する
プロバイダーは、保留中、検証済み、エラーの状態と、レコード モーダルの検証コントロールを文書化します。一般的なエラーは削除されたレコードや不正なレコード タイプに関連付けられており、変更が反映されるまでに最大 24 時間かかる可能性があると述べています。この間隔はプロバイダーのガイダンスであり、すべてのリゾルバーが特定の時点で意図した値を返すことを証明するものではありません。権威あるDNS証拠とは別に、現在のステータスと観察時間を記録します。 アンバサダー送信ドメインガイド
検証が失敗した場合は、別の編集を行う前に、所有者、タイプ、および完全な値を比較してください。キャッシュに以前の結果がまだ保持されている場合、すでに正しい権限のあるレコードを繰り返し変更すると、診断が困難になる可能性があります。逆に、待機していても、間違った所有者やレコード タイプを修復することはできません。提案されたプロセスは、経過時間を正確さの証拠に変えるのではなく、構成の意図、公開されたDNS 、およびアプリケーションの検証を区別します。
返信可能な送信アドレスとキャンペーン アドレスを構成する
ドメインの検証後、文書化されたワークフローに従って送信電子メールの名前とアドレスが編集されます。返信はそこに配信されるため、大使はそのアドレスでメールを受信することを明示的に要求します。差出人の名前とアドレスに対するオプションのキャンペーン レベルの変更には、同じメール受信要件が適用されます。オーバーライドごとにその前提条件を維持します。検証済みのドメインは、存在しない、または監視されていないメールボックスを返信先として受け入れません。 アンバサダー送信ドメインガイド
メールボックスの所有者と意図した返信処理について、キャンペーンからアドレスへのチェックリストを維持します。承認されたメッセージを評価できる場合は、実際のエンベロープ ID とDKIM署名ドメインを個別に記録します。 DMARC 表示されている From ドメインを基準にして、適格な調整されたSPFまたはDKIM結果が必要です。 「確認済み」と表示されるアプリケーション自体は、すべてのキャンペーンの上書きが意図したものであることを確立するものではありません。 アライメント. RFC 9989 、セクション 4.4
架空の診断: 検証済みのドメイン、使用できない返信アドレス
架空の組織 Maple Circle では、オペレーターが従来の送信ドメインのセットアップを準備し、検証済みの状態を記録します。次に、キャンペーン編集者は、送信者を魅力的だが存在しないアドレスに変更します。別の管理者も、別のルートがすでに所有しているセレクターを再利用することを提案しています。これは発明された受け入れ演習であり、観察されたインシデントや実行されたテストではありません。
レビューでは問題を分離します。キャンペーン オーバーライドに対するプロバイダーの返信可能なアドレス要件を保持し、承認されたメールボックスの決定を取得し、既存のセレクターの依存関係を上書きせずに解決します。その後、実際に受信したメッセージの証拠を保留状態に保ちます。ドメインのステータスもコピーされたDNS値も、キャンペーンの返信、署名、調整の準備ができていることの証拠として扱われません。
空白の承認ワークシート
- 実際のアンバサダーのエディション、アカウント、適用性の確認: ____。
- 承認された送信ドメインまたはサブドメインとビジネス所有者: ____。
- 既存のセレクターの依存関係と衝突判定: ____。
- サブドメインの命名制限が確認されました: ____。
- 生成された 3 つのレコード タイプ、完全な所有者と値: ____。
- 既存のSPFポリシーとメール ルーティングの依存関係は保持されます: ____。
- DNSオペレーター、承認された変更参照およびロールバック所有者: ____。
- アプリケーションのステータス、 DNS観察時間、および未解決のエラー: ____。
- 返信可能なメールボックス所有者を持つ送信アドレスとキャンペーン アドレス: ____。
- 承認されたメッセージ ID、調整証拠、およびリリース承認者: ____。
すべてのエントリは空白です。オリジナルの証拠、人間/SME のレビュー、ソースの適用性、生産ルート、ビジュアル/アクセシビリティのレビュー、および所有者の公開は未解決のままです。テナントのセットアップ、 DNS変更、メッセージの送信は行われていません。認証は、受信トレイへの配置を保証したり、ビジネス リクエストを安全にしたりするものではありません。 RFC 9989 、セクション 2.4