SPFレコードが見つからない：原因と修正方法

チェックツールが「no SPF record found」と表示したり、メールヘッダーにspf=noneと出たりすることがあります。どちらも意味は同じです。リゾルバーが特定の名前のTXTレコードを問い合わせたところ、v=spf1で始まるものが一つもなかったということです。メールサーバー自体に問題はありません。問題は、なぜ答えが空だったのかです。多くの場合、確認している名前、または公開している名前が間違っています。

この記事は、その空の答えを診断する手順です。レコードは存在するのにエラーになる場合は、代わりにDNSルックアップが多すぎる場合と10回のルックアップ制限の記事をご覧ください。

「見つからない」とは実際に何を意味するのか

SPFは通常のTXTレコードに置かれます。受信側はメッセージからドメインを取り出し（通常はエンベロープ送信者で、バウンスアドレスやReturn-Pathアドレスとも呼ばれます）、そのTXTレコードを要求して、テキストがv=spf1で始まるものだけを残します。絞り込んだ一覧が空なら、結果はnoneです。これは構文エラーではなく、ポリシーが存在しないということです。

これは、混同されやすい他の二つの状況とは異なります。それぞれ結果も修正方法も違います。

原因1：レコードが間違った名前にある

SPFはメールで使われたドメインで調べられ、他の場所では調べられません。親ドメインから継承されることも、wwwで探されることもありません。www.example.comに公開したレコードは@example.comから送るメールには何の効果もなく、example.comのレコードは@news.example.comから送るメールには何の効果もありません。

典型的なミスはDNS管理画面で起こります。apex（サブドメインのないドメインそのもの）のレコードでは、ホスト欄は通常@ですが、空欄にする画面や、ドメイン全体の入力を求める画面もあります。画面のヒントを読み、フォームを信用せずに問い合わせで確認してください。

• wwwやmailにあるレコード： 内容は正しいがホストが違います。@example.comから送信するなら、apexに移してください。
• ドメインの二重化： ゾーン名を自動で付け足す管理画面では、example.comがexample.com.example.comになります。その名前を問い合わせれば、レコードがそこにあるのが見つかります。
• 送信ドメインの違い： example.comを確認したが、エンベロープ送信者はbounce.example.netやmail.example.comだった場合です。受信側が見たのはあなたのドメインではなく、その名前です。

原因2：メールが使うドメインとは別のドメインを確認している

Fromヘッダーで人が目にするアドレスと、SPFが評価するエンベロープ送信者は別のものになり得ます。多くのメール配信サービスは独自のバウンスドメインを使い、初期設定で自社のドメインを使うものもあります。その場合、SPFはその名前で評価され、あなた自身のレコードはチェックで参照されません。

どのドメインが評価されたかはメッセージヘッダーでわかります（後述）。それがあなたのサブドメインなら、親ドメインのレコードが完璧でも、そのサブドメインに独自のレコードが必要です。送信しないサブドメインはv=spf1 -allを公開できます。

原因3：テキストが有効なSPF文字列になっていない

チェッカーは値の先頭に厳格です。テキストはv=spf1で始まる必要があり、等号があって、その内側にスペースがあってはいけません。次のような惜しい書き方は、どれも「見つからない」になります。

• spf1 include:_spf.example.net ~all（v=がない）
• v=spf include:_spf.example.net ~all（バージョンはspf1でなければならない）
• v = spf1 ...（等号の前後にスペースがある）
• ドキュメントやチャットからコピーした、曲がった「スマート」引用符が含まれたテキスト

引用符には注意が必要です。ホスティング型のDNS管理画面の多くは、半角のダブルクォートを自動で付けるため、自分で入力するとそれがリテラルの文字として保存されることがあります。digの応答に引用符が二重に表示されていたら、自分で入力した分を削除してください。

原因4：編集したゾーンが実際に使われているゾーンではない

これは経験豊富な人でも引っかかります。DNS管理画面で完璧なTXTレコードを追加しても、公開DNSには何も見えないことがあります。その管理画面は、インターネットが問い合わせる先ではないからです。よくある理由は委任です。

• レジストラとDNSホストの違い： ドメインはある会社で登録されているが、ネームサーバーは別の会社（CDN、ホスティング会社、独立したDNSプロバイダー）を指しています。有効なのは、委任先のネームサーバーにあるゾーンだけです。レジストラ自身のDNSページや、以前のプロバイダーに残っているゾーンに追加したレコードは無視されます。

NSルックアップで委任先のネームサーバーを調べ、そのプロバイダーのゾーンを編集してください。「1時間前に追加したのにまだ出ない」という状況は、伝播よりもこれで説明できることがよくあります。

原因5：古いレコードタイプ、キャッシュ、タイミング

初期のSPFドラフトでは、専用のレコードタイプ（番号99、名前はSPF）が使われていました。このタイプは非推奨で、受信側はTXTレコードを評価するため、SPFタイプだけで公開したレコードは現在のチェックからは見えません。DNSプロバイダーがSPFタイプをまだ提供していても、TXTレコードを公開してください。

