SPFレコードを正しく書いたはずなのに、送信元の認証結果が「permerror」になることがあります。多くの場合、原因はレコードの構文ではなく、参照先のDNSルックアップ回数が上限を超えていることです。

10回という上限の意味

SPFの仕様では、include・a・mx・ptr・existsなど、追加のDNS参照が発生する仕組みの合計回数が10回までと決まっています。11回目以降は評価そのものが失敗（permerror）となり、SPFが正しく機能しません。この上限は自社の記述ミスがなくても、外部サービスを追加していくうちに超えてしまうことがあります。

超えやすいケース

  • メール配信サービス、CRM、フォーム通知、請求システムなど、複数のサービスをすべてincludeで追加している
  • 追加したサービスをやめたあとも、SPFレコードからincludeを削除し忘れている
  • 一つのinclude先が、さらに別のincludeを複数参照している（ネストして回数が積み重なる）

確認と対処の順番

  1. 現在のSPFレコードに含まれるincludeを、実際に使っているサービスと突き合わせる
  2. 使っていないサービスのincludeを削除する
  3. それでも上限に近い場合は、レコードの「フラット化」（参照先を実際のIPアドレスに置き換える）を検討する

フラット化は回数を減らせますが、参照先サービスがIPアドレスを変更した際に自動で追従しなくなるという別のリスクを持ちます。変更後は、送信テストとDMARCレポートで実際にSPFが正しく評価されているかを確認してください。

認証設定全体の役割を先に整理したい場合は、SPF・DKIM・DMARCの基本を参照してください。