スコープとプロバイダー固有の構成
を使用してドキュメント送信者ドメイン認証を簡素化する SPF, DKIM そして DMARC。新しいバルクセンダーの記事では、古い k5 からの移行を明確にしています。 DKIMセレクター dkim2048 へ。ドメインを評価するときは、意図された署名ルートの証拠として履歴キーを扱うのではなく、その現在の動作を使用してください。
送信者アドレスで使用されているドメインとその既存の認証レコードをインベントリします。送信者ドメイン ガイドでは、 SPFベースラインv=spf1 include:carmamail.com ~allを公開しています。必要なインクルードを他の承認されたサービスと単一のポリシーにマージします。完全な送信インベントリとルックアップ予算を確認せずに、確立されたポリシーを置き換えたり、ベースラインの終了を採用したりしないでください。
DKIMの場合、新しいガイドでは、記号を Symplify と記載しています。 2048ビット鍵 セレクター dkim2048 を使用します。現在のプロバイダーの公開キーをTXTとして dkim2048 で公開します。 _domainkey .<あなたのドメイン>。スクリーンショットやこの記事から長いキーを転写するのではなく、現在のソースから中断されていないキーをコピーします。 DNSエディターが 255 文字の文字列制限のために複数の文字列を必要とする場合、それらは 1 つの論理文字列を形成する必要があります。 TXTレコード。チャンクを独立した競合するキー レコードに変えたり、公開キー マテリアル内にスペースを追加したりしないでください。
プロバイダーは、k5 の場合のみと説明します。 _domainkeyが存在する場合は、dkim2048 が追加されるまで古いキーが使用され続けます。どちらのキーも公開されていないため、Symplify は独自のドメインを使用して署名しますが、その署名は顧客の From ドメインと一致しません。これが、一般的なDKIMパスが受け入れの証拠として不十分である理由です。受信したキャンペーンの実際の d= 値と s= 値を読み取ります。
該当するDMARCポリシーを公開または確認します。プロバイダーが提供するもの p=none 出発点および報告アドレスの例として使用しますが、メールボックスは実際のものであり、承認されている必要があります。例を反映するために既存のポリシーをダウングレードしないでください。 Symplify は、 domainsetup@symplify.comを通じてセットアップ検証を提供します。そのチームに問い合わせるのは、承認が必要な別個の通信です。また、認証は、受信者の許可、リストの健全性、または表示される購読解除リンクに代わるものではありません。新しいガイドにはこう書かれています ワンクリックで購読解除 ヘッダーはサービスによって追加されますが、表示されるリンクはテンプレート所有者の責任となります。
重要な決断
dkim2048 署名が、プロバイダー ドメインのDKIMパスを受け入れるのではなく、顧客の From ドメインと一致していることを確認します。
公開されたレコードと実際の送信パスを確認する
編集する前に、変更所有者、送信製品、ドメイン、承認されたメンテナンス期間、および以前のDNS回答を記録します。指定されたアカウントまたは文書化されたプロバイダーのワークフローから現在のレコード値を取得します。プロバイダーによって提供される値を、 DMARCポリシーやレポート受信者など、組織が管理する選択肢から分離します。既存のメールボックスMX 、無関係な検証TXTレコード、およびアクティブなDKIMセレクターは、単に新しいサービスが追加されるという理由だけでクリーンアップの候補にはなりません。
公開後に、権威ネーム サーバーにクエリを実行して、正確な所有者とレコード タイプを確認します。クエリ時間、応答サーバー、および完全な応答を記録します。 TXT文字列を 1 つの論理値として比較し、 DNS応答によって TXT 文字列が文字列に分割されます。チェック CNAME ターゲットと開始エイリアス。次に、再帰リゾルバーの答えを比較して、キャッシュの違いを特定します。プロバイダー検証の成功は構成の有効な証拠ですが、実際の受信者が何を受信したかを証明するものではありません。
意図された製品ルートを使用して、承認されたテストのみを管理された受信者に送信します。生のメッセージと信頼できる受信システムを保持します。 Authentication-Results。表示されている From ドメイン、 SMTPを記録します。 メール送信元 または観察された Return-Path ドメイン、すべてのDKIM d= および s= 値、 SPFおよびDKIM結果、および受信者のDMARC結果。 SPFまたはDKIMチェックに合格すると、認証されたドメインが該当するポリシーで表示される From ドメインと一致する場合にのみDMARCがサポートされます。 Reply-To とブランド表示名は、アライメント ID ではありません。 RFC 7208 、 RFC 6376 、およびRFC 9989は、これらの区別のためのプロトコルの基礎を提供します。
受け入れワークシート、回収および証拠の制限
これはオリジナルの受け入れワークシートであり、ライブ テストのレポートではありません。証拠が存在するまで各ゲートを保留中とマークします: アカウント範囲が確認されました。以前のDNSがキャプチャされました。正確に新しい所有者/タイプ/値が公開されました。プロバイダーの検証が完了しました。意図されたルートが実行されました。受信した身元情報が記録される。整合性のある認証が確認されました。他の送信者は影響を受けません。すべてのゲートに人物と証拠ファイルを割り当てます。プロバイダーのダッシュボードが緑色の場合でも、赤いゲートはロールアウトをブロックします。
テストが失敗した場合は、まず、パブリケーションの欠落、キャッシュされたデータの失効、非アクティブなプロバイダー構成、間違った送信ルート、および調整されていない認証を区別します。確認された最小の欠陥を修正し、再度テストします。 1 つのテストに合格させるために、 DMARC弱めたり、他の送信者のレコードを削除したりしないでください。変更によって既存のメールに損害が生じた場合は、承認された回復計画とキャプチャされた変更前の構成を使用して、プロバイダー側の送信者の変更とDNSを調整します。キューに入れられたメッセージまたは承認された重複で古いキーが必要な間は、古いキーを保持します。
この原稿には、顧客テナント、変更前/変更後の権限のあるメッセージ、または実際に受信したメッセージがありませんでした。保持されているソースはドキュメンタリーのワークフローをサポートします。それらは、委託された生きた証拠のゲートを満たしていません。独立したチェッカーによるレビューと人間による SME の承認は保留中です。このガイドを現場で検証されたものとして説明したり、それらの門を通過したものとして公開したりしないでください。
フォールバック署名を不完全な証拠として扱う
文書化されたケース SY-01 では、キャンペーンに From news@example.orgがあり、顧客ドメイン セレクターも公開されておらず、仮想受信者が無関係のプロバイダー ドメインからの署名を示していると想定しています。正確なプロバイダー ドメイン、セレクター、およびSPF結果は意図的に不明であるため、完全なDMARC判定はアサートされません。 DNS所有者は、目的の dkim2048 レコードをキャンペーン所有者と調整し、制御された受信メッセージを取得する必要があります。汎用DKIMパスに顧客ドメインの調整としてラベルを付けたり、欠落している ID を隠すために適用を変更したりしないでください。キャンペーン、確認メール、 DNSアクションは発生しませんでした。
施行境界を維持する
RFC 9989セクション 7.4 ではp=reject,公開するドメインに対してSPFのみではなく有効なDKIM要求し、間接メールとメーリング リストの相互運用性について警告しています。ダイレクト メッセージ テストが 1 回成功しただけでは、すべての正当なルートがより強力なポリシーに対応できるようになっているという証拠にはなりません。実際のギャップを診断しながら、既存の承認された保護を維持します。政策変更には独自の決定が必要です。