タイミングは最後に疑うべき原因で、可能性も最も低いものです。リゾルバーがその名前にTXTレコードがないと一度学習すると、ゾーンのネガティブキャッシュ設定に応じた期間、その空の答えを返し続けることがあります。権威ネームサーバーに直接問い合わせれば、疑いを晴らせます。仕組みについては、DNS伝播にかかる時間の記事で解説しています。

DNSが実際に返す内容を確認する

何かを変更する前に、受信側と同じ質問をDNSに投げてみましょう。LinuxまたはmacOSでは次のとおりです。

dig TXT example.com +short
# a healthy answer includes a line like:
# "v=spf1 include:_spf.example.net ~all"

nslookup -type=TXT example.com

答えが空の場合や、サイト認証トークンのようなものしか含まれていない場合は、「見つからない」が確認できます。自分のリゾルバーのキャッシュを避けるには、ネームサーバーに直接問い合わせます。dig TXT example.com @ns1.example.net +shortのように、NSルックアップで得たネームサーバーを使ってください。それでレコードが返り、通常の問い合わせでは返らないなら、キャッシュが原因です。どちらでも返らないなら、そのレコードは有効なゾーンにありません。

このサイトのSPFチェッカーは、入力したドメインのTXTレコードを問い合わせ、v=spf1で始まるものを残し、何も見つからなければ「No SPF record」と報告します。見つかった場合は、includeをたどってルックアップ数も数えます。TXTルックアップは、ある名前のすべてのTXT値を表示するため、レコードはあるのに形式が壊れている場合に、生のテキストが見えて役立ちます。

失敗したメッセージのヘッダーを読む

配信されたメッセージの元のソースを開き、受信サーバーが追加したAuthentication-Resultsヘッダーを探します。SPFの部分には結果と、通常は評価されたドメインが書かれています。ヘッダーの表現は受信側によって異なるため、例は正確な形式ではなくパターンとして扱ってください。

spf=none (example.com does not designate permitted sender hosts)
spf=fail smtp.mailfrom=example.com
spf=permerror smtp.mailfrom=example.com

• spf=none： 評価されたドメインにレコードがありません。この記事の内容が当てはまります。
• spf=failまたはsoftfail： レコードはありますが、送信元IPが許可されていません。送信元を追加するか、ポリシーを修正してください。
• spf=permerror： レコードが壊れています。レコードが2つあるか、ルックアップが多すぎます。

smtp.mailfrom（またはReturn-Path）のドメインに注目してください。SPFが評価したのは、Fromアドレスではなくそれです。ヘッダーの読み方を詳しく知るには、メールの元の送信者をたどる方法をご覧ください。

最小限で安全なレコードを公開する

エンベロープ送信者で使われている名前に、TXTレコードを1つ公開します。レコードは左から右へ読まれるメカニズムの並びで、最後にそれ以外すべてに対する既定の扱いを置きます。

• ip4 / ip6： アドレスまたは範囲を許可します。例：ip4:203.0.113.25。DNSルックアップは消費しません。
• include： 別のドメインのSPFレコードが許可するものを許可します。例：include:_spf.example.net。ルックアップを1回消費します。
• a： ドメイン自身のA（またはAAAA）レコードのIPアドレスを許可します。ルックアップを1回消費します。
• mx： ドメインのMXレコードに指定されたホストを許可します。ルックアップを1回消費します。受信ホストが送信するホストと違う場合は不適切です。
• ~all、-all、?all： 既定の扱いです。~allはsoftfail、-allはfail、?allはneutralです。

すべての送信元が記載されていることを確認するあいだは~allで始め、確信が持てたら-allを検討してください。?allは何も主張せず、主に移行期間用です。受信側はSPFをDKIMやDMARCと合わせて評価するため、末尾よりも、一覧が正しいことのほうが重要です。

よく使われるプラットフォーム向けのヒント

メニューは異なり、変更もされますが、失敗のパターンは繰り返されます。構成の種類ごとに、これらを確認してください。

• Microsoft 365とGoogle Workspace： どちらも、管理コンソールやセットアップガイドからコピーするincludeを提供しています。ここで「見つからない」となるのは、通常、レコードを誤ったDNSプロバイダーまたは誤ったホストに置いたことを意味します。
• GoDaddyなどのレジストラ： ネームサーバーをCDNやホスティング会社に変更した場合、レジストラのDNSページはもはや権威を持ちません。NSルックアップで表示されたプロバイダーでレコードを編集してください。
• Cloudflare： ドメインがCloudflareのネームサーバーを使っている場合は、CloudflareのDNSタブでTXTレコードを追加してください。

SPFがない場合に受信側がすること

SPFがnoneでも、自動的に拒否されるわけではありません。標準は判断を受信側のローカルポリシーに委ねているため、結果はさまざまです。SPFがなく、それを補うDKIMやDMARCもないメールは、疑わしく見える可能性が高くなり、大量送信者向けに認証要件を公開しているプロバイダーもあります。送信先のプロバイダーの最新のルールを確認してください。

SPFはエンベロープ送信者を確認するため、それだけでは、見えるFromアドレスの偽装は防げません。それはDMARCの役割です。SPF、DKIM、DMARCの解説とSPFレコードの確認方法をご覧ください。