SPFレコードの書式エラーを直す｜原因箇所の見分け方とptrの置き換え

診断で「SPFレコードに問題があります」と表示されたら、まず原因が自分のレコードの書式にあるのか、includeやredirectで指定した参照先にあるのかを見分けてください。この2つは直す場所が違います。あわせて、ptr機構を使っている場合の置き換え方も扱います。ptrは書式の誤りではなく、使っただけでpermerrorになるわけではありません。

結論 — 直す前に、原因が自分のレコードか参照先かを見分けます

自分のSPFレコードの書式が壊れている場合は、レコードを読んだ時点で評価が終わります。RFC 7208 セクション4.6は、次のように定めています。

The syntax of the record is validated first, and if there are any syntax errors anywhere in the record, check_host() returns immediately with the result "permerror", without further interpretation or evaluation.

レコード全体の構文をまず検証し、誤りが1か所でもあれば、その時点でpermerrorという結果になります。誤りの前にある部分が正しく書かれていても機構の評価はまったく始まりません。誤りがレコードの末尾にあっても先頭に書かれたip4は評価されません。

一方、参照先に問題がある場合は、自分のレコードの書式そのものは正しく書けています。includeで指定した参照先が実際に評価されたとき、初めて問題が表面化します。直し方は状況によって変わります。使っていない参照先なら、自分のレコードからその項を削除してください。自分が管理している参照先なら、参照先を直してください。他社のサービスを今も使っているなら、その事業者に確認してください。

Majestic Millionに掲載されている.jpドメイン19,535件を対象にした実測では、自分のレコードに問題があった件数より参照先だけに問題があった件数のほうが多くありました。測定方法と内訳は記事末尾の「調べ方と数値」にまとめています。

現在のレコードと問題の箇所を確かめる

dig +short txt example.jp

example.jpの部分は自分のドメインに置き換えてください。実行すると次のように表示されます。

"v=spf1 include:_spf.example.com ~all"

SPF以外のTXTレコードも同時に表示されることがあります。SPFのレコードは、v=spf1の直後が半角スペースかレコードの終わりになっているものです。RFC 7208 セクション4.5は次のように定めています。

discard records that do not begin with a version section of exactly "v=spf1". Note that the version section is terminated by either an SP character or the end of the record. As an example, a record with a version section of "v=spf10" does not match and is discarded.

v=spf10のように続けて文字が入っているものはSPFのレコードとして扱われません。また、1本のTXTレコードは複数の文字列に分かれて表示されることがあるため、「行」と「レコード」は同じものとは限りません。v=spf1で始まる行が2つ以上表示された場合は、SPFレコードの重複という別の問題で、SPFのDNS参照回数が10回を超える原因と直し方で扱っています。

表示された値は、直す前に控えてください。

メール認証の診断にドメインを入力すると診断結果に問題のある箇所が表示されます。自分のレコードの書式が壊れているのか、参照先で起きているのかは、表示される文言で区別できます。

参照先のドメインが一時的に応答しない場合は、この表示とは別に「参照先を確認できませんでした」という表示になります。これは設定の誤りではなく、確認できなかったことを表しています。この表示が出た場合は、レコードを変更せずに時間を置いてから再診断してください。DNSの一時的な状態が原因であることがあり、設定を変えても直らないことがあります。

自分のレコードの書式が壊れている場合

自分のレコードの書式が壊れている状態は、次の8種類に分けられます。分母はSPFレコードが見つかった15,498件です。

「アドレス」はip4とip6に書く値、「参照先」はincludeとexistsに書く値、「修飾子」はredirectとexpを指します。1つのドメインが複数の状態を持つことがあるため、合計は、自分のレコードに問題があった80件と一致しません。

SPFで使える機構は8つだけです。RFC 7208 セクション4.6.1のABNFが次のように定義しています。

mechanism = ( all / include / a / mx / ptr / ip4 / ip6 / exists )

all・include・a・mx・ptr・ip4・ip6・existsの8つです。これ以外の綴りは機構として認識されず、書式の誤りになります。

解釈できない項がある状態です。全角のスペースや記号が混ざっている、引用符の数が合っていないといった場合に起こります。

v=spf1 ip4:203.0.113.0/24　-all

この例では、ip4:203.0.113.0/24と-allの間に全角スペースが入っています。RFC 7208 セクション4.6.1が定める項の区切りは半角の空白で、全角スペースは区切りとして認識されず、レコード全体が解釈できなくなります。

v=spf1 ip4:203.0.113.0/24 -all

半角スペースに直すと解釈できるようになります。

機構名の綴りを誤っている状態です。

v=spf1 incude:example.com ~all

includeをincudeと書き誤っています。8つの機構名のどれとも一致せず、書式の誤りになります。

v=spf1 include:example.com ~all

includeに修正すると解釈できるようになります。

