最初に Netcore CE または Netcore Email API を特定します
Netcore アカウント ラベルだけでは、 DNSレシピを選択するのに十分ではありません。 Netcore は、Customer Engagement プラットフォーム (CE) と電子メール API 用の個別のドメイン セットアップ手順を公開しています。製品ログイン ページでは、Email API が以前の Pepipost として識別されます。どの製品、テナント、またはサブアカウントがメッセージを送信したか、およびアプリケーションがSMTP 、API 統合、または CE キャンペーンを使用しているかどうかを記録します。両方に Netcore の名前が付いているという理由だけで、古い Pepipost 記事を CE 画面に適用しないでください。 ネットコア製品のログイン, CEドメインのセットアップ, 電子メールAPIの検証.
送信ドメインを追加する前に、実際の顧客向けフローのインベントリを作成します。レシート、ログイン リンク、マーケティング キャンペーンには、アプリケーション所有者と From ドメインが異なる場合があります。それぞれについて、ベースライン メッセージまたは送信失敗、設定された送信者、現在のドメイン ステータス、および誰が権威DNSを制御するかを保存します。以下の手順では、文書化されたブランチについて説明します。アカウントによって生成されたホスト名と値は、例よりも優先されます。
電子メール API: DNS検証を承認から分離する
保持されている Email API セットアップ ガイドでは、ダッシュボードが提供するメール API の公開について説明しています。 SPF TXTとユニークな DKIM TXTレコード、次にDNSレコードの確認」を使用します。 SPF所有者にポリシーがすでに存在する場合は、別の候補を追加するのではなく、必要な承認をそのポリシーにマージします。 SPFレコード。完全なサンプル ポリシーを他の正当な送信者のアクセス許可の上に貼り付けないでください。 DNS検証後、ドメインは自動チェックと手動レビューを含む承認プロセスに入ります。検証されたDNSレコードだけでは、ドメインの送信が承認されたことを証明するものではありません。 電子メール API ドメインの検証と承認.
2 つの結果を別々のワークシート フィールドに保存します。 DNSは正しいが承認が保留中である場合は、アカウントのレビュー ステータスと要求されたビジネス情報を調査します。 DNS編集を繰り返すと、承認に対処せずに動作する構成が不明瞭になる可能性があります。逆に、アクティブなアカウントは、特定の送信者ドメインまたはサブアカウントの準備ができていることを証明するものではありません。
Netcore の説明ガイドでは、既存のポリシーが検出されたときにオペレーターが公開する必要がある改訂されたSPF値についても説明しています。その提案された値を現在の権限のあるレコードと比較します。ダッシュボードが最初にそれを読み取ってから、別のチームがDNS変更した可能性があります。意図的なアクセス許可を保持し、完全な検索パスを評価します。 DKIMの場合は、選択したドメインに関連付けられたホスト名と値を使用します。個別のセレクターは異なるサービスを提供できますが、1 つのセレクターでは値が競合します セレクタ 任意のキーを積み重ねることによって解決されるものではありません。 電子メール API SPFとDKIM説明, SPF処理ルール.
CE: 生成されたすべてのDNS行を検証する
CE ドキュメントでは、[設定] → [電子メール ドメイン] → [ドメインの追加] を指定します。ドメインに入ると、 DNS設定画面に各レコードの目的、タイプ、ホスト名、値、ステータスが表示されます。レコードタイプにはTXT 、 CNAME およびMX 。 Email API の 2 TXT モデルを強制するのではなく、テナントに実際に提供された行をコピーします。ガイドには、生成されたすべてのレコードを構成して検証する必要があると記載されています。 [検証] を使用し、成功したらフローを完了します。 CE メールドメインの追加.
同じ CE ガイドでは、成功、保留中、エラー、移行済みを区別します。 「保留中」および「エラー」の場合は送信できません。また、検証後にホスト名を編集するとドメインが非アクティブになり、すべてのレコードの再検証が必要になることも警告します。ホスト名の編集は、中断のリスクを伴う制御された変更として扱います。 DNS設定のダウンロードが利用できると、証拠の受け渡しに役立ちます。これは、レコードが公開されたこと、または受信者がメッセージを認証したことを証明するものではありません。
組織の通常のインバウンドを再ポイントしないでください MXレコード 単に生成された行がMXを使用しているためです。まず、テナントが示す正確な所有者と目的を特定します。送信またはバウンスのサブドメインは、独自のDNS構成を持つことができます。検討された公開テキストは、ユニバーサル CE ホスト名、 MXターゲット、またはDKIMセレクターを正当化するものではありません。
カスタム エンベロープ: 公開とアクティベーションは異なる手順です
Netcore Email API はカスタムを個別に文書化します。 Return-Path プロセス。ここでは、サブドメインの選択、提供されたCNAMEマッピングの公開、配信チームにアカウントのカスタム エンベロープ/ Return-PathおよびDKIM有効にするよう依頼する方法について説明します。この文書化されたプロセスは、公開されたCNAMEだけでは、メッセージが ID を切り替えたという証拠にはならないことを意味します。このオプションに依存する前に、現在のテナントの指示とアクティベーション状態を確認してください。この記事では Pepipost 時代の命名が残っているため、その対象やサポート プロセスを CE に一般化しないでください。 電子メール API のカスタムReturn-Path.
カスタム エンベロープが必要な理由を決定します。実際のエンベロープ ドメインが From-domain と一致する場合にのみ、調整されたSPFパスを提供できます。 アライメント 要件とSPFに合格しています。関連するサブドメインは緩和されたアライメントを満たすことができますが、厳密なアライメントではドメインの正確な同等性が必要になります。検証され、調整された DKIM署名 すでに供給している可能性があります DMARC パス。 DMARC必要な調整された受け渡しメカニズムが 1 つだけであるという理由だけで、プロバイダーが必要とするDNSレコードを削除しないでください。 DMARCアラインメント ルール.
製品固有の Netcore ワークシートに記入します。
テナント/サブアカウントおよび送信ドメインごとに 1 つのコピーを使用します。複数の目的を 1 つにまとめるのではなく、生成された各DNS行を番号付きの個別のエントリにコピーします。
- 製品: CE / 電子メール API。テナント/サブアカウント: ______。アプリケーションまたはキャンペーン: ______。
- 対象ドメイン: ______。現在構成されている送信者: ______。 DNS機関とオペレーター: ______。
- 生成された行番号: ______。目的： ______。所有者： ______。タイプ： ______。正確な値の証拠: ______。正式な結果と UTC 時間: ______。
- 既存のSPF権限は保持されます: ______。 DNS ルックアップ評価を完了します: ______。
- ドメインDNS状態: ______。 API 承認状態 (該当する場合): ______。証拠の日付: ______。
- CE ホスト名の変更は計画されていますか? ______。再検証と中断の所有者: ______。
- カスタム封筒が必要ですか? ______。公開所有者: ______。プロバイダーのアクティブ化の確認: ______。受信したエンベロープの ID: ______。
- テスト ワークフローとメッセージ ID: ______。ドメインから: ______。 SPFドメイン/結果: ______。すべてのDKIM
d=/s=/ 結果： ______。 - 受信側のDMARC結果: ______。アライメントモードと通過パス: ______。
- バウンス処理チェック: ______。ロールバック ルート: ______。リリース承認者: ______。
診断ルール: 信頼できるデータの欠落は出版の問題です。保留中の API 承認はサービス承認の問題です。公開後にエンベロープが異なる場合は、アクティベーションまたはルーティングの問題です。別の変更を行う前に、失敗を正しい所有者に割り当ててください。
機能した架空の診断: 検証済みのDNS 、古いエンベロープ
架空のトレーニング例であり、Netcore テストの結果ではありません。アプリケーションは次から領収書を送信します receipts.example。その所有者はアカウントのDKIMレコードを公開し、カスタム エンベロープを要求しました。 bounce.receipts.example。受信したメッセージは依然として無関係なサービス エンベロープを使用していますが、 DKIM次のようにパスします。 d=receipts.example。信頼された受信者はDMARCパスを報告します。
ワークシートは両方の結果を説明しています。DKIM DKIM位置合わせされた通過パスを提供します。カスタムエンベロープのカットオーバーはまだ証明されていません。管理者は、プロバイダーのアクティベーションが行われたかどうか、およびアプリケーションが目的のテナントを使用しているかどうかを確認します。 SPF権限をさらに追加する receipts.example そのメッセージ内のサービスが所有するエンベロープは変更されません。アクティベーションが確認された後、新しいレシートには予期されたエンベロープと正常なバウンス処理が示されている必要があります。
2 番目の架空の CE ケースでは、キャンペーンの開始中に検証済みのホスト名が編集され、ドメインが非アクティブになります。正しい応答は、必要な再検証を完了し、CE が許可するまで送信を一時停止し続けることです。電子メール API 承認チケットは、間違った製品ワークフローに対処することになります。
受け入れと回復
権威DNSで正確なレコード所有者を照会し、再帰的な結果をタイムスタンプと比較します。受信した署名とダッシュボードを検査します。公開されたDKIMキーは可用性を証明するものであり、アプリケーションがそのキーを使用したことを証明するものではありません。 API の送信が成功すると、受信箱の配置ではなく、サービスによって受け入れられたことが証明されます。レビュー バンドルに実際のリセット トークンや顧客データを含まず、管理されたトランザクションと受信者を使用します。 DKIM検証.
変更前のDNSおよびアプリケーション設定を保存します。新しいルートが失敗した場合は、影響を受ける送信者を一時停止し、変更された構成のみを復元して、新しいメッセージをテストします。重複を避けるために、トランスポートを切り替える前にキューに入れられた送信を確認してください。無関係なドメインやキャンペーンは変更の対象外に保ちます。
この原稿では、ライブ Netcore テナント、 DNS変更、受信メッセージはテストされていません。ワークシートと例は準備資料です。現在の製品/テナントの適用性、アクティベーションと承認の証拠、権威DNS 、ライブ メッセージ テスト、ビジュアル レビュー、および SME による人間の承認は、リリース前に引き続き必要です。