CloudflareでSPF、DKIM、DMARCを設定する方法

Cloudflareは、ドメインのDNSを管理する場所として最も広く使われているサービスの1つです。ここでSPF、DKIM、DMARCを設定する作業は、3つのTXTレコードを正しい場所に正しい名前で追加することに尽きます。レコードの内容は、DNSをどこでホストしていても変わりません。DNSホストごとに違うのは、エディターの場所と、名前欄に何を入力するかです。このガイドでは、Cloudflareに絞って次の内容を解説します。DNSレコードエディターの開き方、ルートドメイン、DKIMセレクター、_dmarcのそれぞれでNameフィールドに入力する値、そしてオレンジのプロキシのクラウドがTXTレコードにはまったく影響しないといったCloudflare固有の注意点です。

結論から#

3つの送信ドメイン認証レコードはいずれも、Cloudflareダッシュボードの DNS → Records で追加する TXTレコードです。レコード間で違うのは、Nameフィールドと値の入手元だけです。

• SPF：Nameは@（ルートドメイン）。値はv=spf1で始まり、自社に代わって送信することを許可されたサービスを列挙します。SPFレコードは必ず1つだけ公開してください。
• DKIM：Nameは<selector>._domainkey。セレクターと長い公開鍵の値は、どちらもメールサービスから提供されます。自分で作る値ではありません。
• DMARC：Nameは_dmarc。値はv=DMARC1で始まります。ポリシーを適用する前に状況を監視できるよう、まずはp=noneで始めます。

DNSを操作する前に、3つの関係を概念から把握しておきたい場合は、先にSPF・DKIM・DMARCの解説をお読みください。この記事は、Cloudflareでの実践的な手順を扱います。

CloudflareでDNSレコードを管理する場所#

Cloudflareダッシュボードにログインし、設定したいドメインを選択します。Cloudflareでは、ドメインごとのまとまりをゾーンと呼びます。左サイドバーで DNS → Records を開いてください。この1つの画面にそのドメインのすべてのDNSレコードが表示され、上部の青い Add record ボタンが3つのレコードすべての出発点になります。クリックしたら、いずれの場合も Type を TXT に設定します。

Cloudflareはダッシュボードを定期的にデザイン変更するため、この記事をお読みの時点では、左メニューの分類やボタンの表記が変わっている可能性があります。変わらないのは作業の流れです。ドメインを選択したら DNS または Records の領域を探し、タイプ TXT のレコードを追加します。画面がこの説明と完全には一致しない場合は、その領域を探してください。

つまずきやすい前提条件が1つあります。これらのレコードが有効になるのは、ドメインが実際に Cloudflareのネームサーバーを使用している場合に限られます。ドメインを別のレジストラで取得し、サブドメインやプロキシだけをCloudflareに向けている場合は、権威を持つDNSがレジストラ側に残っていることがあります。その場合、Cloudflareに追加したレコードは何の効果もありません。作業を始める前に、Cloudflareでドメインのステータスが有効（active）になっていることを確認してください。

CloudflareでSPF、DKIM、DMARCを設定する#

作業全体を一覧にしたのが次の表です。作成する3つのレコードと、Cloudflareが求めるNameフィールド、それぞれの値の入手元をまとめています。

以降のセクションで、1つずつ順に説明します。

SPFレコードを追加する#

Add record をクリックし、Type を TXT に設定して、Name フィールドに@と入力します。Cloudflareでは、@はゾーンのルート（apex）、つまりドメインそのものを指す省略表記で、SPFを置くべき場所がまさにここです。ドメイン名をすべて入力してもCloudflareが正規化してくれますが、@と入力するのが一般的です。

Content フィールドには、SPFの文字列を貼り付けます。送信元が1つだけの場合の例は次のとおりです。

Type:    TXT
Name:    @
Content: v=spf1 include:_spf.google.com ~all

include:メカニズムは、環境によって変わる部分です。追加すべきものは、各送信サービス（Google Workspace、Microsoft 365、ESP、CRMなど）が案内してくれます。Cloudflareに限らず守るべき重要なルールがあります。1つのドメインに置けるSPFレコードは1つだけです。@にすでにv=spf1のTXTレコードがあり、別の送信元を許可したい場合は、既存のレコードを編集して新しいinclude:を追加してください。2つ目のSPFレコードを作成してはいけません。ルートドメインにv=spf1のレコードが2つあると、互いに無効になってしまいます。複数の送信元を1行にまとめる場合は、SPFレコード作成ツールを使えば、有効な1つのレコードを組み立てられます。TTL は、特別な理由がなければ Auto のままにしてください。

DKIMレコードを追加する#

DKIMは、手書きできない唯一のレコードです。2つの要素がどちらもメールサービスから提供されるためです。1つはセレクター（google、s1、k1、selector1のような短いラベル）、もう1つは公開鍵（v=DKIM1; k=rsa; p=…で始まる長い文字列）です。まず、サービスの管理コンソールでこれらを生成するかコピーしてください。

Cloudflareでは、TXTレコードを追加し、Name フィールドにセレクターに続けて._domainkeyを入力します（例：google._domainkey）。ここにドメイン名を付け足してはいけません。Cloudflareがゾーン名を自動的に補うため、自分で入力するとgoogle._domainkey.example.com.example.comのようにホスト名が二重になります。サービスから提供された鍵は、そのまま Content に貼り付けます。

Type:    TXT
Name:    google._domainkey
Content: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQ...

