DNS変更する前にビジネス ID を選択してください
EngageLab Email には、カスタム ドメイン送信とホストされた共有ドメイン ルートの両方があります。これらは異なるアイデンティティの選択であり、交換可能なショートカットではありません。受信者に組織のドメインを表示する必要があるかどうかを決定します。プロバイダー所有のアドレスからのテストが成功しても、ビジネス ドメインが認証されていることは証明されません。 DNS設定を開く前に、正確なアプリケーション、表示される送信者アドレス、メッセージ タイプを記録します。
送信設定のドキュメントでは、初期テスト ドメイン、個別の共有ドメイン機能、およびカスタム ビジネス ドメインについて説明しています。その共有ルートは、そのホストされた名前空間上に表示されるアドレスを持つ、 base.engagelab.comのサブドメインを使用します。ビジネス ドメインのロールアウトには、カスタム ドメイン ワークフローを使用します。共有された評判や無料割り当てに関するサービスの主張を、配信保証や契約上の権利として扱わないでください。商用制限については別途ご確認ください。
ドメイン固有の構成を取得する
[設定]、[ドメイン] で、送信ドメインを作成または選択し、現在のDNS指示を取得します。エンゲージラボのリスト SPF, DKIM 必要に応じてMXと DMARC 検証状態ではオプションです。未検証とは、必要なチェックが欠落していることを意味します。使用可能とは、必要なチェックに合格したことを意味します。検証済みとは、表示されたすべてのチェックに合格したことを意味します。これらのラベルは、受信メッセージの判定ではなく、製品の検証を説明します。
DNS所有者に、公開前に提案されたレコード セット全体を確認してもらいます。 MX変更は、その所有者名の受信ルーティングに影響します。提案された名前がすでにスタッフメールを受信している場合は、そのメールエクスチェンジャーを置き換えるのではなく、一時停止して衝突を解決します。専用の送信名前空間を使用すると衝突を減らすことができますが、その適合性を実際のアカウント構成に対して確認する必要があります。すべての変更の所有者名、タイプ、値、TTL、古い値、および理由を記録します。
Domain API ドキュメントでは、 SPF 、 DKIM 、 MXおよびDMARC構成値とレコードごとの検証結果が公開されています。これは、再利用可能なサンプル認証情報やDNSキーのソースとしてではなく、アカウントが何を期待しているかをクロスチェックするのに役立ちます。独自のドメイン オブジェクトから値をコピーします。サンプル ドメインの公開キーは決して再利用しないでください。 セレクタ を適用するか、他の正規のメール ストリームを確認せずにそのサンプル拒否ポリシーを採用します。
無関係な権限を置き換えずに公開する
権限のあるDNSホストで、必要な正確なレコード タイプと所有者名を追加します。 DNSパネルはゾーン名を追加するかどうかによって異なるため、結果の完全修飾名を検査してください。セレクターが間違って配置されると、受信者が決してクエリしない、一見もっともらしいレコードが残る可能性があります。完全なキーデータを保存し、他のデータを一度に追加することを避けます。 CNAME 所有者。
SPFがすでに存在する場合は、新しい承認をその単一のSPFポリシーに調整します。同じ名前で 2 番目のv=spf1ポリシーを作成しないでください。単に表示されるインクルードを数えるのではなく、結合されたポリシーの DNS ルックアップ依存関係を評価します。ドメイン所有者が変更を別途承認しない限り、アクティブな送信者と確立された最終修飾子を保持します。これらの手順のいずれも、無関係なメール サービスへのアクセス許可の拡大を許可するものではありません。
信頼できる記録をクエリし、保存されたアカウントの指示と比較します。次に、キャッシュの有効期限が切れた後に EngageLab 検証を再実行します。ドキュメントに記載されているDNS遅延の推定値は、普遍的な期限ではありません。間違った権威ある回答は待っていても修復されません。プラットフォームと信頼できる応答が一致しない場合は、リゾルバー キャッシュのトラブルシューティングを行う前に、両方をタイムスタンプとともに保存してください。
アプリケーションを目的のルートにバインドする
また、EngageLab は、バルク制限によってトリガー メッセージが遅延しないように、トリガー メールとバルク メールには異なるプライマリ ドメインを持つ異なる送信ドメインを使用するようユーザーに指示しています。 API_USER ルートをバインドする前に、アカウント所有者にこの分離を確認してください。同じプライマリ ドメインの 2 つのサブドメインは、指定された指示を満たしていません。メッセージの種類ごとに承認されたドメインを記録します。
文書化された API_USER 設定では、送信ドメインとトリガーまたはバッチ メッセージ タイプが関連付けられます。アプリケーションが意図した関連付けを使用していることを確認します。本番環境で別の資格情報を使用しているときに 1 つの資格情報をテストすると、誤解を招くグリーンの結果が生成される可能性があります。秘密は、この証拠記録、スクリーンショット、サポート添付ファイルではなく、承認された秘密ストレージに保管してください。
アプリケーション、環境、API またはSMTPトランスポート、メッセージ タイプ、バインドされたドメイン、表示される From アドレス、所有者、ロールバック ルートなどの小さなルート ワークシートを作成します。制御された受信者を使用して、運用環境と同等のコード パスをテストします。プレビュー、テスト アカウント、または無関係なアプリケーションが統合を証明していると推測しないでください。時間に敏感なトランザクション メールの場合は、一括キャンペーンの成功に依存するのではなく、トリガー ワークフローを明示的にテストします。
受信したメッセージとの整合性を証明する
元の受信メッセージと信頼できる受信者を保持する Authentication-Results。レコード From、エンベロープ ドメイン、すべてのDKIM d= および s= 値、 SPF結果、 DKIM結果、およびDMARC結果。 SPFエンベロープ ドメインを認証します。 DKIM署名ドメインを認証します。 DMARCは、該当するモードで表示される From ドメインに合わせて認証されたパスが少なくとも 1 つ必要です。認証は受信トレイへの配置を保証するものではありません。
EngageLab のデフォルトではない合成推論の例: receipts@example.comから、エンベロープbounce@other.example.netおよびd=example.com. other.example.netのSPF example.comと一致しませんが、署名は正確なDKIMを提供します アライメント。その署名が存在しないか無効な場合、想定されるDMARCパスはサポートされません。合格などの裸の単語で間違ったドメインが隠蔽されないように、評決の横に ID を書きます。
変更を閉じてリカバリを保存します
検証が失敗した場合は、問題がDNS 、ドメインの関連付け、またはメッセージの署名のいずれであるかを特定します。ドメイン全体のDMARCポリシーを弱めるのではなく、正常であることがわかっているアプリケーション ルートを復元します。キューに入れられたメッセージでまだ使用されているキーは削除しないでください。成功したら、承認されたDNS差分、アカウント検証、ルート ワークシートおよびメッセージ証拠を保持し、トランスポートまたはドメインの変更後に繰り返しチェックをスケジュールします。
これはドキュメント構成ガイドです。このドラフトでは、EngageLab テナントは変更されず、運用DNSも測定されず、実際の受信メッセージ ID テーブルは収集されませんでした。上記のチェックはオペレーターの承認作業であり、結果を要求するものではありません。実稼働展開の前に、人の承認とルート固有のテストが引き続き必要です。
リリース前にドメイン バインディングの不一致を解決する
文書化されたケース EL-01 では、実稼働トリガー アプリケーションがホストされた共有ドメイン API_USER にバインドされたままである一方で、コンソールがnotify.example.comを使用可能にマークすると想定しています。対象となる From は、 receipts@notify.example.comです。実際の From、エンベロープ ID、および署名結果は収集されていません。使用可能なDNS状態は、意図されたアプリケーション ID を証明できません。アプリケーション所有者は、無害な制御受信テストの前に、バインドされたドメインとトリガー タイプを承認されたルートと調整する必要があります。ワークシートを緑色にするためだけに資格情報を作成したり、 MXを変更したりしないでください。 API 呼び出し、シークレット、 DNS編集、またはメッセージは実行されませんでした。
施行境界を維持する
RFC 9989 セクション 7.4 では、ドメイン公開にはSPFのみではなく有効なDKIMが必要です p=reject、間接メールとメーリングリストの相互運用性について警告します。ダイレクト メッセージ テストが 1 回成功しただけでは、すべての正当なルートがより強力なポリシーに対応できるようになっているという証拠にはなりません。実際のギャップを診断しながら、既存の承認された保護を維持します。政策変更には独自の決定が必要です。