SPF パーエラー: DNS ルックアップが多すぎる場合の修正方法

ブログ

SPF PermErrorが発生する原因と迅速な解決方法について学びましょう。メール認証を復元し、DNSルックアップの過剰発生を防ぐには、以下の手順に従ってください。

マイサム・アル・ラワティ

最終更新日:
8 読了時間：約8分
SPF パーエラー: DNS ルックアップが多すぎる場合の修正方法

主なポイント

  • SPF Permerrorは、ドメインのSPFレコードに根本的な問題があり、正確な評価ができないことを示しています。
  • 10回のDNSルックアップ制限を超えると、メールが拒否されたり、スパムとして分類されるなど、深刻な問題を引き起こす可能性があります。
  • SPFレコードの構文エラーはパーメラーにつながる可能性があり、慎重なフォーマットと検証が必要である。
  • オーバーサイズのSPFレコードは、確立された文字数制限を超える可能性があり、配信可能性の問題や潜在的なSPFエラーの原因となります。
  • SPFフラット化ツールを利用することで、レコードを最適化し、パーミスを防止し、メール認証を強化することができる。

送信者ポリシーフレームワーク（SPF）は、ドメイン所有者が自ドメイン名を使用してメッセージを送信することを許可するメールサーバーを定義できるメール認証方式です。メッセージが到着すると、受信メールサーバーはSPFをチェックし、承認済み送信元からのものかどうかを確認した上で、そのメッセージの処理方法を決定します。

SPF検証中、PermErrorはSPFレコード内の恒久的な問題を指し示し、それが適切に評価されるのを妨げます。これは通常、レコードがDNSルックアップ制限を超過した場合、またはSPFの処理方法を破綻させる構造的問題を含む場合に発生します。認証は時折失敗するのではなく、毎回失敗します。

そのような状況では、正当なメールでさえ受信サーバーに不審に映る可能性があります。メッセージが拒否されたり、スパムフォルダに振り分けられたり、DMARC違反を引き起こしたりするケースも発生します。これらはすべて、SPFレコード自体の信頼性のある評価が不可能であることに起因します。

SPF PermErrorを修正したい場合、その原因を理解することが最初のステップです。本記事では、SPF PermErrorの一般的な原因を分析し、メールが正しく認証されて宛先の受信箱に届くよう、実践的な解決方法を解説します。

SPF Permerrorとは？

SPF Permerrorとは、SPFレコードに永久的なエラーがあることです。

Permerrorは、SPFレコードの構文が正しくない、DNSルックアップ回数が多すぎる(10回を超える)、機構が無効であるなど、SPFレコードを評価できないような重大な問題がある場合に、受信メールサーバから返されます。通常のSPFの「失敗」（メールが認証を通過しなかったことを意味する）とは異なり、PermerrorはSPFレコード自体が壊れているか、設定が間違っていることを示します。これは配信に影響を与えるだけでなく、DMARCを弱体化させる可能性があります。 DMARCの保護を弱めることにもなります。

なぜSPFには10回のDNSルックアップ制限があるのですか？

SPFの10DNSルックアップ制限は制限的だと思うかもしれないが、これにはちゃんとした理由がある。

によると RFC 7208によると、この制限は主にセキュリティと性能のために存在する。具体的には、受信メールサーバを以下から保護するのに役立つ。 サービス拒否（DoS）攻撃から受信メールサーバーを保護するのに役立つ。

これが悪用される可能性がある：

脅威者は悪意のあるSPFレコードを作成し、複数のドメインやインクルードを参照することで、何百ものDNSルックアップを引き起こすかもしれない。これは、信頼できる企業のふりをしたなりすましドメインと結びついている可能性がある。受信サーバーがこのようなメールを検証しようとするたびに、これらのルックアップをすべて解決することを余儀なくされ、サーバーの動作が遅くなったり、クラッシュしたりすることさえある。

