ガイド · Cloudflare DMARC

プロダクトチームはCloudflareのDMARCをどのように安全に導入すべきか

CloudflareでDMARCを設定するには、表示されるFromドメインで送信しているすべてのサービスを洗い出し、管理されたテストメッセージでSPFまたはDKIMのアライメントを検証し、正確な_dmarcの名前にTXTのポリシーを1つ追加します。まずはレポートから始め、変更前のDNSの状態を保存し、権威サーバーとキャッシュリゾルバーの応答を検証し、集約レポートを確認してから、quarantineやrejectを要求します。CloudflareはDNSのポリシーをホストまたは分析するだけであり、送信者のアライメントを成立させたり、配信を証明したりするものではありません。

CloudflareのDNSと送信者の設定を切り分ける

Cloudflareが権威DNSを運用し、別のプロバイダーがアプリケーションのメールを送信・署名するという構成もありえます。何かを編集する前に、それぞれの責任範囲を記録しておきましょう。ゾーンはDMARCのTXTポリシーを公開します。各メールプロバイダーは、Return-Path、DKIMの署名ドメインとセレクター、検証、場合によってはレポートを管理します。アプリケーションは、テナント、メッセージの種類、受信者、テンプレート、表示されるFromアドレス、プロバイダーの経路を管理します。有効なDNSレコードであっても、許可されていない送信者、欠けているDKIM署名、アライメントしていないReturn-Path、テナントをまたいだFromの値を修復することはできません。本番環境、ステージング、サポート、請求、ID管理、監視、CRM、マーケティング、人が使うメールのシステムを、表示されるFromドメインごとに洗い出してください。それぞれに担当者とロールバック時の連絡先を割り当て、ポリシーの適用を強める前に、レポートに現れる不明な送信元を分類します。

受信側が評価するポリシー名を照会する

alerts@notify.example.testから送るメールであれば、まず_dmarc.notify.example.testのTXTから始めます。ポリシーを誤ってWebサイトのホスト、メールエクスチェンジャー、DKIMセレクター、Return-Pathの名前に公開しないでください。現在のDMARCの検出手順では、作成者ドメインに有効なレコードがない場合、該当する組織ドメインまたはパブリックサフィックスのポリシーが選択されることがあるため、照会した名前と選択されたポリシードメインの両方を記録しておきます。Cloudflareを開く前に、既存の権威サーバーとキャッシュリゾルバーの応答を照会してください。同じ名前に複数のポリシーレコードがある場合、タグの構文が不正な場合、競合するCNAMEがある場合は、結果が使えなくなることがあります。ロールバックをインシデント中に再構築するのではなく正確に行えるよう、変更前の内容、TTL、リゾルバーの出力、担当者、変更後に期待される値を記録しておきましょう。

Cloudflareでレビュー済みのTXTレコードを1つ作成する

正しいCloudflareアカウントとゾーンを開き、DNS Recordsに移動して、Add recordを選び、TXTを選択します。apexのポリシーであれば相対名として_dmarcを、対象のサブドメインであれば正確な_dmarcラベルを使います。レビュー済みの値を1つ、引用符を不統一に使わずに入力します。Cloudflareのドキュメントによると、引用符なしで保存された新しいTXTの内容には、囲みの引用符が自動的に追加されます。展開と復旧の計画に合ったTTLを選び、必要に応じてプライバシーに配慮した変更の参照情報を追加し、ゾーン、名前、変更前の値、新しい値を確認してから保存します。TXTのポリシーはDNSのデータであり、プロキシされるWebルートではありません。ホスティングパートナーや別の権威プロバイダーがゾーンを管理している場合は、Cloudflareのダッシュボードが権威を持つと決めつけず、そちらで変更を行ってください。

明示的な判断に基づいてDMARCの値を組み立てる

観察段階のレコードは、v=DMARC1; p=noneと承認済みの集約レポート用URIから始めることができますが、これはあくまで例であり、どこにでも当てはまる値ではありません。バージョンを先頭に置き、要求するポリシーは意図して選び、すべてのレポート送付先を承認しておきます。サブドメインのポリシー、アライメントモード、適用率、レポート関連のタグは、文書化された要件と現行の標準の解釈がある場合にのみ見直してください。他人のruaメールボックスを含むベンダーのサンプルをコピーしたり、構文が通ったからといってp=rejectに飛びついたりしないでください。有効なレコードは受信側に求める処理を表明するものにすぎず、SPFやDKIMが認証に成功すること、認証済みのいずれかの識別子がFromドメインとアライメントしていること、正当な送信経路がすべて洗い出されていること、メッセージが受信トレイに届いたことを証明するものではありません。

