.jpドメインのSPFレコード4万件を分析した

SPF導入率34.1%

SPF（Sender Policy Framework）は、ドメインの所有者が「うちのメールはこのサーバーから送る」とDNSで宣言する仕組みだ。受信側はこれを見て、宣言されていないサーバーからのメールを疑わしいと判断できる。メール認証の基本中の基本で、DMARCやDKIMと比べても設定のハードルは一番低い。

それでも、.jpドメインの65.9%はSPFを設定していない。

前回のDMARC調査で導入率の概要は出したが、今回はSPFレコードの「中身」に踏み込む。includeに何が書かれているか、MXレコード（実際のメール受信先）と整合しているか、DNS lookup数は大丈夫か。レコードがあるだけでは意味がない部分を掘り下げた。

SPFレコードの中身 -- includeで見るメールサービス分布

SPFレコードのinclude:メカニズムには、そのドメインがメール送信に使っているサービスの名前が入る。ここを読めば、.jpドメインがどのメールサービスに依存しているかが見える。

41,520件のSPFレコードから、主要サービスのincludeパターンを抽出した。

Google WorkspaceとMicrosoft 365が上位を占めるのは予想通りだが、3位にXserverが入っているのが日本市場の特徴だ。Xserverは共有ホスティングのデフォルト設定でSPFレコードを自動生成するため、ユーザーが意識しなくてもSPFに含まれる。

ただし、ここに名前が出ていないサービスが多数ある。41,520件のSPFレコードのうち、上位10サービスのincludeにマッチしたのは計15,773件（38.0%）。残り62%は独自サーバーのIP直指定、国内ISPのinclude、あるいはincludeなしの最小構成だ。

MXはGoogleなのにSPFにGoogleがない問題

ここからが今回の調査で一番気になった点だ。

MXレコード（メール受信先）の分析では、.jpドメインのメールサービス利用状況はこうなっている。

Google Workspaceをメール受信に使っている.jpドメインは49,220件。ところが、そのうちSPFレコードにinclude:_spf.google.comを設定しているのは5,475件。88.9%のドメインは、Googleでメールを受けているのにSPFにGoogleを含めていない。

一方、Microsoft 365は72.7%。Google Workspaceとの差は歴然だ。

この差が生まれる理由として考えられるのは、セットアップフローの違いだ。Microsoft 365はドメイン追加時にDNSレコードの設定を強く誘導する。管理コンソールにSPF/DKIM/DMARCの推奨レコードが表示され、設定が完了するまで警告が出続ける。対してGoogle Workspaceは、MXレコードの設定は管理コンソールでガイドされるものの、SPFはDNSホスティング側で手動追加する必要があり、ステップが分離している。

もう一つの要因は、国内ホスティング事業者のデフォルト設定だ。XserverやLolipop!はメールサーバーのSPFレコードを自動で設定するが、そこにはGoogleのincludeは含まれない。ユーザーがGoogle Workspaceに移行してMXだけ変更し、SPFを更新し忘れるパターンが多いのだろう。

~allが79% -- SPFの「本気度」

SPFレコード末尾のallメカニズムは、リストにないサーバーからのメールをどう扱うかを決める。

~all（softfail）は「リスト外のサーバーからのメールは疑わしい」という意味。-all（hardfail）は「拒否してください」という明確な意思表示。現実的には~allでもDMARCと組み合わせればenforcement可能なので、~all自体が悪いわけではない。

問題は、~allのドメインの大半がDMARCを設定していないことだ。DMARC調査で示した通り、DMARC導入率は17.5%。つまりSPFを~allで設定しているドメインの大部分は、SPFもDMARCも中途半端な状態にある。受信サーバーの「お気持ち」にメール配信の可否を委ねている格好だ。

?all（neutral）が312件、+all（pass all）が2件。+allは「全サーバーからの送信を許可する」という意味で、SPFとして完全に無意味。設定ミス以外の理由が思いつかない。

DNS lookup制限に引っかかりそうなドメイン

RFC 7208はSPFレコードの評価時にDNS lookupを最大10回と定めている。include:、redirect=、a:、mx:がそれぞれ1回のlookupを消費し、includeの先にさらにincludeがあればネストされた分も加算される。10回を超えるとpermerror（永続エラー）となり、SPF認証自体が失敗する。

5つ以上のincludeを持つSPFレコードが1,892件（4.6%）。include先のネストを考慮すると、このうち相当数が10回上限に達しているか、ギリギリのラインだろう。

典型的なパターンは、ホスティング事業者のデフォルトSPF + Google Workspace + メール配信サービス（SendGridやMailchimp） + CRM（Salesforce） + サポートツール（Zendesk）のように、サービスを追加するたびにincludeが増えていくケースだ。各サービスのinclude先がさらに2-3回のlookupを消費するので、見た目4つのincludeでも実質8-10回に達することがある。

この調査から見えること

1. SPFは「入れた」だけでは機能しない

SPFレコードの存在だけで安心している管理者は多い。しかし、Google Workspaceの例が示すように、MXを変更してもSPFを更新しなければ、正規のメールがSPF認証に失敗する。SPFは設定して終わりではなく、メール基盤の変更に合わせてメンテナンスが必要な生き物だ。

2. ホスティング事業者のデフォルト設定に頼りすぎている

Xserver（3,229件）やLolipop!（736件）のinclude数は、デフォルト設定がそのまま使われているケースを多く含んでいるはずだ。デフォルトSPFがある安心感が、逆に「自分で設定する」意識を薄めている面がある。特に外部メールサービスに移行した後が危ない。

3. DMARCなしの~allは、ほぼ意味がない

SPFの~allは「softfail = 疑わしいけど受け取ってもいいよ」という曖昧なシグナルだ。DMARCのenforcement（quarantine/reject）と組み合わせて初めて、認証失敗メールを確実にブロックできる。SPFだけ入れてDMARCを入れていない約2万件の.jpドメインは、鍵をかけたつもりでドアが開いている状態に近い。

まとめ

• メール利用.jpドメイン121,772件のSPF導入率は34.1%（41,520件）
• SPFレコードの79.0%が~all（softfail）、-all（hardfail）は19.3%
• includeで最も多いのはGoogle Workspace（5,475件）、次いでMicrosoft 365（4,519件）
• Google Workspace MX利用49,220件のうち、SPFにGoogleを含めているのはわずか11.1%
• Microsoft 365は72.7%でSPF設定率が格段に高い
• 5つ以上のincludeを持つレコードが1,892件（4.6%）-- DNS lookup上限リスク
• SPFだけ入れてDMARCなしが約2万件 -- 防御として不完全

SPFは20年以上前に生まれた仕組みで、メール認証の入口としてはもっとも手軽だ。だからこそ「とりあえず入れた」で止まりやすい。レコードの中身を確認し、MXと整合させ、DMARCと組み合わせる。そこまでやって初めてSPFは機能する。

よくある質問