SPF が PermError になる5つの原因
目次
この記事でわかること
- SPF の評価結果が
PermErrorになる典型的な 5 つの原因 - 各原因の見分け方（検出方法）と直し方（修復手順）
- PermError を放置すると DMARC まで失敗し、メールが届かなくなるビジネス上のリスク
PermError は「SPF を設定していない」のと同じくらい危険
SPF（エスピーエフ：送信元サーバーが正当かを受信側が確認する仕組み）のチェック結果には、pass・fail・softfail・neutral・none・temperror・permerror があります。このうち permerror（パーマネントエラー）は、RFC 7208 の定義で「公開されたレコードを正しく解釈できなかった。解決には DNS 管理者の対応が確実に必要な状態」とされています。
ここで実務上やっかいなのは、PermError になると SPF は pass（認証成功）になりません。そして DMARC（ディーマーク：SPF と DKIM の結果をまとめて最終判定する仕組み）は、SPF が pass しているかどうかを見て判定します。SPF が PermError で pass しない場合、DKIM 側でも認証が通っていなければ、DMARC の判定は失敗に倒れます。
つまり PermError を放置すると、SPF を一切設定していない状態と実質的に変わらず、さらに DMARC まで道連れで失敗します。DMARC を p=quarantine や p=reject で運用していれば、正規のメールが迷惑メール扱いされたり、受信拒否されたりする実害につながります。これは取引先への請求書や問い合わせ返信が届かないという、事業に直結する問題です。
以下、PermError を引き起こす代表的な 5 つの原因と、その検出・修復手順を整理します。
PermError を引き起こす5つの原因
原因1: DNS lookup が10個を超えた
SPF の評価中に DNS 参照を伴うメカニズムは合計 10 個までと RFC 7208 が定めています。include・a・mx・ptr・exists の各メカニズムと redirect 修飾子がこの 10 個に数えられます（ip4・ip6・all は DNS 参照しないので数えません）。この上限を超えると、受信側は PermError を返さなければなりません。
これは最も頻度の高い原因です。複数の SaaS を include で連ねると簡単に 10 個を超えます。詳しい仕組みと回避策はSPF の DNS lookup 10 個上限を解説とSPF include 上限を超えたときの直し方で扱っていますので、ここでは深入りせずそちらをご参照ください。
原因2: SPF レコードが複数存在する
1 つのドメインに v=spf1 で始まる TXT レコードを 2 つ以上公開すると、RFC 7208 は「結果のレコードが複数含まれる場合、PermError になる」と定めています。
ありがちなのは、メール配信サービスを追加導入したときに既存レコードを編集せず、新しい v=spf1 の行を別に追加してしまうケースです。SPF は 1 ドメインにつき 1 行が原則です。複数のサービスを使う場合は、1 行の中に include: を並べて統合します。
検出: dig txt <ドメイン> +short で v=spf1 から始まる行が 2 つ以上ないか確認します。修復: 内容を 1 行に統合し、余分な TXT レコードを削除します。
原因3: 構文エラー・タイポがある
RFC 7208 は「レコードの構文がまず検証され、どこかに構文エラーがあれば check_host() は即座に PermError を返す」と定めています。メカニズムの評価以前に弾かれるため、1 文字のタイポでも SPF 全体が機能しなくなります。
よくある例は次のとおりです。
include:のコロンをinclude=と書いてしまうip4:をip:やipv4:と書く- 全角スペースや余分な引用符が混入する
- メカニズムを区切る半角スペースが抜けて 1 語に連結する
検出: 表記を 1 文字ずつ目視するか、後述の検証ツールで構文チェックします。修復: 正しい表記に直します。コピー&ペースト時の不可視文字混入にも注意します。
原因4: include 先に有効な SPF がない（NXDOMAIN）
include:example.net のように指定した参照先に、有効な SPF レコードが存在しない場合も PermError になります。RFC 7208 の結果表では、参照先の評価結果が none（SPF レコードなし）のとき、include メカニズムは PermError を返すと定められています。
加えて、参照先が存在しない（NXDOMAIN）といった「空振りの DNS 参照（void lookup）」が一定数を超えると PermError になります（RFC 7208 は void lookup を 2 回までに制限すべきとしています）。配信サービスの解約後に include を消し忘れる、ドメイン名をタイポする、といったケースで起こります。
検出: 各 include 先について dig txt <参照先> を実行し、v=spf1 が返ってくるか確認します。修復: 使っていない include を削除し、参照先の表記を正します。
原因5: 非推奨メカニズムや不正なマクロ
ptr メカニズムは RFC 7208 で「公開すべきではない（SHOULD NOT be published）」とされています。ptr 自体は構文として有効なので直接 PermError を起こすわけではありませんが、信頼性が低い上に DNS lookup と void lookup の両方を消費するため、原因 1 や原因 4 の引き金になりやすいメカニズムです。
一方で、綴りを間違えたメカニズム名や、仕様に沿わない不正なマクロ（%{...} の記法ミス）は、原因 3 と同じく構文エラーとして即 PermError になります。ptr は使わず ip4・ip6・include で表現し、マクロは安易に手書きしないのが安全です。
まず実施したい検出と切り分けの順番
PermError が疑われるときは、次の順で切り分けると効率的です。
v=spf1の行が 1 つだけかを確認する（原因 2 の除外）- DNS 参照メカニズムの数を数える（原因 1 の確認。
include・a・mx・ptr・exists・redirectの合計）。SPF ルックアップ数カウンタを使うと、include の入れ子まで再帰的にたどった実際の参照回数をその場で確認できます - 構文を 1 文字ずつ点検する（原因 3 の確認）
- 各
include先が有効な SPF を返すかを確認する（原因 4 の確認） ptrや不正なマクロが残っていないかを確認する（原因 5 の確認）
SPF・DKIM・DMARC をまとめて確認する具体的な手順はSPF / DKIM / DMARC の確認方法に詳しくまとめています。確認結果の数値や具体的なエラーコードの解釈に迷う場合は、公式仕様（RFC 7208）をご確認ください。
修復後に必ず確認すること
レコードを直したら、変更が反映されるまで時間差があります。DNS の TTL（反映待ち時間）が切れるまでは古い結果が返ることがあるため、修正直後の判定だけで安心しないことが大切です。
- 修正後、しばらく時間を置いてから再度判定する
- 自社から自社以外（Gmail など）へテスト送信し、受信メールの
Authentication-Resultsヘッダーで SPF がpassに変わったか確認する - DMARC レポート（rua）が届いている場合は、SPF の認証結果が改善しているか数日かけて確認する
SPF を直しても DMARC の判定がすぐに改善しない場合は、DKIM 側やアラインメントの問題が別にある可能性があります。DMARC ポリシーの段階的な運用についてはDMARC ポリシーの強化手順も参考になります。
よくある質問
PermError と Fail は何が違いますか
fail は「このメールは正規の送信元ではない」と判定された結果です。permerror は「SPF レコード自体が壊れていて評価できない」状態で、正規・非正規の判定以前の問題です。PermError は SPF が機能していないのと同じため、設定の修正が必要です。なお fail（-all）と softfail（~all）の扱いの違いはSPF Fail と SoftFail の違い・対処早見表で詳しく整理しています。
include を減らせない場合はどうすればいいですか
include の数を増やさずに IP を直接展開する「SPF フラット化」という手法があります。詳しくはSPF の DNS lookup 10 個上限を解説をご参照ください。ただしフラット化は配信サービス側の IP 変更に追従できなくなるリスクがあるため、運用方針とあわせて検討してください。
ツールで自動的に検出できますか
はい。SPF レコードの構文・参照数・複数レコードの有無は、ツールで自動チェックできます。手作業の見落としを防げるため、まずは自動診断で全体像を把握するのがおすすめです。
まずは自社の SPF が PermError になっていないか確認しませんか
自社ドメインの SPF が正しく pass する状態か、DNS lookup 数や複数レコードの問題がないかは、ドメイン番人の無料診断で数秒で確認できます。PermError の原因切り分けや SPF レコードの統合に迷う場合は、お問い合わせフォームから状況をお知らせください。専門家が一緒に整理いたします。