実際のメッセージでSPFとDKIMのアライメントを検証する

すべてのアプリケーション経路から、生のヘッダーを確認できる受信者に管理されたテストメッセージを送信します。表示されるFrom、SMTPのMAIL FROM、送信元IPアドレス、DKIMのd=ドメインとセレクター、Authentication-Results、プロバイダーの識別子、メッセージの種類、環境、時刻を記録します。DMARCは、アライメントの取れた認証済みのSPF、またはアライメントの取れた検証済みのDKIM署名のどちらかでパスできます。SPFはSMTPのIDを評価するもので、転送によって変わることがあります。DKIMは選択された内容に対する署名を検証します。どちらもアプリケーションの認可の代わりにはなりません。サブドメインやフェイルオーバー経路も含め、relaxedアライメントとstrictアライメントを意図してテストしてください。プロバイダーAPIによる受け付け、宛先サーバーによる受け付け、DMARCのパス、メールボックス内の振り分け先、エンゲージメントは、それぞれ別の観測結果です。API呼び出しの成功やポリシーの緑色の表示が、より強い配信の証拠として扱われることがないよう、これらの状態は区別しておきましょう。

ダッシュボードの外でDNSとレポートを検証する

保存したら、Cloudflareの権威ネームサーバーと、互いに独立した複数のキャッシュリゾルバーに対して、正確な_dmarcの名前のTXTを照会します。生の応答、選択されたポリシードメイン、TTL、リゾルバー、タイムスタンプ、パーサーの結果を保存します。使えるレコードがちょうど1つであること、v=DMARC1が先頭にあること、必要な値が有効であること、レポート用URIが承認済みであることを確認します。想定されるキャッシュ期間が過ぎたら、もう一度繰り返します。再度管理されたテストメッセージを送信し、受信側のヘッダーを確認します。CloudflareはDMARC Managementを、送信元とSPF、DKIM、DMARCの集計結果を確認する手段として説明していますが、レポートは受信側が遅れて提供する観測結果であり、リアルタイムの完全な調査結果ではありません。プロバイダー側の証拠と突き合わせてください。リゾルバー間で結果が食い違う場合、低頻度のトラフィックが見当たらない場合、不明な正当な送信元がある場合、管理されたテストメッセージがアライメントしていない場合、レポートの量に予期しない変化がある場合は、作業を一時停止してください。

Cloudflare DMARC ManagementをDNSの変更として扱う

Cloudflareによると、DMARC Managementを有効にすると、レコードが存在しない場合は作成を促されたり、既存のruaタグにCloudflareの集約レポート用アドレスが追加されたりすることがあります。この変更案は本番インフラと同じようにレビューしてください。変更前の値をエクスポートし、既存の送付先が意図どおりに残ることを確認し、ドメインの範囲を検証し、ロールバックできる状態を保ちます。有効化に関するドキュメントには、現時点での対象がapexドメインであることと、外部のSPFレコードに関する注意点も記載されています。この機能が、別の場所でホストされているSPFの経路を安全に書き換えられると推測しないでください。送信元やIPアドレスが一覧に表示されていても、どのアプリケーション、テナント、人物がそれを許可したかは証明されません。また、行がないからといってトラフィックが存在しないことも証明されません。この画面は証拠の収集に使い、権威DNS、生のメッセージ、プロバイダーのログ、アプリケーションの監査記録といった証拠も保持しておいてください。

証拠に基づいて段階的に適用を強める

すべての正当な送信者、メッセージの種類、曜日ごとのパターン、バッチジョブ、フェイルオーバー経路、低頻度のワークフローをカバーできるだけの期間、観察を続けます。送信元は、自社所有、承認済みベンダー、転送、不明、不正のいずれかに分類します。より強い処理を要求する前に、正当なトラフィックのアライメントを修正してください。実施可否の判断基準には、有効なDNS、管理されたテストメッセージのパス、許容できるアライメントのカバー率、不明な正当な送信元がないこと、インシデントの担当者、サポート体制の準備、テスト済みのロールバックを含めるべきです。ポリシーの強化は、範囲を限定した承認済みの変更によってのみ行い、認証とビジネス上の失敗の両方を監視します。正当なメッセージが拒否された場合、レポートが届かなくなった場合、予期しない送信元が現れた場合、リゾルバー間で不整合がある場合、プロバイダーを移行した場合、サブドメインへのポリシーの継承で予想外の事態が起きた場合は、ロールバックするか一時停止してください。問題が起きたときに原因を特定しやすいよう、SPF、DKIM、DMARCはできるだけ別々に変更しましょう。

