Cloudflare DKIM が動かない時の 5 ステップ

この記事でわかること

• Cloudflare DNS で DKIM が動かないときの切り分け順序
• Proxy（オレンジ雲）が原因のケースの見分け方
• セレクタ名・TXT 分割・反映待ちの確認方法
• SaaS 側の Verify が通らないときの再現手順

まず前提を揃える

正規の設定手順は Cloudflare で DKIM を設定する手順 に整理しています。本稿は「手順どおりに登録したつもりなのに dkim=pass にならない」状態を 5 ステップで切り分けるトラブルシュート編です。

DKIM 自体の検証の考え方やコマンドは DKIM 検証の確認方法とコマンド、セレクタの命名規則は DKIM セレクタとは｜命名規則と運用 を先に読むと理解が早いです。

STEP 1: dig で TXT / CNAME が見えるか

最初に「DNS にちゃんと載っているか」を外から確認します。Cloudflare ダッシュボードで登録済みに見えても、外から引けなければ意味がありません。

# CNAME 委任型（SendGrid / Resend など）
dig +short CNAME s1._domainkey.example.co.jp

# TXT 直接登録型（BYODKIM）
dig +short TXT selector1._domainkey.example.co.jp

何も返らない場合は次のいずれかです。

• レコード自体が登録されていない
• ネームサーバが Cloudflare に切り替わっていない（レジストラ側で NS 確認）
• TTL が長く、設定変更前のキャッシュが残っている

dig +short NS example.co.jp で *.ns.cloudflare.com が返るかを先に確認します。BYODKIM の概念は BYODKIM とは｜AWS SES / Cloudflare の設定 を参照。

STEP 2: Proxy（オレンジ雲）が OFF か

Cloudflare 特有の最大の落とし穴がこれです。

CNAME や A レコードは Cloudflare DNS 上でデフォルト Proxy ON（オレンジ雲）になることがあります。Proxy ON だと CNAME 先が Cloudflare の IP に書き換わって返るため、受信側 MTA は DKIM の公開鍵を解決できません。

DKIM 用のレコード（*._domainkey の CNAME / TXT、SendGrid の em*.example.co.jp 等）は 必ず DNS only（グレー雲） にします。

# Proxy ON の場合、CNAME ではなく A レコードに見える
dig +short s1._domainkey.example.co.jp
# → 104.16.x.x のような Cloudflare の IP が返る = NG

期待される挙動は CNAME がそのまま返ることです。

dig +short CNAME s1._domainkey.example.co.jp
# → s1.domainkey.uXXXXX.wlYYYYY.sendgrid.net.

ダッシュボードで該当行の雲アイコンをクリックしてグレーに変更すれば即座に修正されます。

STEP 3: セレクタ名と _domainkey 付け忘れ

これも頻発します。SaaS 側の指示で「s1._domainkey」と書かれているのに、Cloudflare の Name 欄に s1 だけ入力してしまうケースです。

Cloudflare DNS の Name 欄は ドメイン名を自動補完します。example.co.jp というゾーンで以下のように入力すると:

• s1._domainkey → s1._domainkey.example.co.jp（正解）
• s1 → s1.example.co.jp（誤り。DKIM では引けない）
• s1._domainkey.example.co.jp → 自動補完で二重になり s1._domainkey.example.co.jp.example.co.jp（誤り）

ダッシュボード上は省略表示されるので、dig で FQDN 全体を引いて確認するのが確実です。セレクタ命名の詳細は DKIM セレクタとは｜命名規則と運用 を参照。

STEP 4: TXT 値の分割・改行確認

BYODKIM や DMARC レポート用レコードのように、TXT に長い値を入れる場合は 1 文字列あたり 255 文字という DNS の制約に当たります。これを超える値は複数文字列に分割して連結する仕様です。

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFA…前半…"
"…後半AB+CD/EF=="

Cloudflare ダッシュボードの UI はおおむね自動で分割してくれますが、以下に注意します。

• API / Terraform 経由で登録した場合は自動分割されないことがある
• コピー時に 改行コード（\n）や全角スペースが混入すると検証 fail
• 公開鍵の最後の = パディングまで含めて貼る

検証は dig +short TXT selector1._domainkey.example.co.jp の出力を 1 行に連結して、SaaS 側に提示された値と完全一致するか目視で照合します。

STEP 5: 反映待ち（TTL）と再検証

ここまで問題がなければ、最後は単純な反映待ちです。

• Cloudflare の DNS 反映は通常数分以内
• ただし古いキャッシュを参照する Resolver では TTL（デフォルト Auto = 5 分） だけ古い応答が返る
• SaaS 側（SendGrid 等）の Verify ボタンは内部キャッシュを持つことがあるので、5〜10 分待ってから再 Verify

公共 Resolver 別に確認すると問題の所在が分かりやすいです。

dig +short CNAME s1._domainkey.example.co.jp @1.1.1.1
dig +short CNAME s1._domainkey.example.co.jp @8.8.8.8
dig +short CNAME s1._domainkey.example.co.jp @ns1.cloudflare.com

権威サーバ（Cloudflare のネームサーバ）に直接問い合わせて期待値が返り、公共 Resolver だけ古い場合は、純粋にキャッシュ待ちです。

Proxy 設定の NG / OK 比較

ダッシュボード上の雲アイコンを必ずグレーに揃えます。SaaS 側の verify ステップで失敗する 8 割はこれが原因です。

切り分け後の総合確認

5 ステップを潰したら、テストメールを Gmail / Outlook など複数の受信側に送り、ヘッダの Authentication-Results を確認します。

Authentication-Results: mx.google.com;
  dkim=pass header.i=@example.co.jp header.s=s1
  spf=pass smtp.mailfrom=bounce.example.co.jp
  dmarc=pass header.from=example.co.jp

3 つすべて pass であれば設定は完成です。総合的な確認方法は SPF / DKIM / DMARC の確認方法まとめ にコマンド付きで整理しています。

よくある質問

Cloudflare の Email Routing を使っているのに DKIM が pass しません

Email Routing は 受信転送専用で、自社ドメインからの送信機能ではありません。自社ドメインから送信したい場合は SendGrid / Resend / Amazon SES 等の SMTP サービスが別途必要です。詳しくは Cloudflare で DKIM を設定する手順 の方式 B / C を参照してください。

DKIM は pass するが DMARC が fail します

DKIM 署名ドメインと From ヘッダのドメインが アライメント不一致になっている可能性があります。サブドメイン送信時に起こりやすい問題です。

dig は OK だが SaaS 側 Verify が通りません

SaaS 側の内部キャッシュ待ちが原因のことが多いです。10〜30 分置いて再 Verify、それでも通らなければ SaaS 側のサポートに連絡します。

まとめ

• まず dig で外から見えているか確認
• Cloudflare 特有の最大の罠は Proxy ON。DKIM 用は必ず DNS only
• セレクタ名は _domainkey の付け忘れと二重補完に注意
• 長い TXT は 255 文字分割と改行混入を確認
• 最後は TTL 待ち、権威 NS と公共 Resolver を切り分け

まずは現状を把握しましょう

自社ドメインの DKIM 設定が正しく公開されているかは、ドメイン番人の無料診断で確認できます。設定が複雑で切り分けに困った場合はお問い合わせからご相談ください。