Cloudflareについて、注意点が2つあります。1つ目は、DKIMにTXTレコードではなくCNAMEを指定するサービスがあることです（鍵を自動でローテーションするESPでよく見られます）。その場合は Type: CNAME を選び、v=DKIM1の値ではなく、サービスが示すターゲットのホスト名を貼り付けてください。サービスが指定するレコードタイプに従います。2つ目は、DKIM鍵が長いことです。以前は、DNSホストによっては長いTXTの値を引用符付きの断片に手作業で分割する必要がありました。Cloudflareは長さを処理してくれるため、鍵全体を1つの値として貼り付け、引用符や改行は自分で追加しないでください。

DMARCレコードを追加する#

もう1つTXTレコードを追加します。Name フィールドには_dmarcと入力します。ここでも_dmarc.example.comではなく、_dmarcだけを入力します。値は、認証に失敗したメールをどう扱うか、レポートをどこに送るかを受信側に伝えます。まずは監視モードで始めます。

Type:    TXT
Name:    _dmarc
Content: v=DMARC1; p=none; rua=mailto:dmarc@example.com

p=noneのポリシーでは、まだ何も適用されません。安全に導入を進めるための日次の集計レポートを有効にするだけです。タグが正しい形式になるよう、DMARCレコード作成ツールで値を作成して公開し、届くレポートを確認しながらp=noneのままにしておきます。すべての正規の送信元が認証に成功していることをレポートで確認できたら、ポリシーをquarantine、次にrejectへと引き上げます。この一連の流れとXMLレポートの読み方は、DMARCの設定手順とDMARCレポートの読み方で解説しています。なお、p=noneにSPFとDKIMを加えた状態は、GoogleとYahooの送信者ガイドラインが大量送信者に求める最低限の水準でもあります。QualisendのDMARCレポートでは、rua=に入れるレポート用アドレスが発行され、その後、送信元ごとに成功数と失敗数が表示されます。

オレンジのクラウドとTXTレコード#

Cloudflareを使い始めたばかりの方は、オレンジのクラウドのプロキシ切り替え、つまりトラフィックをCloudflare経由にする設定を気にすることがよくあります。この設定はここには当てはまりません。プロキシが表示されるのは、アドレスに解決されるレコード（A、AAAA、CNAME）だけです。TXTレコードは常に DNS only で、グレーのクラウドが表示され、切り替えるトグルはありません。これは正常な動作です。SPF、DKIM、DMARCは純粋なDNSの参照なので、プロキシを経由させるものはなく、この点で設定を間違える余地もありません。DKIMでCNAMEを追加した場合は、そのレコードにオレンジのクラウドの選択肢が表示されることがあります。受信側のメールサーバーがターゲットを正しく解決できるよう、そのレコードは DNS only（グレー）にしてください。

Cloudflareにはもう1つ、速さという強みがあります。CloudflareのDNSネットワークは、変更の反映が非常に速く、新規や編集後のレコードは通常、世界中で1～2分以内に有効になります。DNS全般でよく言われる「最大48時間」という目安よりはるかに速い反映です。実際には、レコードを追加してすぐに確認できます。ただし、レコードが誤っているように見える場合は、トラブルシューティングの前に数分待つことをおすすめします。

レコードを確認する#

3つとも公開できたら、正しく解決され、認証に成功することを確認します。まず、送信ドメイン認証チェックにドメインを入力してください。各レコードが存在するか、構文が正しいか、参照できるかがわかります。次に、Gmailアカウント宛てにテストメールを送り、Show original を開きます。spf=pass、dkim=pass、dmarc=passと表示されていれば成功です。SPFに失敗する場合は、v=spf1のレコードが1つだけであること、送信元のinclude:がそのレコードに含まれていることを再確認してください。DKIMに失敗する場合は、Nameフィールドのセレクターの入力ミスか、ドメインを誤って付け足していることがほとんどです。DMARCが見つからない場合は、Nameが正確に_dmarcになっているか確認してください。

ここで線引きを押さえておきましょう。送信ドメイン認証が証明するのは、送信者が誰かという点であり、優良な送信者であるかどうかではありません。認証が整ったクリーンなレコードがあれば、受信トレイへの配信候補として扱われますが、配置を左右するのはレピュテーションとリストの品質です。その他の要素については、メール到達率ガイドで解説しています。

Cloudflareでよくある間違い#

• 2つ目のSPFレコード。 既存のレコードを編集せず、新しいv=spf1のTXTレコードを追加してしまうケースです。すべての送信元を、@の1つのレコードにまとめてください。
• Nameフィールドにドメインを付け足す。 _dmarc.example.comやgoogle._domainkey.example.comと入力すると、ホスト名が二重になります。_dmarcとgoogle._domainkeyだけを入力してください。残りはCloudflareが補います。
• DNSを編集する場所が違う。 レジストラが権威を持つDNSを保持したままだと、Cloudflareで追加したレコードは反映されません。まず、ドメインがCloudflareのネームサーバーを使っていることを確認してください。
• DKIMの値を自分で作る。 セレクターと公開鍵は、メールサービスのコンソールから取得する必要があります。Cloudflare側で生成するものはありません。
• DMARCをいきなりp=rejectにする。 p=noneで公開し、レポートを確認してから段階的に引き上げます。監視の前にポリシーを適用すると、自社のメールが迷惑メールに振り分けられるおそれがあります。

CloudflareでSPF、DKIM、DMARCが有効になったことで、受信トレイへの配信候補として検討される資格を得ました。次は、これらのレコードの裏にあるリストが、その資格に見合う状態かを確認しましょう。無料メールチェッカーなら、存在しないドメインや入力ミスをバウンスする前に見つけられます。ほかの無料ツールも、送信ドメイン認証とリストの衛生管理を維持するのに役立ちます。