IPアドレスやCIDR(アドレス範囲)の書き方を誤っている状態です。

v=spf1 ip4:203.0.113.999 ip4: ip4:203.0.113.0/99 -all

IPv4アドレスの各オクテットは0から255までの整数、CIDRの指定は0から32までの整数である必要があります。ip4やip6はコロンの後ろにアドレスを書かないと値が書かれていない状態として扱われます。

v=spf1 ip4:203.0.113.0/24 -all

それぞれ正しい形式に直すと解釈できるようになります。

includeやexistsに参照先が書かれていない状態です。

v=spf1 include: ~all

コロンの後ろに参照先のドメインが必要です。

v=spf1 include:{参照先のドメイン} ~all

{参照先のドメイン}の部分に実際に利用している送信サービスのドメインを入れます。

このほか、redirectやexpの値が空になっている場合や、同じ修飾子が2回以上書かれている場合も書式の誤りになります(RFC 7208 セクション6)。値の違う2つが書かれている場合は、どちらを残すかを確認したうえで一方を削除してください。

画面には貼り付け用の値は出ません。何が正しい値かは自分のレコードの内容によって変わるためです。上の例を参考に、自分のレコードのどこが該当するかを照合して直してください。

読み飛ばされるだけの記述との違い

書式の誤りと混同しやすいものに読み飛ばされるだけの記述があります。これらはpermerrorにはなりません。

未知の修飾子は無視されます。RFC 7208 セクション6が「認識できない修飾子は、レコードのどこに、何回現れても無視しなければならない」と定めているためです(原文: "Unrecognized modifiers MUST be ignored no matter where, or how often, they appear in a record")。

allより後ろに書いた機構も、評価されないだけで書式の誤りにはなりません。この扱いはSPFレコードのall修飾子の違い｜~allと-allはどちらにすべきかで扱っています。

redirectとexpはレコードの末尾に置くことがRFC 7208 セクション6で推奨されています(SHOULD)。ただし構文上はレコードのどこに置いてもよく、位置が理由で書式の誤りになることはありません。

参照先に問題がある場合

自分のレコードの書式は正しいのにincludeで指定した参照先やredirectで委譲した先が実際に評価されたときに問題が起きる場合です。

includeの参照先にSPFレコードが無い場合は、RFC 7208 セクション5.2が定める評価結果の表にもとづきpermerrorになります。参照先の評価結果がnoneのとき、includeを使った側もpermerrorになると定められているためです。

redirectの委譲先にSPFレコードが無い場合も同様にpermerrorになりますが、根拠の条項は別です。RFC 7208 セクション6.1は次のように定めています。

if no SPF record is found, or if the <target-name> is malformed, the result is a "permerror" rather than "none"

この2つは対処が違います。includeは不要なら自分のレコードから削除できますが、redirectは送信元の宣言そのものを委譲しているため、削除すると宣言が丸ごと無くなります。委譲先を直すか、委譲をやめて自分のレコードに直接書くかを検討してください。

参照先にSPFレコードが無い状態が最も多く、過去に利用していたサービスを解約した後もincludeが残っていることが主な原因です。

1つのドメインが複数の状態を持つことがあるため、合計は、参照先だけに問題があった271件と一致しません。

参照をたどると自分へ戻る状態は、参照の連鎖をたどると元のドメインを再び参照する構成です。参照先にSPFレコードが2本以上ある状態は、SPFレコードが1本しか置けないという規定(RFC 7208 セクション4.5)に反するため、その参照先自体がpermerrorを返します。

この記事が扱うのは参照先のドメイン自体が持つ問題です。参照先のa・mx・existsが指す先が存在しない場合や、応答が空になる参照(void lookup)が続く場合は、別の状態として扱われます。RFC 7208 セクション4.6.4はvoid lookupの上限をSHOULDとして定めており、実装がその値を設定できるとしています。本サイトの診断は2件を超えた場合をこの状態として扱っており、直し方はSPF void lookupの推奨上限は2件で扱っています。参照回数がSPFレコード1本あたりの上限を超える場合は、SPFのDNS参照回数が10回を超える原因と直し方で扱っています。

ptrを使っている場合

ptr機構がレコードに含まれている場合、診断は「ptr 機構が使われています」と表示します。RFC 7208 セクション5.5は、この機構に"ptr" (do not use)という見出しを付け、本文で「この機構は公開すべきではない」としています(原文: "This mechanism SHOULD NOT be published.")。

非推奨の理由は、同セクションの注記に3つ書かれています。

This mechanism is slow, it is not as reliable as other mechanisms in cases of DNS errors, and it places a large burden on the .arpa name servers.

処理が遅いこと、DNSのエラー時に他の機構ほど信頼できないこと、.arpaのネームサーバーに負荷をかけることの3つです。同じ注記は、長年の運用経験から、より信頼できる代替の機構を使うべきだという結論に至ったとも述べています。

