サーバーおよびアプリケーションごとのドメインのインベントリ
実際にメッセージを送信するサーバーまたはサブアカウントについて、SocketLabs 認証を確認する必要があります。まずはアプリケーションのリストから始めます。From ドメインと各アプリケーションが使用する SocketLabs 設定が表示されます。個別の From サブドメイン、顧客ブランド、フォールバック ルートを含めます。複数の組織に代わって送信するサーバーとしては、1 つのブランドが機能しているだけでは不十分です。
プロバイダーは検証済みの送信ドメインを要求し、アドレスが許可されない場合はエラーを文書化します。アドレス確認プロセスや適格なDNS認証機能による所有権の検証をサポートしますが、アカウントの構成と計画が送信ドメイン制御の適用に影響することに注意してください。 SocketLabs 送信ドメイン、送信ドメインの追加と検証.
受信側での認証から送信の許可を分離します。ドメインは、希望する顧客ドメインなしで送信できる場合があります。 DKIM またはエンベロープ ID が使用されています。これらを独立したチェックとして記録し、顧客またはパートナーの ID を承認する前にドメイン所有者の許可を取得します。
キー所有者によるDKIM方式を選択します
SocketLabs では、顧客が提供するTXTキー、プロバイダーが生成するTXTキー、プロバイダーが管理する TXT キーの 3 つの方法を文書化しています。 CNAME。この選択により、誰がキーを管理するか、およびサーバー間でキーがどのように維持されるかが変わります。現在の概要では、署名には From ID との一致が必要であると記載されています。 SocketLabs DKIM概要、3 つの署名方法.
DNS作業を開始する前に決定を記録します。プロバイダー管理の方法の場合、署名構成を変更できる人を特定します。顧客が制御する方法の場合は、秘密キーの管理者と承認されたローテーション プロセスを特定します。キーでいっぱいのスプレッドシートは、許容可能な所有権記録ではありません。ワークシートには、秘密資料ではなく、証拠の参照先と責任者を含める必要があります。
より多くのコントロールが公開されるため、最も複雑なメソッドを自動的に選択しないでください。組織の要件を満たし、実際のオペレーターが保守できる、サポートされているアプローチを優先します。ポリシーで特定のキー管理の取り決めまたは通常とは異なる署名 ID が必要な場合は、サポートされている構成を提示する前にプロバイダーの確認を得てください。
選択した署名方法を構成します
CNAME署名については、公式ガイドで 1 つの委任されたDNSレコードと、機能を有効にする前のアカウント側の検証について説明しています。 CNAMEガイドには dkim がリストされています。 dkim._domainkey.email-od.comを指す送信ドメインの下の_domainkey 。その公開文書のペアを当座預金口座の指示と比較してください。占有されているものを上書きしないでください セレクタ 単に例がその名前と一致しているからです。 DNSホストがCNAME所有者に必要なアンダースコアをサポートできない場合、このガイドでは、ユーザーが考案したスペルではなくTXTアプローチを使用するように指示されます。 SocketLabs CNAME署名ガイド.
目的のセレクター所有者が別のサービスによってすでに使用されているかどうかを確認します。 CNAME無関係なセレクターの上に安全に貼り付けることはできません。代わりに、サポートされている代替案または承認された移行をリクエストしてください。既存のレコード、その依存サービス、および変更の決定を実装チケットに保存します。
TXTガイドでは、プラットフォームでのキーの生成とキー ペアの取得を区別しています。 DNSの公開キーが必要であり、関連する設定を保存する前にそのキーを検証します。生成されたキー フローは、そのプライベート コンポーネントをアカウント内に保持します。 SocketLabs TXT署名ガイド.
選択した方法にプライベート マテリアルのインポートが含まれる場合は、承認されたシークレット処理ワークフローを使用します。公開キーのみを公開します。正確なドメインとセレクターを記録し、DNS エディターの文字列分割後の結果の論理TXT値を検査します。生成されたキーのガイドには、 DNS公開と保存が成功した後は、公開キーがポータルで利用できなくなると記載されています。セットアップ チケットを閉じる前に、レビュー バンドルに秘密キーを保持せずに、公開記録とその来歴を保存します。
バウンス ドメインを別のマッピングとして構成する
SocketLabs は顧客ドメインを実装します SPF 既存のvisible-Fromへの追加を必要とせずに、カスタムバウンスドメインモデルを通じて SPFレコード。そのガイドでは、選択したバウンス サブドメインからtracking.socketlabs.comへのCNAMEを指定します。複数のバウンス エントリを設定できます。一致しないメールは、選択されたデフォルトまたはプロバイダーのフォールバックを使用します。 SocketLabs カスタム バウンス ガイド、セットアップと複数のカスタム バウンス ドメイン.
DNS管理者に相談して未使用の名前を選択し、実際のサーバーでサポートされているマッピングを確認してください。ドメインの通常の受信メール構成をそのまま維持します。バウンス ホスト名はアプリケーション配信 ID であり、ユーザーの返信メールボックスや Web サイトの追跡エンドポイントと混同しないでください。
すべての From ドメインに対して意図した一致を記録し、デフォルトの動作を記録します。デフォルトは、複数ブランドのサーバー上で明確なビジネス レビューに値します。配信が成功しても、予期しないブランドやプロバイダーのアイデンティティが明らかになる可能性があります。設定内の名前だけからアクティブなマッピングを推測しないでください。放出された Return-Path 後で比較するための証拠になります。
公的記録を公開して比較する
承認された変更を行う前に、関連するDNSレコードをエクスポートします。権限のあるサービスとDNSエディターによる相対名の処理を確認してください。 CNAMEチェーンまたはTXT回答を含め、公開された各所有者を個別に検査します。正しいDKIMレコードはバウンス名が設定されていることを証明するものではなく、正しいバウンス レコードはDKIM署名がアクティブであることを証明するものではありません。
SPF 、単に表示される From ではなく、 SMTPエンベロープ ID を使用して評価されます。別のサービスが依然としてルート ドメインのSPFポリシーを必要とする場合は、それを保存します。 SPFポリシーが必要な所有者では、1 つのポリシーを維持し、プロトコルの DNS クエリ期間制限を確認します。 RFC 7208 、セクション 2.4、4.5、および 4.6.4.
キャッシュが関係する場合は、一貫した信頼できる再帰的な回答を待ちます。プロバイダーが確認できない場合 記録、名前を繰り返し変更するのではなく、発行された値と時間指定されたDNS観察をサポート用に保存します。 DNS ホストの制限は、文書化されたサポートされている方法を通じて処理する必要があります。
From ドメインとバウンス一致をそれぞれテストします。
無害なコンテンツを、各マテリアル アプリケーションおよびサーバーを通じて、制御された外部受信者に送信します。時刻、メッセージ ID、プロバイダーまたはアプリケーションのイベント参照を保存します。親ドメインのエントリがサブドメインをカバーしていると想定するのではなく、サブドメインから個別にテストします。
古いCNAMEページでは、適用性の説明で PRA と Sender について言及されていますが、現在の概要とTXTページでは、From の正確な一致について説明されています。アプリケーションが別個の Sender ヘッダーまたはその他の異常な ID を使用している場合は、説明を取得し、その正確な形式をテストしてください。これらの異なるステートメントを黙って普遍的なルールに変換しないでください。
受信者では、目に見える From、 Return-Path 、信頼できるSPF ID と結果、すべてのDKIM d と s、および DMARC 結果。 DKIM検証では、実際の署名内のドメインとセレクターを使用して公開キーを見つけます。 RFC 6376 、セクション 3.5 および 6.1.
渡された各 ID を、該当する下に表示されている From と比較します。 アライメント モード。カスタム バウンス サブドメインは、厳密な同等性を満たさずに、緩和されたSPFアライメントを満たす場合があります。整列したパス DKIM署名 独立してDMARCを満たすことができます。ドメイン検証の成功やプロバイダー ドメイン認証パスだけでは、結果全体を推測するのに十分ではありません。 RFC 9989 、識別子のアライメントの説明とDMARC評価.
障害のあるレイヤーを診断する
送信者が許可されていないエラーの場合は、 DNSキーを変更する前に、検証と正しいサーバーのドメイン制御を検査してください。予期しない署名ドメインの場合は、正確な From と構成されたDKIMエントリを比較します。予期しないReturn-Pathについては、バウンス マッチとデフォルトを調べてください。 1 つを修復しても別のチェックで問題が隠蔽されないように、これらのチェックは別々に保管してください。
DNS正しいにもかかわらず暗号検証が失敗した場合は、パスに沿った署名付きコンテンツまたはヘッダーへの変更を調査します。認証と調整は成功したが、受信トレイの配置が適切でない場合は、受信者のフィルタリング、評判、メッセージの目的を調査します。認証は、配信を約束したり、承認されたアカウントのすべての使用が正当になることを保証するものではありません。
リリース前のレコードのリカバリ
SocketLabs のドメインとサーバーのワークシートに記入します (ここで説明されているフィールドを使用して別のレビュー レコードを作成します)。許可、署名方法、バウンス マッピング、受信した証拠のルートごとのマトリックスを保持します。テストが失敗した場合に、アプリケーションを一時停止したり、以前に承認されたサーバー構成を復元したりできる人を特定します。
キューに入れられたメッセージや他のサーバーがそれらに依存している間は、古い公開キーやバウンス レコードを削除しないでください。アプリケーション所有者とともに廃止を計画し、From ドメイン、サーバー、キー メソッド、バウンス デフォルト、またはDNSプロバイダーを変更した後に再テストします。
デフォルトのバウンス エントリを含む架空の診断ケース
架空のケースのみ: SOCK-01 は、1 つのサーバーがエンベロープbounces.alpha.exampleと合格したSPF結果を含む From news@alpha.exampleを送信すると想定しています。 2 番目のルートは From news@beta.exampleを使用しますが、同じくSPFパスを使用してbounces.alpha.exampleにフォールバックします。リラックスした位置合わせでは、最初に規定されたエンベロープが位置合わせされます。 2番目はそうではありません。どちらのDKIM結果も不明であるため、完全な 2 番目のメッセージの失敗も修復の成功も主張されません。サーバー所有者は、ベータ版のマッピングを承認して検証し、発行されたReturn-PathとDKIM検査する必要があります。サーバー、 DNS 、またはメッセージのテストは実行されませんでした。
受け入れは保留中のままです
対象のサーバーがドメインを許可し、選択した署名方法が検証し、各バウンス マッピングが承認されたものとして動作し、受信者の証拠が必要な調整されたパスを確立する場合、ルートを受け入れます。この未公開のドラフトについては、オリジナル スコープの承認、ライブ テナントとDNSチェック、独立した技術レビュー、ビジュアル レビュー、SME による承認が保留中です。
通過メッセージを施行の準備から切り離す
RFC 9989 セクション 7.4 では、ドメイン公開に有効なDKIMが必要です p=reject 間接メールの相互運用性に関する注意事項。単一の調整されたSPF結果だけでは、拒否ポリシーのロールアウトが正当化されるわけではありません。このプロバイダーの設定とは別に、すべての正当なルートとポリシーの所有権を確認します。