DNSルックアップの上限を10にすることで、SPFは役立つ：

  • 電子メール処理のパフォーマンスを維持する
  • リソース枯渇攻撃からの保護
  • より良いSPFレコード設計を奨励することにより、なりすまし対策の信頼性を向上させる。

SPFパーマの原因は？

SPF Permerrorは、過剰なDNSルックアップ、構文エラー、設定ミス、あるいは大きすぎるSPFエントリーなど、いくつかの問題によって引き起こされる可能性があります。最も一般的な原因について説明しよう：

1. SPF構文エラー

SPFレコードの不正な書式や無効な構文は、適切な評価を妨げ、Permerrorにつながる可能性がある。

一般的な原因

  • 文字の欠落や誤植（例：引用符 " やコロン 🙂）。
  • 無効な、あるいは不正なメカニズムや修飾子（include:spf.example.comの代わりにinclude_spf.example.comを使うなど）。
  • 不正なマクロ定義またはサポートされていないマクロ

例を挙げよう：

❌ v=spf1 include_spf.example.com -all → include にコロンがない。

❌ v=spf1 +mx a:mail.example.com -all → +修飾子は不要であり、しばしば誤用される。

2. DNS設定の問題

これらは、SPFレコードに関連するDNSの設定に問題があります。

よくある問題：

  • 存在しない、または設定ミスのドメインを指すSPFレコード
  • 参照ドメインにSPFレコードがない
  • 無効または非推奨のDNSレコードタイプ（TXTの代わりにSPFタイプレコードを使用するなど）

例

ドメイン参照にinclude:spf.partner.comが含まれていますが、spf.partner.comが存在しないか、TXTレコードがないため、SPF評価に失敗しています。

3. DNSルックアップが多すぎる

SPFは、RFC 7208のセクション4.6.4で定義されているように、レコード評価中に10回のDNSルックアップしか許可しない。これは悪用（サービス拒否攻撃など）を防ぎ、評価を軽量に保つためのセキュリティ対策である。

ルックアップとしてカウントされるもの

  • インクルード
  • a, mx, ptr
  • が存在する場合は、リダイレクト

