Clever Elements のドメイン所有権を認証から分離する
Clever Elements は、ドメイン制御の証明と電子メール認証の構成に関する個別の手順を公開しています。このガイドでは、CleverReach や別の同様の名前のマーケティング プラットフォームではなく、文書化された Clever Elements アカウントのワークフローについて説明します。認証記事の日付は 2024 年 4 月 19 日、所有権記事の日付は 2024 年 3 月 19 日です。製品の手順はセットアップの有用な証拠を提供しますが、特に古い場合は、現在のアカウントの適用性を検討する必要があります。 DMARC アドバイスは現在の標準とは異なります。
の ドメイン所有権ガイド ユーザーに、 TXTレコード アカウントからの確認コードが含まれています。記事に掲載されている例示的なコードではなく、発行されたコードを使用してください。このチェックは、関連するDNS構成の制御を示します。それはありません DKIM 公開鍵、 SPF 特定のメール送信が認証されることを証明するポリシーまたは証明。変更リクエストでは、各レコードの目的を明確にしてください。
送信者ドメインと既存の依存関係を特定する
レコードを追加する前に、目的のメールで使用される実際の送信者ドメインと、その権威DNS誰が管理しているかを特定します。 Web リンクに使用されるドメインは、表示される電子メール作成者のアドレスのドメインと異なる場合があります。 Clever Elements は、認証とは別にブランド化されたハイパーリンク ドメインを推奨しますが、その推奨をリンク ブランド化が送信者を認証する証拠として扱うべきではありません。各機能を独自の観点から確認してください。
既存のSPFポリシーのインベントリ、アクティブ DKIMセレクター 所有者と現在のDMARCポリシーを変更する前に確認してください。承認が誤って削除されないように、同じ組織 ID で送信する他のサービスを記録します。選択したドメインがサブドメインの場合は、すべての設定が親から継承されると想定するのではなく、その実際のポリシーと委任を確認してください。この原稿に関しては、顧客のドメイン、メーリング リスト、 DNSレコードは検査されていません。
文書化されたDKIMエイリアスを公開し、署名を個別にアクティブ化します。
役人 認証セットアップガイド を指定します CNAME プレフィックス cemsc が付きます。 _domainkey 、送信者ドメインのdkim.cemsc.netを指します。公開する前に、この文書化された値が現在のアカウントに適用可能なままであることを確認してください。最終的な完全修飾所有者とDNSエディターのサフィックス動作を比較し、その名前の既存のレコードがまだ必要かどうかを確認します。依存関係を理解せずに、占有されている所有者を上書きしないでください。
このガイドでは、レコードを追加した後にアカウントのDKIM送信を有効にすることが明示的に要求されています。最適化オプション ウィンドウと、右上のユーザー アカウントの代替コントロールについて説明します。 DNS公開とそのアカウントの設定は別の手順です。正しいエイリアスでは非アクティブな署名者に署名を生成させることはできません。また、有効なコントロールでは間違ったエイリアスを検証させることはできません。認可されたオペレーターが作業を実行するときは、公的記録の証拠と実際のアカウントの状態の両方を記録します。
CNAME 、公開キーの検索を指定されたプロバイダー ターゲットに委任します。秘密キーは公開されず、受け入れワークシートには秘密の内容は含まれません。 RFC 6376 、セクション 3.5 および3.6.2.2 署名フィールドとTXTキー ストレージを定義します。その後のメッセージ レベルの検証では、どのキーがメッセージに署名したかを証明する、使い慣れたDNSプレフィックスの存在を前提とするのではなく、実際の署名ドメインとセレクターを使用する必要があります。
例全体をコピーするのではなく、 SPF認証をマージします。
Clever Elements ガイドでは、mx、 include:cemsc.net 、およびsoftfail all 用語を含むポリシーが出力されます。これはプロバイダーの例であり、実際の組織のすべての正当な送信者の完全なインベントリではありません。そのメカニズムが実際の認可されたインフラストラクチャと一致するかどうかを確認します。 2番目の独立した組織を作成しないでください SPFレコード または、記事のサンプルを再現するためだけに既存のメールボックスとトランザクション サービスを削除します。
RFC 7208 、セクション 2.4、3.2、および 4.6.4 識別する メール送信元、複数レコードの動作を説明し、評価された DNS に依存する用語に制限を設定します。実際のメール ルートとその完全なポリシーで使用されるエンベロープ ID を評価します。表示される各インクルードを全体の検索コストとして扱うのではなく、評価パスに沿ってネストされた依存関係をカウントします。 SPFインクルードの公開自体は、特定のエンベロープ ID を使用したり保証したりするようにアプリケーションを構成しません。 アライメント 送信者ドメインが表示されます。
古いDMARCレシピと現在の要件を調整する
2024 年のプロバイダーの記事には、サンプルにパーセンテージベースのロールアウト手順と pct タグが含まれています DMARCレコード. RFC 9989 、付録 A.6 現在のDMARC仕様からpctを削除する文書。その古いレシピを現在の標準ジェネレーターとして提示したり、パーセンテージが受信機全体で意図したロールアウト制御を提供すると想定したりしないでください。既存の送信者の対応範囲を確認し、現在の動作と証拠に基づいて移行計画を選択します。
プロバイダーは、レポート アドレスとより強力なポリシーの選択についても説明します。これらはドメイン所有者が決定するものであり、セットアップ ページからコピーする無害なデフォルトではありません。既存のポリシーは、その範囲、正当な送信者、および意図された変更が確認されるまで保持してください。レポートの宛先を選択するには、データの共有と運用上の責任が伴います。この原稿はレポート記録を作成したり、新しい受信者にレポートを送信したりすることを許可するものではありません。バージョン文字列は、発明された 2 番目のバージョンではなく、現在の標準ではv=DMARC1ままです。
RFC 9989 、セクション 4.4 アライメントについて説明します。整合されたSPF結果または整合されたDKIM結果を渡すと、認証条件を満たすことができます。この規格は、両方が合格することを普遍的に要求しているわけではありません。無関係なドメインの 2 つの合格結果は、位置合わせと同等ではありません。規範的な評価ルールとは別にいくつかのメカニズムを構成するというプロバイダーの推奨事項を維持してください。
製品の小切手を狭く解釈する
Clever Elements によれば、同社のシステムはレコードが正しく設定されているかどうかを検出し、チェックが満たされた場合には未送信メールの詳細ビューにある最適化通知を削除するという。ユーザー アカウントで使用されている送信者ドメインを確認する方法についても説明します。これらはアカウントの観察としては有用ですが、実際の郵送ルートの信頼できる受信者の証拠に代わるものではありません。消えた通知は、受信箱の配置や受信者の関与を証明するものではありません。
所有権の記事では、通常の認識推定は数分であり、最大 48 時間の遅延の可能性が示されています。これらは、間違った名前や値が最終的に機能するという証拠ではなく、プロバイダーのガイダンスとして扱ってください。提案された承認演習では、実際の観察時間と構成状態を保持し、別途許可された無害なメッセージを使用して署名と調整の結果を検査する必要があります。ここでは、メール送信、アカウントの切り替え、 DNSクエリ、診断アップロードは実行されていません。
架空の診断: DNS準備はできていましたが、署名が有効になっていませんでした
架空の発行者である Lantern Field Notes は、文書化されたDKIMエイリアスとそのアカウント発行の所有権TXTコードを追加します。両方のレコードがDNSパネルに表示されるため、エディターは認証が完了したことをマークします。レビューの結果、 DKIM送信制御が有効になっておらず、目的の送信者ドメインに対する受信者の証拠が存在しないことがわかりました。
提案された修正は、所有権の検証、キーの検索、署名のアクティブ化、およびメッセージの受け入れを別個のチェックリスト項目に分離することです。すぐに公開鍵を置き換えたり、 DMARCを強化したりするものではありません。この例は架空のものであり、実際の加入者情報、プロバイダーの結果、実行されたテストは含まれません。これは、 DNS準備だけではアクティブな署名構成を確立できない理由を示しています。
空白の受け入れワークシートとリリース境界
- 製品、当座預金口座の適用性、および送信者のドメイン: ______
- 発行された所有権TXTコードのリファレンスと公開検証結果: ______
- DKIMエイリアス所有者/ターゲットおよび既存レコードの依存関係のレビュー: ______
- 許可されたDKIM送信アクティベーションと観察されたアカウント状態: ______
- 完全なSPFポリシーと評価された依存関係の証拠: ______
- 現在のDMARC決定、従来の PCT レビューおよびレポートの承認: ______
- アカウント チェックの結果と信頼できる受信メッセージの整合性の証拠: ______
- 残りの例外、ロールバック所有者およびリリース決定: ______
オリジナルの実装証拠、人による対象のレビュー、現在のソースの適用性、生産ルートのテスト、視覚的なアクセシビリティ、および所有者の公開は未解決のままです。より広範なカタログ要件には、依然として認可された運用証拠が必要です。このガイドでは、ライブ アカウントが設定されていること、古いDMARC例が最新のままであること、または認証されたメールが受信トレイに到達することが保証されていることは主張しません。