アカウント構成を開始点として使用する
Sendloop は、送信者ドメイン認証のためのアカウント ワークフローを提供しますが、そのパブリック認証ウィザードでは専用の認証についても言及しています。 DKIM そして アライメント 設定。これらのページは、認証が利用可能であることを確立しますが、特定のアカウントの正確なレコード セット、署名 ID、またはエンベロープ制御を確立するわけではありません。このガイドでは、文書化されたアカウント ワークフローと管理された検証計画について説明します。専用のDKIM取り決めまたはカスタム エンベロープの要件は、引き続きプロバイダーの確認項目となります。 Sendloop 認証ウィザード、 DKIMおよびドメイン調整設定.
まず、アカウント、承認済みの From ドメイン、およびそれぞれを使用するキャンペーンまたはオートメーションを特定します。アカウントに専用の配送手配があるかどうか、およびそれを確認できる人を記録します。価格ラベル、古いオンボーディング電子メール、またはサードパーティの送信 IP リストから専用インフラストラクチャを推測しないでください。 Sendloop 管理者、 DNS所有者、および組織のレビュー担当者を割り当てます。 DMARC ポリシー。
変更を加える前に、関連する所有者の現在のDNSエントリをエクスポートします。利用可能な場合は、既存の承認済みルートから受信した代表メッセージを 1 つ保持します。すでに機能しているものを一覧表示することで、新しい認証プロジェクトが別の送信者を誤って無効にしてしまうことを防ぎます。ターゲットは、認証され調整された Sendloop ルートであり、ドメインの電子メール構成を完全に置き換えるものではありません。
送信者ドメインのコントロール パネルを開きます
プロバイダーのガイドでは、[設定] > [送信者ドメイン認証] > [送信者ドメインの認証]、[ドメインの追加] の順に案内されます。結果として得られるドメイン コントロール パネルには、アカウント関連の値とDNSレコードの確認アクションが表示されます。 DNSを編集する前にその出力をキャプチャします。現在のインターフェイスが異なる場合は、同等のボタンを推測するのではなく、現在のプロバイダーの指示またはサポートを使用してください。 Sendloop ガイド、電子メール認証ウィザードの使用と認証設定の確認.
それぞれの完全な所有者、 DNSタイプ、値、TTL をその目的とともに記録します。表示されたレコードセットを変更チケットに添付して保持します。パネルに欠落したレコードが表示されている場合は、そのレコードが存在しないか、間違った所有者で公開されているか、または別の値で存在しているかを判断します。別の Sendloop アカウント用に既に構成されているドメインは、置き換えではなくプロバイダーの調整が必要な場合があります。
公開ガイドには、 SPF 例と既存の記録の補正には、同一の内容が記載されていません。テキスト ファイルの準備についても説明します。いずれの詳細も自動生産レシピにしないでください。 DNS 、現在の適用可能なポリシーが含まれている必要があります。ワークステーションに保存されたテキスト ファイルは公開されません。実装前に、アカウント パネルと公開ページ間の不一致を解決してください。 Sendloop ガイド、 SPFレコードのセットアップ.
無関係な権限を拡張せずにSPFを確認する
実際の Sendloop メッセージが使用するエンベロープ ドメインを決定します。これは、表示されている From ドメインが評価所有者である必要があると想定するのではなく、 SPFについて調査する ID です。承認されたカスタム エンベロープの取り決めが存在する場合は、その発行された設定と範囲をキャプチャします。そうでない場合は、観察されたプロバイダー エンベロープ ID を記録し、 DKIMアライメントを個別に評価します。
所有者が変更される場合は、単一のSPFポリシーを保持し、他のアクティブな送信者が必要とする承認を保持します。新しい用語を追加する前に、ネストされたDNSルックアップを確認してください。 SPFの 10 ターム制限は、レコード内に表示される単語の数ではなく、評価中にDNSルックアップを引き起こすメカニズムと修飾子に適用されます。既存の寛容なメカニズムも検討する価値がありますが、それらを削除するかどうかは依存関係を個別に決定する必要があります。 RFC 7208 、セクション 4.5 および 4.6.4.
既存のレコードの置き換えとして広範なサンプル ポリシーをコピーしないでください。これを行うと、不要なホストが承認されたり、障害修飾子が変更されたり、別のプロバイダーが削除されたりする可能性があります。必要な認証が安全に収まらない場合は、停止してメール所有者にサポートされている設計を選択するように依頼してください。別のSPFポリシーを公開したり、見慣れないサービスを削除したりして問題を解決しないでください。
発行された公開DKIMマテリアルのみを公開します
このアカウントに指定された所有者と公開値を使用します。公開ガイドにはDKIM TXTセットアップが示されていますが、そのデモンストレーション キーは顧客のキーではありません。パネルまたはサポートがサポートされている別の記録形式を提供する場合は、証拠なしにそれを変換するのではなく、その指示を保持してください。 Sendloop ガイド、 DKIMレコードのセットアップ.
DNSには公開検証キーのみが属します。 DKIM秘密キーを使用して暗号署名を作成します。送信メッセージに秘密キーは埋め込まれません。公開ガイドの非公式の説明は、署名の秘密を共有するよう求めるものとして解釈されるべきではありません。メッセージには署名が含まれており、検証者は署名ドメインによって識別される公開鍵を使用し、 セレクタ. RFC 6376 、セクション 3.5 および 6.1.
提案された所有者に別のルートに属するアクティブなキーがないか確認してください。衝突には調整が必要です。赤のステータスをクリアするためだけに、動作中のセレクターを上書きするのは安全ではありません。公開後に、 DNSエディターによって追加されたドメイン サフィックスを含む完全修飾名を確認します。タイムスタンプとクエリ結果を保存しておくと、後のレポートで古いキャッシュと間違った所有者やキーを区別できるようになります。
リンクのブランディングを調整の結論の外に置く
プロバイダーのガイドでは、オプションの CNAME エイリアス付きメッセージ リンクの場合。その目的はリンクのブランディングであり、 SPFまたはDKIM一致していることを証明するものではありません。関連する追跡変更が承認され、アカウントが正確なターゲットを指定する場合にのみ実装してください。 Sendloop ガイド、オプション: CNAMEレコードのセットアップ.
提案された所有者を主張する前に、既存の Web サイトまたは使用状況を確認してください。ルート Web サイトまたはライブ アプリケーションのホスト名を追跡ターゲットに指定しないでください。管理されたキャンペーン内に無害なテスト リンクを保持し、レビュー担当者がリンク先と表示されたホスト名の両方を確認できるようにします。認証とリンク機能は個別の受け入れチェックです。ブランドリンクが機能しても、有効な署名は確立されません。
公開後にアカウントのDNSチェックに戻ります。表示されたすべての結果を独立した公開検索と比較します。保留状態を正直に記録します。外部テストがまだ失敗しているにもかかわらず、アカウントが検証済みと表示されている場合は、変更を開いたままにし、メッセージの証拠を使用して残りの境界を見つけます。
受信したメッセージ ID レコードを収集する
顧客データを使用せずに、実際のキャンペーン ワークフローを通じて制御された外部メールボックスに送信します。実質的に異なる From ドメインまたは配信構成に対してこの手順を繰り返します。元のメッセージと信頼できる受信者の結果を、メッセージ ID と UTC タイムスタンプとともに保存します。合格した最初の署名で停止するのではなく、すべてのDKIM署名を記録します。
証拠レコードには、表示される From ドメイン、認証されたエンベロープ ID、 Return-Path、 DKIM d= および s= 値、 SPFおよびDKIM結果、および受信者のDMARC結果。どの受け渡しメカニズムが From ドメインに適合するかを確立します。緩和された配置と厳密な配置では、異なるドメインの比較が必要になります。使用中のモードを記録します。 RFC 9989 、識別子のアライメントの説明.
唯一の受け渡し署名で無関係のプロバイダー ドメインが使用されている場合は、サポートされている顧客ドメイン署名オプションとそのアクティブ化条件をリクエストします。公開ウィザードの専用 DKIM 連絡先メモは、オプションが有効であること、無料であること、すべてのプランで利用できること、または自動的に構成されていることを証明するものではありません。正確なアカウントについての回答を取得します。トラッキング エイリアスを代替エンベロープ ドメインとして表さないでください。
失敗を利用して次のチェックを選択します
行方不明の場合 DKIM署名、アカウントを確認し、[ID とプロバイダーのアクティベーションから] を選択します。署名が失敗した場合は、署名されたコンテンツに対するダウンストリームの変更を調査する前に、観察されたセレクターと公開キーを比較します。異なる送信者アドレスを使用したテストは成功する一方で、影響を受けるキャンペーンは失敗する可能性があるため、診断中はワークフローを一定に保ってください。
SPFエラーの場合は、評価されたドメインと最終的な送信元を特定します。 DMARCエラーを伴うSPFパスの場合は、 SPFインクルードを追加するのではなく、アラインメントを検査します。プロバイダーが必要な ID オプションを文書化できない場合は、その要件をブロックしたままにして、サポートされている別のルートをビジネス オーナーと評価してください。 1 つのプロバイダーのテストが失敗しなくなるようにするためだけに、ドメイン全体のポリシーを引き下げないでください。
アカウント ID、影響を受けるドメイン、発行された公開記録、観察されたDNS回答、メッセージ ID、時間、および関連する受信者の結果を含むサポート バンドルを準備します。パスワード、API キー、受信者リスト、および無関係なメッセージ コンテンツを除外します。再現可能な簡潔な失敗は、 DNS編集の相関性のない複数のスクリーンショットよりも役立ちます。
ワークシートの回復と受け入れ
Sendloop 認証ワークシート (ここで説明するフィールドを使用して別のレビュー レコードを作成) を使用して、レコードの不一致レビュー、専用機能の確認、および最終的な ID 比較を追跡します。エンベロープ機能の応答が欠落していると、通常の調整されたDKIM機能する場合でも、明示的に未解決のままになる可能性があります。すべての空白を仮定で埋めるのではなく、ビジネス要件に対する受け入れを定義します。
変更が失敗した場合は、影響を受ける送信を一時停止し、記録された変更計画を通じて以前に承認された構成を復元します。 DKIM変更をプロバイダーのアクティベーションと調整します。サービスがまだ公開キーで署名している間に公開キーを削除すると、新たな障害が発生します。 Sendloop を廃止する場合は、信頼または追跡レコードを削除する前に、すべてのキャンペーンと自動化が停止していることを確認し、共有SPF依存関係を確認してください。
SPFの不一致の架空の実際の例
架空の記述されたケースのみ: SLP-01 は、 From offers@workshop.exampleを意図したものであると想定します。公開された例には 2 つのプロバイダー インクルードが含まれており、その既存のポリシー命令の名前は 1 つです。現在のアカウントの認証、エンベロープ ID、 DKIM / SPF結果は不明です。 DNS所有者は変更を保持し、アカウント所有者にルート固有の確認を取得するように依頼します。テキスト ファイルとブランド リンクでは認証が確立されません。明確にした後、チームは 1 つのポリシーを検討し、制御されたキャンペーン メッセージを収集します。アカウント、 DNS 、または送信テストは実行されませんでした。
ドキュメンタリー取材と残されたゲート
このドラフトでは、パブリック アカウントのワークフローと安全な検証について説明します。汎用の専用 DKIM やカスタムのReturn-Pathセットアップを確立するものではなく、ライブで調整された Sendloop メッセージが検査されたとは主張しません。これらのアカウント依存の詳細、ライブDNSとヘッダーの証拠、独立したレビュー、視覚的なレビュー、および人間による SME の承認は保留中です。必要なアカウント証拠によってギャップが埋まるまで、元の完全な実装範囲は保留しておいてください。
通過メッセージを施行の準備から切り離す
RFC 9989 セクション 7.4 では、ドメイン公開に有効なDKIMが必要です p=reject 間接メールの相互運用性に関する注意事項。単一の調整されたSPF結果だけでは、拒否ポリシーのロールアウトが正当化されるわけではありません。このプロバイダーの設定とは別に、すべての正当なルートとポリシーの所有権を確認します。