SPFのPermErrorは、SPFレコードが10回のDNSルックアップを超えて発生することを意味します（RFC 7208の上限）。include・a・mx・ptr・exists・redirect はそれぞれ数え、各 include はその中のルックアップも加算します。未使用のincludeを削除し、一部を ip4:/ip6: アドレスに置き換えるか、レコードをフラット化して修正します。
受信側はSPFをリアルタイムで評価するため、仕様は乱用と配信遅延を防ぐためDNS処理を10回に制限しています。超えると結果は PermError となり、失敗として扱われ、正規メールが迷惑メール行きになったり、DMARCで拒否されたりします。
10回の上限に数えるもの：include・a・mx・ptr・exists・redirect、そして再帰的に各 include 内のすべて。数えないもの：ip4: と ip6: のメカニズム、および all メカニズム。この非対称性が解決の鍵です。
1. 使っていないものを削除。 SPFに残った古いESPやツールが最も多い原因です。2. 統合。 より軽いincludeを公開するプロバイダーもあります。3. includeをIPに置換。 安定したIP範囲を公開するサービスなら、include:service.com をその ip4: ブロックに置き換えます。ルックアップはゼロです。4. フラット化は最後の手段で、監視付きのみ。IPを変えるプロバイダーはフラット化レコードを静かに壊します。
SPF レコードが 1 つだけ存在することを確認し、そのメカニズムを確認します。
$ dig TXT yourdomain.com +short上記の SPF チェッカーは、すべてのインクルードを展開し、実際のルックアップ数と最もコストが高いインクルードをレポートします。
今すぐSPFレコードを確認
無料のSPFチェッカーを開く →いいえ。ip4: と ip6: はDNSルックアップがゼロです。だからincludeをIP範囲に置き換えるのは有効な解決策です。
機能しますが脆弱です。プロバイダーの現在のIPをレコードに固定するため、IPが変わるとメールが失敗します。フラット化するなら、レコードを自動更新するサービスを使い、監視してください。
はい。複数のSPFレコードを公開することは別のPermErrorの原因です。ドメインは正確に1つだけ持つべきです。