ボイドルックアップ(DNSデータを返さないクエリー）にも制限があります。 2.

共通の原因：

多数のinclude:メカニズムやネストされたincludeを持つSPFレコードで、それらがまとめて10ルックアップの制限を超えるもの。

4. 通知書には以下が含まれます

サーキュラー・インクルードは、SPFレコードがループの中で互いを参照し合い、無限の解決サイクルを生み出すときに発生する。

例

  • ドメインA: v=spf1 include:domainB.com -all
  • ドメインB: v=spf1 include:domainA.com -all

この循環参照はSPF評価に失敗し、しばしばパーメラーを引き起こす。

5. 無効なメカニズムまたは修飾子

SPFレコードに認識されていない、または非推奨のメカニズムを使用すると、Permerrorになる可能性があります。

よくある間違い：

  • ip6ではなくip6vのようなタイプミス
  • all:、ptr:などのサポートされていないメカニズムが誤って使用された。
  • 不必要または不正確に+または?

例

❌ v=spf1 ptr:mail.example.com -all →推奨されないメカニズム
❌ v=spf1 ip4v:192.0.2.0/24 -all → 無効なメカニズム(ip4vはip4であるべき)

6. 過剰なSPFレコード

SPFレコードはサイズ制限に従わなければならない：

  • TXTレコードの各文字列は255文字以下でなければならない。
  • TXTレコードの長さの合計は512バイトを超えてはならない。
記録過多の原因：
  • IP、インクルード、メカニズムの数が多すぎる
  • 重複または不要な項目

例

v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.0/24 include:spf1.example.com include:spf2.example.com include:spf3.example.com include:spf4.example.com -allのようなレコードは、DNSの制限やサイズの制約を超える可能性があります。

DNSルックアップの過剰がメールを壊す仕組み

SPFレコードが10回以上のDNSルックアップを引き起こすと、メール配信に深刻な支障をきたします。以下はその例です：

  • 配送遅延:メールサーバーがSPFレコードを評価しようとして処理が遅くなり、配信遅延が発生することがあります。
  • タイムアウトエラー：ルックアップが多すぎると、SPF評価中にタイムアウトが発生し、メッセージがサイレントで失敗したり、ドロップされたりすることがある。
  • 拒否されたメール受信サーバーによっては、インフラを保護するために、SPF Permerrorの付いたメールを拒否したり、フラグを立てたりすることがあります。
  • DMARCが失敗する：DMARCポリシーがSPFアライメントに依存している場合、SPFチェックに失敗するとDMARCが破壊され、ドメインの信頼性が低下します。

SPFエラーを修正する方法（ステップバイステップ）

マニュアル修正

  • 未使用のインクルード機構を削除する

SPFレコードのinclude:をひとつひとつ確認し、まだ必要かどうかをチェックする。もう使っていないサービスにリンクされている場合は、削除してください。

  • include を IP アドレスに置き換える（静的の場合）

include:が静的IPまたは小さなIP範囲を指しているだけの場合は、DNSルックアップを避けるために、ip4:またはip6:メカニズムに直接置き換える。

  • PTRメカニズムを排除する

PTRはパフォーマンスと信頼性の問題からRFC7208では推奨されていない。ルックアップを減らし、エラーを避けるために、完全に削除する。

  • ドメインを含めて統合する

サービスによっては（電子メール・プラットフォームやプロバイダーなど）、複数のSPFエントリーを提供しているものもある。そのようなサービスでは、複数のSPFエントリーを提供する代わりに、1つのSPFエントリーを提供することが多いので、それらのドキュメントを確認してください。

  • 可能な場合はIPv4/IPv6を使用してください

送信サーバーのIPがわかっている場合は、ルックアップを消費するMXやAのようなメカニズムに頼るのではなく、ip4:やip6:を使って直接追加する。

ベストプラクティス：自動SPF平坦化ツールを使用する

自動SPFフラット化は、複数の "include "文やその他のDNSベースのルックアップを、単純化されたIPアドレスのリストに動的に変換するプロセスである。このアプローチにより、SPFチェック中のDNSルックアップの回数を減らすことができます。

手動によるSPFフラット化は手軽な解決策のように思えるかもしれませんが、重大なリスクを伴います。メールサービスプロバイダーが送信IPを変更した場合、手動で更新しない限りSPFレコードにその変更が反映されません。そのため、コンプライアンスを維持するには継続的な監視と手動編集が必要です。フラット化されたレコード内の古いIPはSPFの失敗を引き起こし、メールの到達率やDMARC整合性に影響を及ぼす可能性があります。

PowerSPFは、ホスト型のSPFフラット化・最適化ツールで、プロセス全体を自動化するため、ルックアップの制限やIPの変更を心配する必要がありません。

  • ベンダーがIPを変更した際の自動更新: SPFレコードをリアルタイムで更新します。
  • ワンタイム設定:一度設定すれば後は何もする必要がありません。継続的なメンテナンスは不要です。
  • ルックアップ回数は低水準を維持: SPFレコードは簡潔な状態を維持し、RFCガイドラインと制限に準拠します。

SPF失敗とSPFパーマネントエラーの主な違い

SPF失敗SPF パーマエラー
その意味SPFレコードが見つかり、評価されたが、送信者は認証されていない。エラーまたは設定ミスにより、SPFレコードを評価できませんでした。
原因送信者IPがドメインのSPFレコードに記載されていないSPF構文が壊れている、DNSルックアップが多すぎる、またはその他の重大な問題
問題の種類一時的な問題（メールが許可されていない）パーマネントエラー（SPFレコードが無効または読めない）
インパクトメールが拒否されたり、スパムとしてマークされる可能性があります。SPFの検証を行わないと、メールが拒否されたり、スルーされたりすることがある。
DMARCアライメントSPFが整合していない場合、DMARC失敗を引き起こす可能性がありますDMARCを破壊する可能性がある。
修正送信者リストに目を通し、正当な送信者を承認する。機能を回復するにはSPFレコードを修正する必要がある。

DNSループの過剰発生やその他のSPFエラーを防止する

SPFエラーの防止には継続的な注意が必要です。特にメールインフラが変化し、新しいサードパーティサービスが追加されるにつれて重要です。いくつかの継続的な対策により、SPFレコードを有効な状態に保ち、プロトコルの制限範囲内に安全に維持できます（設定が進化し続ける場合でも）。

メールサービスプロバイダーの設定を最新の状態に保つことで、許可された送信元がSPFレコードと整合性を保ち続けます。プロバイダーが送信インフラを更新したり、ドメインを含めるための変更を推奨したりした場合、それらの更新を反映しないままにすると、認証失敗の原因となります。

ベンダーの追加・削除・変更時には、SPF設定の確認が同様に重要です。マーケティングプラットフォーム、課金システム、サポートツール、自動化サービスは、しばしばお客様のドメインを代行してメールを送信します。各変更時には、SPFレコードがすべてのアクティブな送信者を反映していることを確認するチェックを必ず実施してください。

定期的な監査スケジュールを維持することで、レコードが複雑化しすぎるのを防げます。定期的なレビューにより、未使用のインクルード文の削除、DNSルックアップの追跡、エラー発生前にレコードがSPFルックアップ制限内に収まることの確認が容易になります。

ドメインに代わってメールを送信するすべてのサービスを文書化することで、将来の更新に向けた明確な参照ポイントが提供されます。承認済み送信者の簡単な一覧を作成することで、推測作業が減り、トラブルシューティングが迅速化され、長期的にクリーンで信頼性の高いSPF設定を維持するのに役立ちます。

結論

SPFエラーは、配信可能性、ドメインの健全性、およびセキュリティに影響を与える可能性があります。冗長なメカニズムを削除する、メカニズムをIP範囲に置き換える、配信可能性を監視するといった簡単な取り組みで、大きな効果が期待できます。

手間を省き時間を節約したい組織には、PowerSPFのようなホスト型ソリューションがあります。その仕組みや認証態勢への変革効果についてご興味をお持ちですか？今すぐ弊社の専門家による無料デモをご予約ください！

よくある質問 (FAQ)

必要に応じてSPFのルックアップ回数は10回を超えることは可能ですか？

いいえ、SPFはRFC7208で定義されているように、評価中のDNSルックアップは厳密に10回に制限されています。この制限を超えるとパーエラーとなり、メールが拒否されたり、スパムと判定される可能性があります。

複数のSPFレコードを持つことはできますか？

いいえ。ドメインごとに、そのドメインに対するすべての送信元を認証するSPFレコードを1つだけ設定する必要があります。複数のレコードがあると、すべてのレコードが無効になり、エラーの原因となります。

Permerrorを修正する最も安全な方法は？

Permerrorを修正する最も安全な方法は、PowerSPFのようなホスト型SPFソリューションを使ってSPFを動的に最適化することである。  

ダイナミックIPのフラット化は安全か？

プロバイダーが動的IPを使用している場合、手動でのIP平坦化はすぐに古くなり、SPFの失敗を引き起こす可能性があります。動的IPや頻繁に変更されるIPの場合、最も安全な選択肢は、自動的にIPを取得・更新するホスティングソリューションを利用することです。 

「素晴らしい製品とチーム

ハコブ・シャラブハニャン（ハックテックCEO）

"素晴らしい会社、製品、MSPベンダー"

ビル・バーネット（クリアビューIT創設者兼社長）

前へ次のページ

最新記事 by Maitham Al Lawati(全て見る)
最終更新日:
SPF、DKIM、DMARC：その概要と重要性spf dkim dmarcDNS PTRレコードとはPTRレコードとは何か、そしてなぜ重要なのか