Campaign Monitor は、アカウント設定、パブリックDNS 、検証チェックを通じて送信ドメインを認証します。サブドメインを含め、From アドレスに表示される正確なドメインを使用します。これは送信者固有の構成です。Campaign Monitor を認証しても、同じブランド ドメインを使用する別のサービスは認証されません。
ID を確立して所有者を変更する
組織が目的のドメインを管理していること、およびDNSオペレーターが権限のあるゾーンを変更できることを確認します。既存の保存 セレクタ, SPF そして DMARCレコード。提案されたポリシーの置き換えを受け入れる前に、他の正当な送信者を特定してください。キャンペーンを構成する担当者とDNSを公開する担当者を、メールなどの短いラベルだけでなく、完全なドメイン上で調整してください。
の 送信ドメインガイド 第 2 レベルのドメインを認証しても、プラットフォーム内のそのサブドメインは認証されないと述べています。キャンペーンでnews.example.comを使用する場合は、 example.comアカウント設定をカバーすると仮定するのではなく、その正確なドメインを追加します。
ドメインと生成されたキーを構成する
プロファイル メニューを開き、[アカウント設定]、[送信ドメイン] の順に開きます。 [送信ドメインのセットアップ] または [ドメインの追加] を選択し、完全なドメインを入力して続行します。エディターの正しいフルネームまたは相対名の規則を使用して、生成されたTXT名と値を権威DNSで公開します。キャンペーンモニターに戻り、「レコードを追加しました」を選択するか、後で戻る場合は「レコードを再確認」を選択します。
このセットアップには、都合よく既存の秘密キーをインポートするのではなく、新しく生成されたキーを使用してください。プライベートな署名資料をDNS 、チケット、共有ワークシートから遠ざけます。生成されたセレクターが別のアクティブなレコードと衝突する場合は、セレクターを置き換える前に競合を解決してください。公開サンプルはアカウントのキーではありません。
DMARCを維持し、 SPF慎重に調整する
文書化されたワークフローでは、既存の有効なワークフローが受け入れられます。 DMARC 構成。ドメイン所有者が別の変更を承認しない限り、その施行ポリシーとレポート宛先は維持してください。ポリシーが適用されない場合は、正しい所有者でポリシーを確立してください。あ p=none 例はモニタリング要求であり、強制ではなく、親から継承したポリシーを弱める理由でもありません。
Campaign Monitor ではinclude:_spf.createsend.com.を使用したオプションのSPF認証を推奨します。その承認が構成に適切な場合は、2 つ目の SPF ポリシーを追加するのではなく、単一の既存のSPFポリシーにその承認をマージします。他の正当な送信者を保持し、評価された依存関係パスをSPFの検索制限に対してチェックします。プロバイダーの 電子メール認証の概要 はコンテキストを提供しますが、受信したエンベロープによって、受信者が実際にどのドメインをチェックするかが決まります。
サービス所有のエンベロープのSPFパスは、表示されている From と必ずしも一致しているとは限りません。パスが揃った DKIM署名 SPFパスが調整されていない場合でも、 DMARCを満たすことができます。厳密なSPFを約束しないでください アライメント 単に From ドメインにインクルードが追加されたためです TXTレコード.
キャンペーンのテスト前に記録を検証する
各権威サーバーで生成されたセレクターをクエリし、該当するDMARCおよびSPF応答を検査します。完全な所有者、タイプ、値、タイムスタンプを記録します。 DNSエディターは、長いTXT値を 1 つのレコード内の文字列に分割する場合があります。複数の出版とは異なります DKIM 記録。 DNSプロバイダーの処理に従い、再構築された値を比較します。
Campaign Monitor が検証できない場合は、ドメイン・サフィックスの重複、間違ったレコード・タイプ、キー文字の省略、および権威サーバーの不一致を確認してください。 TTL はキャッシュ制御であり、すべてのバリデーターが更新される保証された時刻ではありません。キャッシュされた否定的な回答は、新しいレコードが作成されるまで存続する可能性があります。
実際のキャンペーンが目的のドメインを使用していることを確認する
新しく認証された From アドレスを使用して、制御されたテスト キャンペーンを送信します。信頼されたものを維持する Authentication-Results、 から、 Return-Path およびすべてのDKIM d=/s=ペア。通過する署名が構成されたモードで From ドメインと一致していることを確認します。テストは合格したが、その後のキャンペーンが失敗した場合は、 DNSを変更する前に送信者のアドレスとルートを比較します。
例示的なケース: example.comは構成されていますが、キャンペーンではアカウントに追加されていないnews.example.comが使用されています。実際のキャンペーン ID に合わせてドメイン設定を修正します。別の ID の構成を解決するために、有効な親ドメイン キーを置き換えないでください。
可能な場合は、受け入れられるまで以前の作業送信者を保持します。アカウントの変更、新しい送信サブドメイン、 DNS移行、またはキーのローテーションの後に再確認してください。廃止する前に、スケジュールされたキャンペーンを停止し、依存関係が使用されていないことを確認してください。この記事はドキュメント ガイドおよび検証計画の提案であり、キャンペーン モニターのライブ テストや配信の保証を示すものではありません。
製品範囲のギャップと厳密な調整を混同しないでください
文書化されたケース CM-01 では、製品にはexample.comが設定されているが、キャンペーン From はnews@news.example.comであると想定されています。信頼できる受け渡しDKIM署名d=example.com, s=demo1.通常の緩和された組織ドメインの調整では、その署名はnews.example.comに調整できます。 adkim=sの場合は完全に一致しません。 SPFおよびその他の署名は不明であるため、厳密モードの全体的な判定は未解決であり、確立されたDMARC障害ではありません。どちらの前提も、Campaign Monitor に意図したサブドメインが設定されていることを証明するものではありません。キャンペーン所有者は、リリース前に正確なドメインのセットアップを完了し、結果として得られる制御されたキャンペーンを検査する必要があります。これらは架空の入力であり、キャプチャされた配信やポリシーを緩和する理由ではありません。
施行境界を維持する
RFC 9989 セクション 7.4 ではp=reject,公開するドメインに対してSPFのみではなく有効なDKIM要求し、間接メールとメーリング リストの相互運用性について警告しています。ダイレクト メッセージ テストが 1 回成功しただけでは、すべての正当なルートがより強力なポリシーに対応できるようになっているという証拠にはなりません。実際のギャップを診断しながら、既存の承認された保護を維持します。政策変更には独自の決定が必要です。