CloudflareのDMARCでよくある失敗を避ける

よくある失敗には、誤ったゾーンを編集する、誤った_dmarcの名前に公開する、ポリシーレコードを2つ残す、壊れた引用符を追加する、承認済みのruaリストを置き換えてしまう、apexとサブドメインのポリシーが同じだと思い込む、低頻度の送信者が現れる前にp=rejectを使う、などがあります。ダッシュボード上の保存済みや検出済みの状態を、メッセージ単位の証拠として扱うのも誤りです。正確な差分、管理された受信者、独立した照会、生のヘッダー、受信者単位に絞ったインシデントログを使ってください。顧客のアドレス、メッセージ本文、APIキー、範囲を限定していないレポートデータは、チケットや分析ツールに含めないでください。計画した期間を過ぎても権威サーバーとキャッシュの応答が一致しない場合、想定していた送信者が見当たらない場合、実際のメッセージがアライメントに失敗した場合は、作業を止め、委任、キャッシュ、レコードの構文、送信者インベントリ、SPF、DKIMをそれぞれ個別に診断してください。

SendHQの位置付け

安全な境界はプロバイダー非依存です。アプリケーションがメッセージを許可し、送信プロバイダーが認証を行い、CloudflareがDNS状態を公開または分析し、受信者がメッセージを評価します。Cloudflareの最新の公式ドキュメント、現行のDMARC標準、観測されたDNS応答、管理された受信メッセージの証拠を信頼してください。

よくある質問

apexのDMARCポリシーはCloudflareのどの名前に置きますか？

ゾーンの_dmarcにTXTを作成します。これは_dmarc.example.comとして解決されます。サブドメインのFrom IDの場合は、その作成者ドメインと現在の検出ルールに基づいて評価してください。

TXTの値に手動で引用符を付けるべきですか？

Cloudflareによると、引用符なしで保存された新しいTXTの内容は自動的に引用符で囲まれます。手動で不統一な引用符を付けるのは避け、そのうえで権威サーバーの生の応答とパーサーの結果を検証してください。

CloudflareはDMARCのTXTレコードをプロキシしますか？

このTXTポリシーに関しては、HTTPプロキシの判断は関係しません。権威DNSに公開し、外部から検証してください。Webプロキシの挙動は別の機能です。

DMARC Managementがレコードを変更することはありますか？

Cloudflareの有効化に関するドキュメントによると、レコードの追加や、Cloudflareのrua宛先の追加を提案する場合があります。その変更は明示的にレビューし、元の状態を保存し、検証し、ロールバックできるようにしてください。

p=noneで、認証に失敗したメールは拒否されますか？

いいえ。p=noneは観察を目的としたポリシーの要求です。受信側により強い処理を要求することを検討する前に、レポートと管理されたテストメッセージを使って正当な送信者を洗い出し、問題を修正してください。

DMARCにパスすれば受信トレイへの到達が証明されますか？

いいえ。証明されるのは、該当するアライメントの取れた認証の評価にパスしたことです。プロバイダーによる受け付け、受信側による受け付け、フォルダへの振り分け、エンゲージメントには、それぞれ範囲を絞った別の証拠が必要です。

SPFはパスしているのにDMARCが失敗するのはなぜですか？

認証されたSMTPのIDが表示されるFromドメインとアライメントしていないか、別の評価エラーが発生している可能性があります。正確なIDと受信側の生の結果を確認してください。

DMARCレコードはメールプロバイダー連携を証明しますか？

いいえ。DMARCレコードだけではメールプロバイダー連携を証明できません。

出典

さらに学ぶ

アプリケーションメールのDMARCチェック方法DMARCレコードの検出、構文、SPFとDKIMのアライメント、ポリシー、レポート、実際のアプリケーションメッセージを、DNSルックアップと配信を混同せずに確認します。SPFレコードの構文解説：アプリケーションメール向けSPFのv=spf1構文、メカニズム、限定子、修飾子、DNSルックアップ上限、includeとredirectの挙動、検証、DMARCアライメントを解説します。アプリケーションメールのDKIMを確認する方法実際の署名を調べ、セレクターとドメインを照会し、メッセージを検証し、受信側の結果を読み、アライメントをテストしてDKIMを確認します。メール到達率サービスの評価方法対象範囲、証拠、認証、フィードバックループ、サプレッション、プライバシー、ポータビリティ、運用への適合性の観点から、メール到達率サービスを評価します。