非推奨とされていても受信側には対応する義務があります。同じ注記は続けて次のように定めています。

It is, however, still in use as part of the SPF protocol, so compliant check_host() implementations MUST support it.

仕様に準拠したcheck_host()の実装は、ptr機構への対応が義務付けられています。それでも公開すべきでないとされているのは上の3つの性能と信頼性の問題によるものです。

置き換え先は、状況によって変わります。

• 送信元が事業者の管理するサービスの場合は、その事業者が公式に案内しているincludeを使います。事業者側でIPアドレスが変わってもincludeの参照先が追随できます
• 送信元のIPアドレスが固定されている場合は、ip4またはip6に置き換えます。IPアドレスが変わったときにSPFを直せる運用になっていることが条件です
• その送信元をもう使っていない場合は、ptrをレコードから削除するだけで済みます

ptrを一律にip4へ置き換えることは勧められません。送信元のIPアドレスが変わった場合、その送信元からのメールがSPFの認証に失敗するようになるためです。事業者が管理している送信元かどうか、まだ使っているかどうかで、置き換え先を分けてください。

実測では、ptr機構を使っていたのは15,498件中28件(0.18%)でした。

直したあとに確かめること

レコードを直したら、メール認証の診断で再診断します。「SPFレコードに問題があります」または「ptr 機構が使われています」の表示が出なくなったことを確認してください。あわせて、新しい値が意図どおりになっているかも確認してください。DNS上でレコードが直っていることと実際に送ったメールがSPFの認証を通ることは別です。

反映までの時間は、権威DNSへの反映と再帰リゾルバに残るキャッシュの2つに分けて考える必要があります。権威DNSへの反映自体は、多くの場合すぐに終わります。

本サイトの診断が再診断のときに問い合わせるのはGoogleとCloudflareが提供するDoH(DNS over HTTPS)のリゾルバです。再診断の結果に効くのはこのリゾルバのキャッシュで、実際にメールが届くかどうかに効くのは送信元や受信側のメールサーバーが使う再帰リゾルバのキャッシュです。この2つは別の場所にあります。どちらも、直前まで参照していた古いレコードをTTL(生存時間)の分だけ保持し続けることがあります。TTLは、そのレコードをキャッシュしてよい時間で、それを過ぎたら権威DNSサーバーに問い合わせ直すべきだとされている値です(RFC 1035 セクション3.2.1)。DNSの管理画面では、この値を秒単位の数値として設定します。

直す前のレコードに設定されているTTLの値から、古い値が残りうる時間の目安を計算できます。

これはあくまで目安です。権威DNS側での公開が遅れている場合、この時間には含まれません。また、権威サーバーが応答しない場合、期限を過ぎたキャッシュがそのまま使われることがあり、必ずこの時間で切り替わる保証はありません。再診断してもすぐに新しい結果が出ない場合は、この時間が経つのを待ってから確認してください。

直した結果、意図しない不具合が出た場合は、次の手順で戻してください。

1. 直す前に控えた値と直したあとの値の両方を手元に置きます
2. 不具合が出たら、今回変えた項だけを元に戻します。書式の誤りを直した部分は戻しません
3. 戻したあとも、キャッシュが切れるまで古い値が見えることがあります

自分のレコードの内容そのものを一から見直したい場合は、SPFレコードの内容を確認するツールも使えます。

調べ方と数値

Majestic Millionに掲載されている.jpドメイン19,535件を対象に、2026年8月22日にSPFレコードの書式を測定しました。母集団は被リンクの多い順に並んだ一覧からの抽出で、.jpドメイン全体からの無作為抽出ではなく、被リンクの多いドメインに偏ります。DNS問い合わせ75,794回、出典は/data/に置いたjp-spf-policy-2026-08-22.json、再現スクリプトはscripts/measure-spf-policy.mjsです。

SPFレコードが見つかったのは15,498件でした。このうち351件でこの表示が出ていて、自分のレコードに問題があったのは80件、参照先だけに問題があったのは271件でした。

同じ一覧を同じ日に測り直すと値が動きます。DNSの一時的な状態で数件変わるため、ここに載せたのは2026年8月22日の測定値です。

この記事を書く過程で、本サイトの診断がRFC 7208の定める書式の誤りをいくつか見逃していることが分かり、記事を公開する前に診断を直しました。IPv4アドレスの書き方が誤っているもの、CIDR(アドレス範囲)の指定が範囲外のもの、ip4やip6に値が書かれていないもの、allに値やCIDRを付けたもの、項を全角スペースで区切ったもの(RFC 7208 セクション4.6.1の区切りは半角の空白です)を新しく検出するようになりました。その結果、上の実測で20件が新たに見つかりました。内訳は、アドレスの書き方が誤っているもの7件、CIDRの指定が誤っているもの6件、値が書かれていないもの7件です。