Cloudflareのセキュリティチェックと Ask AI で、DNSの地味な設定ミスを直した話

長年 Cloudflare で独自ドメインの DNS を管理し、メールは Google Workspace を使っています。

今回 Cloudflare のセキュリティインサイトでチェックを受けたところ、いくつか未設定の項目が見つかりました。

ついでに Cloudflare 内の Ask AI に自分の DNS レコードを読み取らせてみたら、もっと根の深い問題も出てきました。

※ 独自ドメイン名は example.com として伏字にしています。

はじめに

Cloudflare には、ドメインのセキュリティ設定をチェックしてくれるインサイト機能があります。

今回はそこで指摘された項目を直したのと、あわせて Ask AI に DNS 全体を確認してもらった内容をまとめます。

メールがらみの設定は普段あまり触らない場所なので、放置していたミスがいくつも積もっていました。

症状 / 現象

security.txt が構成されていないという指摘
Bot Fight モードが無効になっていた
DMARC レコードに Cloudflare 側のレポート送信先が入っていなかった
Ask AI に DNS を読ませたら、mail.example.com が CNAME でオレンジクラウド（プロキシ有効）になっていた
SPF レコードが include:aspmx.googlemail.com という誤った記述になっていた
使われていない MX レコードが 8 件も残っていた

原因

security.txt と Bot Fight モードは、単に有効化していなかっただけでした。

mail.example.com がオレンジクラウドになっていた点は少し厄介です。

Cloudflare のプロキシを経由すると、Google のカスタム URL（ghs.google.com 系）の SSL 証明書自動検証が通らず、ブラウザ側で証明書不一致やハンドシェイクエラーが起きるとのことでした。

また転送先も現在推奨の ghs.googlehosted.com ではなく、古い ghs.google.com のままでした。

SPF の aspmx.googlemail.com は Google の MX サーバーのホスト名であり、include の指定先としてはそもそも不正な値だったようです。

正しい include 先は _spf.google.com とのことでした。

MX レコードについては、2023 年以降 Google Workspace 側が smtp.google.com の 1 本に統合されているのに、うちは古いレコード群がそのまま残っていました。

そこに無関係な mail.example.com（優先度 10）まで混ざっていて、送信エラーの原因になり得る状態でした。

flowchart LR
  A[セキュリティインサイトで指摘] --> B[security.txt / Bot Fight を有効化]
  B --> C[Ask AIにDNS全件を確認させる]
  C --> D[mailサブドメインのプロキシ設定を修正]
  D --> E[SPF/MXレコードを整理]
  E --> F[DMARCレポート送信先を追加]

修正内容 / 手順

1. security.txt を有効化

security.txt の自動生成&配置機能

https://zenn.dev

連絡先や優先言語などを入力するだけでした。

項目	内容
連絡先	[email protected]
期限切れ	2027/12/31
優先言語	ja, en

設定後は https://example.com/.well-known/security.txt で確認できます。

2. Bot Fight モードを有効化

Bot Fight Mode

Turn on Bot Fight Mode to challenge requests matching bot patterns on Free plans.

https://developers.cloudflare.com

こちらもトグルを ON にするだけで完了です。

3. DMARC レポート送信先に Cloudflare のアドレスを追加

Just a moment...

https://www.cloudflare.com

# 変更前
v=DMARC1; p=none; rua=mailto:[email protected]

# 変更後
v=DMARC1; p=quarantine; adkim=r; aspf=r; rua=mailto:[email protected],mailto:[email protected]

設定	値	評価
`p=quarantine`	認証失敗メールを迷惑フォルダへ	✅ `none`→`reject`へ飛ばず、影響を確認しながら強化できる中間ステップとして適切
`adkim=r`	DKIMアライメント緩和モード	✅ サブドメインとの一致を許容（例: `mail.washo3.com` と `washo3.com`）。実運用で柔軟性があり推奨
`aspf=r`	SPFアライメント緩和モード	✅ 同上。Google Workspace等の送信元構成で誤検知を防ぐ

今後のロールアウト目安: レポート（rua）を数週間〜1ヶ月確認し、正当なメールが隔離されていないか確認後、最終的に p=reject へ移行するのが推奨フローです。

まとめ

Cloudflare のセキュリティインサイトは基本的なチェックしかしてくれませんが、Ask AI に DNS 全体を読ませると、SPF の記述ミスや不要な MX レコードのような、普段見過ごしがちな部分まで拾ってくれました。

メール関連のレコードは一度設定すると触らないことが多いので、こういう機会に見直すのは悪くないと思っています。

同様に Cloudflare と Google Workspace の組み合わせで運用している方の参考になれば幸いです。

🚀 Way2Go NotionBlog