SPF 10 DNS 照会制限の解説（およびその解決方法）

SPFレコードの制限を理解するには、まず「DNSルックアップ10回」という上限から把握する必要があります。SPFレコードによって10回を超えるDNSルックアップが発生した場合、受信メールサーバーは「SPF PermError: too many DNS lookups」というエラーを返し、DMARCはこれをハードフェイルとして扱います。その結果、正当なメールが警告なしに拒否されたり、スパムフォルダに振り分けられたりすることになります。

この制限はRFC 7208に基づくもので、SPF評価において1回のチェックあたり10件のDNSクエリに上限を設けています。問題は、多くのドメインがこの制限を超えていることに気づいていないことであり、その原因は、ネストされたインクルードや古いサービスにあることがよくあります。

このガイドでは、制限の対象となる要素、SPFレコードがなぜ何の前触れもなく機能しなくなるのか、そしてルックアップの失敗を恒久的に修正・防止する方法について解説します。

SPFチェッカー：無料のSPFチェッカーで現在の照会回数を確認しましょう

SPF 10 DNS ルックアップ制限とは何ですか？

RFC 7208で定義されているSPF仕様では、各SPFチェックにおいてDNSクエリを実行するメカニズムは最大10個までと制限されています。

簡単に言えば、受信メールサーバーがSPFレコードを検証するたびに、追加のDNSクエリを実行する必要が生じ、その都度この制限にカウントされます。

これらのクエリは、次のような仕組みによってトリガーされます：

• インクルード
• a
• エムオーエス
• 伝令者
• ある
• リダイレクト

11回目の照会が必要になると、SPF評価は直ちに停止し、以下を返します：

SPF PermError: DNS 照会が多すぎます

DNSの照会が行われるたびに、受信サーバーのCPU、帯域幅、メモリなどのリソースが消費されます。制限を設けない場合、悪意のある攻撃者が深くネストされたインクルードを含むSPFレコードを作成し、サーバーに数百回ものDNSクエリを強制的に実行させる可能性があります。

これにより、SPFの検証が事実上、サービス拒否（DoS）攻撃の手段となってしまいます。

SPF仕様では、10件という厳格な検索制限を設けることで、以下の点が保証されます：

• メールの処理にかかる時間の目安
• DNSの悪用に対する対策
• メールシステム間で安定したパフォーマンス 

SPF 10のDNS照会制限には何がカウントされますか？ 

SPFレコードに含まれるすべての仕組みがDNSルックアップを引き起こすわけではありません。何がルックアップの対象となり、何が対象とならないかを把握することが、ルックアップ回数を減らす最も手っ取り早い方法です。

有効なSPFメカニズムと無効なSPFメカニズム

これが理由です 以下を含める： および mx メカニズムが、特にネストされたルックアップが含まれている場合、SPF失敗の最大の原因となっているのです。

検索処理の多い仕組みを直接的なものに置き換える ip4: または ip6: エントリ（可能な場合）に置き換えることは、制限内に収めるための最も効果的な方法の一つです。

よくあるケース：複数のクライアントのSPFレコードを管理するMSP

クライアントが複数のメールプラットフォームを利用している場合、マネージドサービスプロバイダー（MSP）はSPFの制限に頭を悩ませることがよくあります。一般的なMSPのクライアントは、Office 365、Mailchimp、Salesforce、HubSpotなどを利用していることが多く、それぞれに「include」ステートメントが必要となるため、10件というルックアップ制限にすぐに達してしまう可能性があります。

SPFの制限に達してしまう理由（ネストされたインクルード）

記録には3つや4つしか記載されていないかもしれません 例： 行しか表示されていなくても、制限に達している可能性があります。その理由は以下の通りです。

v=spf1 include:sendgrid.net include:_spf.google.com include:salesforce.com ~all

一見すると、これは3回のDNS検索のように見えますが、SPFの評価はそこで終わりではありません。各「include」を再帰的に追跡していきます。

実際には、次のようなことが起こります：

1. include:sendgrid.net → SendGridのSPFレコードには、さらに2つの include: メカニズム → 合計3つのルックアップ
2. include:_spf.google.com → GoogleのSPFレコードには、さらに3つのメカニズムが含まれています → 合計4つのルックアップ
3. include:salesforce.com → SalesforceのSPFレコードには、さらに3つの仕組みが含まれています → 合計4つのルックアップ

合計：11回のDNS検索

すべての 追加する 追加するたびに、単なる1回の検索にとどまりません。1回の検索に加え、そのサードパーティの SPFレコード が必要とする数だけ追加されます。これが、特に複数のメールサービスプロバイダーを利用している場合、制限に到達する速度がほとんどのドメイン所有者の予想よりもはるかに速くなる理由です。

SPF 10のルックアップ制限が存在する理由

DNS検索の10件という制限は、特に複数のメールサービスプロバイダーを利用している組織にとっては厳しいものに思えるかもしれませんが、これには重要なセキュリティおよびパフォーマンス上の理由があり、管理者やセキュリティチームはこれを理解しておく必要があります。

概要： ルックアップ制限は、DNSインフラを悪用から保護しつつ、メールの処理を遅滞なく行うことを可能にしますが、SPFレコードの慎重な管理が必要です。

サービス拒否攻撃の防止

DNSへの不当な負荷を回避し、サービス拒否（DoS）攻撃を防ぐため、追加のルックアップは10回までに制限されています。

この制限がなければ、攻撃者は何百ものネストされたインクルードを含むSPFレコードを作成し、そのドメインからのメールを処理するすべての受信メールサーバーに、膨大な数のDNSクエリを実行させることが可能になります。 これにより、DNSサーバーが処理能力を超え、インターネット全体のパフォーマンスが低下する恐れがあります。

メール処理の適時性を確保する

SPFチェック中のDNSルックアップは、その都度メール配信プロセスに遅延をもたらします。 SPFレコードのルックアップが無制限に許可された場合、SPF検証に必要な時間が大幅に増加し、DNSクエリのタイムアウトや一時的なDNSサーバーの障害を引き起こす可能性があります。

10件の検索制限により、SPFチェックが迅速かつ確実に完了し、メール配信におけるボトルネックの発生を防ぎます。

DNSの安定性の維持

DNSインフラは共有リソースです。 SPF認証中に無制限のルックアップを許可すると、特に送信量の多い送信者において、再帰的リゾルバや権威ネームサーバーに過度の負荷がかかることになります。

この制限は、SPF関連のクエリ量を管理可能な範囲に保つことで、より広範なDNSエコシステムを保護します。

SPFルックアップ制限を超えた場合の影響

SPFルックアップの制限を超過すると、単なる軽い警告で済むわけではありません。 これは重大なエラーを引き起こし、メールが受信者の受信トレイに届くかどうかに直接影響を及ぼす可能性があります。

SPF評価はルックアップ11で停止します

SPFは左から右へと評価されます。受信サーバーがSPFレコード内の11番目のDNSクエリメカニズムまたは修飾子に遭遇すると、直ちにレコードの処理を中止し、以下を返します：

SPF PermError: DNS 照会が多すぎます

これは一時的なSPF評価エラーではなく、ソフトフェイルや中立な結果でもありません。受信側は、認証を完了できないため、このSPFレコードを無効なものとして扱います。

DMARCは、SPFのPermErrorをSPFの失敗として扱います

SPFがPermErrorを返すと、DMARCはそれをSPFの失敗と見なします。DMARCを通過させるためにSPFのアラインメントが必要だった場合、そのメッセージはDMARC認証に完全に失敗する可能性があります。

その結果は、以下の要因によって決まります：

• あなたの DMARCポリシー (p=none、 隔離、または 拒否)
• 受信サーバーのフィルタリングルール
• DKIMの検証が成功し、整合性が取れているかどうか

メールは拒否されたり、隔離されたり、スパムフォルダに振り分けられたりする可能性があります

PermError により SPF が失敗した場合：

• プロバイダーによっては、そのメールを即座に拒否する場合があります
• 他のユーザーは、それをスパムフォルダや隔離フォルダに振り分けるかもしれません
• セキュリティフィルターによって、そのメッセージが不審または未認証としてフラグが立てられる可能性があります

これは、次のようなより厳格なDMARCポリシーが適用される場合、特に深刻な影響を及ぼします。 p=quarantine や p=rejectといった厳格なDMARCポリシーが適用される場合、特に深刻な影響を及ぼします。

この点において、Microsoft環境は特に影響を受けやすいと言えます。OutlookおよびExchange Onlineは認証チェックを厳格に実施しているため、SPFのPermErrorsは、Office 365の受信者へメールを送信する組織の配信率に重大な影響を及ぼす可能性があります。

SPFは左から右へと評価されるため、一部の送信サービスはルックアップ制限に達する前に認証に成功する一方で、チェーンの後半にある他のサービスは失敗する場合があります。

つまり、

• 一部のメールは正常に配信されているようです
• その他は予期せず認証に失敗する
• DMARCレポートやSPF分析ツールがなければ、この問題の診断は困難になります

そのため、SPF照会制限の問題は、配信率が低下したり、DMARCレポートで断続的な失敗が判明したりするまで、しばしば見過ごされがちです。

SPF PermError のその他の原因

DNS 照会の制限数（10回）を超過することが、SPF PermError の最も一般的な原因ですが、それだけが原因ではありません。PermError は、次のような場合にも発生することがあります：

• 複数 SPFレコード が存在します
• SPFレコードに構文エラーがあります
• 非推奨またはサポート対象外の仕組みが使用されています
• 円形 以下を含みます: ステートメントが無限ループを引き起こす

これらの問題のいずれも、SPF認証を失敗させ、メールの配信率に悪影響を及ぼす可能性があります。

DMARCポリシーを確認し、リスクの程度を把握するには、 DMARCレコードチェッカー

これらの問題のいずれも、 SPFの失敗 やメールの未配信につながる可能性があるため、SPF設定全体を定期的に検証することが重要です。

SPFの空のレコード検索制限：遭遇する可能性のあるもう一つの制約

多くのSPFガイドでは、DNSルックアップの制限が10回までとされていますが、RFC 7208にはもう1つ制約があり、ルックアップ回数が10回を大幅に下回っていても、同じエラーが発生する可能性があります。それが「無効なルックアップの制限」です。

「ボイドルックアップ」とは、有用な結果を返さないDNSクエリのことです。

これは、ルックアップの結果が次のように返された場合に発生します：

• NXDOMAIN（ドメインが存在しません）
• レコードがない場合のNOERROR（空のレスポンス）

RFC 7208 では、SPF の評価において、1回のチェックにつき無効なルックアップは最大2回までと制限されています。

3回目の無効な検索が発生した場合、受信サーバーは以下を返します：

SPF パーマネントエラー

これはつまり、

レコードのDNSルックアップ回数が10回未満であっても、SPF PermErrorが発生する可能性があります。

だからこそ、ボイド・ルックアップは危険なのです。なぜなら、その存在を検知するのが難しく、SPF監査の際に見落とされがちだからです。

無効な検索結果は、通常、古くなったSPFエントリや設定ミスが原因で発生します：

• 以下を含める： SPFレコードが削除されたドメインを指している
• a または mx 有効なDNSレコードを持たないドメインを参照するメカニズム
• サポート終了または提供終了したメールサービスプロバイダー
• SPFメカニズム内のドメイン名におけるタイプミス

たった1つの古い#include文であっても、SPFチェックのたびに、何の前触れもなく無効な検索が発生する可能性があります。

10件の検索制限と無効な検索制限の違いは以下の通りです：

どちらの場合も結果は同じで、SPF PermError となります。

ルックアップの失敗を防ぐには：

• SPFレコードを定期的に監査し、古くなった には以下を含める： ステートメント
• 使用しなくなったサービスを削除する
• 参照されているすべてのドメインが有効なDNSレコードを返すことを確認する
• [SPFチェッカー]を使用してください SPFチェッカー を使用してください。これは、総ルックアップ数だけでなく、無効なルックアップを検出するものです

PowerDMARCのSPFチェッカーは、総ルックアップ数と無効なルックアップの両方を特定するため、配信率に影響が出る前にこれらの隠れたエラーを発見することができます。

SPFレコードが制限を超えているか確認する方法

SPFレコードがDNSルックアップの制限数（10回）を超えているかどうかを確認することは、配信に関する問題を解決するための第一歩です。 SPFレコードのチェックを実行し、現在のルックアップ回数を確認するには、いくつかの方法があります。

要約： 診断ツールと手動による検証を用いた定期的なSPFモニタリングは、メール配信に影響が出る前にルックアップ制限の違反を防ぐのに役立ちます。

SPF診断ツールを使用する

SPF診断ツールを使用することで、SPFレコードが有効であり、正しく機能しているかを確認できます。 これらのツールはSPFレコードを解析し、ネストされたインクルードを含むすべてのDNSルックアップをカウントし、エラーや警告があればフラグを立てます。

PowerDMARCの無料SPFレコードチェッカーを使えば、総照会数を即座に確認したり、どのメカニズムが最も多くのクエリを消費しているかを特定したり、配信トラブルを引き起こす前に設定ミスを発見したりすることができます。

SPFレコードを手動でトレースする

SPFレコードを自身で確認したい場合は、レコード内の各メカニズムを順に追ってDNSルックアップを手動で数えることができます。

まず、ドメインのSPF TXTレコードを確認し、「include」、「a」、「mx」、「ptr」、「redirect」、「exists」の各メカニズムをすべて数えます。 次に、各「include」について、参照されているドメインのSPFレコードを検索し、その検索を引き起こしたメカニズムも同様に数えてください。

ネストされたインクルードはすぐに累積するため、複数のメールサービスプロバイダーを利用する組織では、気づかないうちに制限を超過することが多い。

SPF検証の経時的な監視

SPFレコードは固定されたものではありません。 メールサービスプロバイダーの追加や削除、ホスティング環境の変更、メールインフラの更新を行うと、SPFレコードも変更されます。変更後は、10件のルックアップ制限に準拠していることを確認するため、SPFレコードの検証を行うことをお勧めします。

PowerDMARCのプラットフォームを通じて継続的な監視を設定することで、SPF設定を常時可視化し、変更によりレコードが制限値を超えた場合に通知を受け取れます。

SPFレコードの修正と最適化方法

SPFレコードが10件のDNSルックアップ制限を超えている、またはその限界に近づいている場合、メール認証のカバー範囲を損なうことなくルックアップ数を削減するための実用的な対策がいくつかあります。

概要： SPFの最適化には、使用されていないサービスの削除、検索負荷の高いメカニズムを直接IPアドレスに置き換えること、および複雑なインフラストラクチャに対する自動管理の実装が含まれます。

現在のSPFレコードを監査し、ルックアップ回数を計測する

まずは 信頼性の高いSPFチェッカーを使用して から始めましょう。これにより、ネストされたインクルードを含めた総DNSルックアップ数を把握できるほか、無効なルックアップや設定ミスなどの問題を特定できます。また、どのメカニズムが最も多くのクエリを消費しているかも明らかになります。

手動でのカウントも可能ですが、包含されたドメイン内での再帰により不正確になることが多いため、可能な限りツールを使用してください。

使用されていない、または不要なサービスを削除する

最も単純な最適化は、SPFレコードを監査し、使用しなくなったサービスを参照するメカニズムをすべて削除することです。

時間の経過とともに、組織はSPFレコードにメールサービスプロバイダー、マーケティングプラットフォーム、サードパーティツールを追加しますが、それらが使用されなくなった際に削除することを忘れてしまいます。

必要なルックアップの数を減らすため、組織はSPFレコードから未使用のサービスを削除すべきです。これはまた、初期設定時に追加されたものの現在では目的を果たしていないデフォルトのSPF値を削除することも意味します。

避ける ptr ptr mx の使用を最小限に抑える

The ptr メカニズムは、SPF標準では強く推奨されません。これは送信元IPごとに逆DNSルックアップを実行するため、処理が遅く、信頼性が低く、ルックアップ負荷が高くなります。もし使用されている場合は、これを削除し、IPアドレスを直接指定するように置き換えてください。

その MX メカニズムもルックアップ回数を増加させる可能性があります。まずMXレコードを解決し、その後、関連する各メールサーバーに対して追加のルックアップを実行します。インフラが安定している場合は、 mx を ip4: または ip6: エントリを追加して、効率を向上させます。

ルックアップを多用するメカニズムをip4またはip6に置き換える

「include」、「a」、「mx」の各メカニズムでは、少なくとも1回のDNSルックアップが必要です。 可能な場合は、これらを、許可されたIPアドレスを直接指定するip4またはip6メカニズムに置き換えてください。SPFレコードでip4またはip6メカニズムを使用すれば、追加のルックアップは不要となり、ルックアップ制限への準拠を維持するのに役立ちます。

例えば、メールサービスプロバイダーのSPFレコードが既知の静的IPアドレスのセットに解決される場合、複数のDNSルックアップを引き起こす「include」を使用する代わりに、それらのIPを直接リストすることができます。

SPFフラット化を使用する（一時的な対処法）

SPFのフラット化により、 以下を含みます： メカニズムをその解決済みIPアドレスに置き換え、DNSルックアップをほぼゼロに削減します。レコードを迅速に制限値内に戻すには、自動SPFフラット化を使用し、公開前に更新されたレコードを検証してください。

ただし、これにはトレードオフが伴います。プロバイダーがIPアドレスを変更した際、レコードが更新されていないと、正当なメールでもSPF検証に失敗する可能性があります。手動でのフラット化には、継続的な監視とメンテナンスが必要です。

ホスト型SPFまたはSPFマクロを使用する（恒久的な解決策）

長期的な安定性を確保するには、PowerDMARCのようなホスト型SPFソリューションの導入をご検討ください。これらのシステムは、マクロや外部解決機能を用いてSPFレコードを動的に管理し、ルックアップ制限内に自動的に収まるよう保証します。

このアプローチにより、以下の点が解消されます：

• ベンダーのIPアドレスが変更された際の手動更新
• 古いフラット化されたレコードに伴うリスク
• 継続的な保守コスト

特に、複数のサードパーティ製サービスを利用している組織や、複雑なメールインフラを管理している組織にとって、その価値は大きい。

ポインタ機構を避ける

ptr メカニズムの使用は、必要なルックアップ回数が増加し、Permerror の問題を引き起こす可能性があるため、強く推奨されません。

ptrメカニズムは、接続してくるすべてのIPアドレスに対して逆DNSルックアップを実行するため、処理が遅く、信頼性も低い。 SPF仕様書自体も、その使用を推奨していません。現在、SPFレコードにptrメカニズムが含まれている場合は、それを削除し、IPアドレスの直接参照に置き換えてください。

mxメカニズムの使用を最小限に抑える

SPFレコードでMXメカニズムを使用しないようにすることで、DNSルックアップの制限数である10回以内に収めることができます。MXメカニズムでは、まずドメインのMXレコードを解決し、その後、リストされている各メールサーバーのIPアドレスを解決するために追加のルックアップが行われます。

ドメインに複数のMXレコードがある場合、単一の「mx」メカニズムで複数のルックアップが発生する可能性があります。 可能な場合は、メールサーバーのIPv4またはIPv6エントリに置き換えてください。

インクルード文を統合する

SPFレコードに複数の関連サービスを指す「include」メカニズムが含まれている場合、それらを統合できるかどうかを確認してください。

一部のメールサービスプロバイダーは重複するインフラを共有しているため、冗長なルックアップを実行している可能性があります。各インクルードを検証し、それが依然として必要かどうか、また基盤となるIPアドレスを直接参照できるかどうかを判断してください。

変更のたびに検証する

SPFレコードの変更後は、10回のルックアップ制限への準拠を確保するため、必ず検証を行うことが不可欠です。

マーケティングプラットフォーム用の「include」を1つ追加するといったわずかな変更であっても、ネストされたルックアップがトリガーされると、レコードが制限値を超えてしまう可能性があります。 更新のたびにSPF診断ツールでレコードを検証し、有効な状態を維持していることを確認してください。

SPFレコードの平坦化：その概要と適用タイミング

SPFレコードのフラット化は、SPFのDNSルックアップ回数10回という制限を克服するために、SPFレコードを最適化する手法です。 これは、複雑なメールインフラを持つ組織において最も議論されている解決策の一つですが、理解しておくべきトレードオフも伴います。

完全な SPFレコードの最適化方法に関する SPFレコードを最適化する方法については、当社のSPF最適化ガイドブログをご覧ください

SPFレコードの平坦化がどのように機能するか

SPFレコードのフラット化は、SPFレコード内のルックアップを引き起こすメカニズムを、対応するIPアドレスまたはCIDR範囲で置き換えることで、SPFレコードの検証に必要なDNSクエリの数を削減します。

「include:emailprovider.com」のような参照を含める代わりに（これは1つ以上のDNSルックアップを引き起こす）、その参照を基盤となるIPアドレスに解決し、ip4またはip6メカニズムを使用してレコードに直接リストします。

たとえば、「include:emailprovider.com」が 3 つの IP アドレスに解決される場合、フラット化処理によって、include ステートメントがこれら 3 つの IPv4 エントリに置き換えられます。 これにより、そのプロバイダーに対して追加のDNSクエリを行うことなく、SPFチェックは同じ結果を返すようになります。

平坦化が役立つ場合

SPFレコードを平坦化することで、DNSクエリメカニズムと修飾子の数を10未満に削減できます。これは特に以下の場合に有用です：

• あなたのドメインは多くのサードパーティサービスを通じてメールを送信しており、インクルード数だけでも10を超えています
• 既に未使用のサービスを削除し、可能な限り統合しましたが、依然として上限を超えています
• 短期的な最適化戦略を策定しながら、記録を迅速にコンプライアンスに適合させる方法が必要です

手動によるSPFのフラット化が一時的な対処法に過ぎない理由

SPFレコードをフラット化すれば、10件のルックアップ制限内に素早く収めることができますが、手動でSPFレコードをフラット化することは長期的な解決策とは言えません。なぜなら、それによって別のリスクが生じ、同様に簡単にメール配信が妨げられる可能性があるからです。

リスク1：ベンダーのIPアドレスが変更される

多くのメールサービスプロバイダーは、事前の通知なしに送信用IPアドレスの範囲を変更したり拡大したりしています。

SPFレコードを手動でフラット化する場合：

• それらのIPアドレスをDNSにハードコーディングする
• しかし、プロバイダーは裏で進化し続けています

IPリストが変更された瞬間、SPFレコードが古くなり、正当なメールの認証に失敗するようになります。

リスク 2：SPFレコードのサイズ（255文字＋DNSの制限）

フラット化を行うと、複数のIPアドレスを含む「includes」が置き換えられ、SPFレコードがすぐに肥大化する可能性があります。

これにより、2つの問題が生じます：

• DNSのTXTレコードは、1つの文字列につき255文字までです
• SPFレコードが長すぎると、解析に失敗したり、DNSの制限を超えたりする可能性があります

ルックアップの制限を「修正」しようとすると、意図せず構文エラーやレコードの切り捨ての問題を引き起こす可能性があります。

リスク3：監視や可視化が行われていない

手動でのフラット化は静的です。以下の操作を行うための組み込みの方法は存在しません：

• IPアドレスの範囲が変更されたことを検知する
• 期間ごとのトラック検索回数
• 認証の失敗を通知します

つまり、配信率が低下するまで、問題に気づかないことがよくあるということです。

リスク4：継続的な保守の負担

次の操作を行うたびに：

• 新しいメールサービスを追加する
• インフラの変更
• または、プロバイダがIPアドレスを更新する場合

SPFレコードを手動で再構築し、検証する必要があります。

複数のドメインやクライアントを管理するチームにとって、これはすぐに手に負えなくなる。

マニュアル SPFのフラット化 は、根本的な複雑さ（動的なインフラストラクチャ）ではなく、症状（ルックアップの制限）を解決するものです。

そこで、ホスト型SPFソリューションの出番となります。

IPアドレスを固定で設定する代わりに、PowerDMARCのようなプラットフォームでは、マクロや自動更新機能を用いてSPFレコードを動的に管理するため、手動での頻繁な操作を必要とせずに、ルックアップ制限内に収めることができます。

知っておくべきその他のSPFレコードの制限事項

DNSルックアップの10回という制限は、SPFの制限として最もよく知られていますが、それだけではありません。 予期せぬ認証エラーを防ぐため、ドメイン所有者はこれらの追加のSPFレコードの制限について認識しておく必要があります。

概要： 10件の検索制限に加え、SPFにはレコード数、文字数制限、無効な検索、および電子メール認証に影響を与える転送シナリオに関する制約があります。

ドメインごとに1つのSPFレコードのみ

SPF仕様では、各ドメインが単一のSPF TXTレコードのみを公開することが要求されます。

SPFレコードに1つのドメインに対して複数のSPFレコードが含まれている場合、SPF PermErrorが発生する可能性があり、受信サーバーがメールを拒否したり、誤った処理を行ったりする恐れがあります。追加の送信者を認証する必要がある場合は、新しいSPFレコードを作成するのではなく、既存のSPFレコードにそれらを追加してください。

SPFは差出人アドレスではなくリターンパスをチェックします

SPFは、受信者が目にする人間が読めるFromフィールドではなく、返信元アドレスのドメインを認証します。これは、攻撃者が異なる返信元ドメインを使用することで、Fromアドレスを偽装しながらSPFを通過できることを意味します。

DMARC このギャップに対処するため、DMARCは人間が読めるFromフィールドのドメインと、SPFによって認証されたドメインとの一致または整合性を要求します。

255文字の文字列制限

SPFレコードの文字数は合計で255文字を超えることもありますが、1つの DNS TXTレコード 文字列は255文字に制限されています。 長いSPFレコードは、同じTXTレコード内で複数の文字列に分割する必要があります。

ほとんどのDNSプロバイダーはこれを自動的に処理しますが、設定ミスによる分割は解析エラーを引き起こす可能性があります。

無効ルックアップ制限

10回のDNSルックアップ制限に加え、SPF仕様では「無効なルックアップ」の数も制限しています。これは、レコードを返さないDNSクエリ（空の応答またはNXDOMAIN応答）を指します。

この制限（通常は2回の無効なルックアップ）を超えると、SPF PermErrorも発生する可能性があります。

転送されたメールに対する保護はありません

メールが転送されると、送信元のIPアドレスは転送サーバーのIPアドレスに変更されますが、そのIPアドレスは元の送信者のSPFレコードに記載されていないことがほとんどです。そのため、元のメッセージが正当なものであったとしても、転送されたメールはSPFチェックに失敗してしまう可能性があります。

SPFルックアップの制限内に収めるためのベストプラクティス

SPF 10のDNSルックアップ制限を超えないようにするには、継続的な管理が必要です。レコードを最適な状態に保ち、予期せぬ障害を防ぐために、以下のベストプラクティスを参考にしてください：

• 送信プラットフォームを追加または削除するたびに、SPFレコードを確認してください
• 1つのドメインにつき、SPFレコードは1つ以上公開しないでください
• 次の ptr メカニズムは使用せず、レコード内に存在する場合は削除してください
• 使用 ip4: および ip6: IP範囲が安定しており、既知である場合はどこでも
• 断続的なSPFエラーを早期に検知するために、DMARCレポート機能を設定する
• PowerDMARCなどの自動監視ツールを使用して、ルックアップ回数が変化した際にアラートを受け取る
• サードパーティの送信サービスを3～4つ以上管理している場合は、ホスト型SPFの導入をご検討ください

PowerDMARCのホスト型SPFがSPFルックアップの失敗を防ぐ仕組み 

現代のメール環境では、手動によるSPF管理はすぐに機能しなくなります。新しいメールプラットフォーム、マーケティングツール、CRM、ヘルプデスク、あるいはクラウドサービスが導入されるたびに、SPFのインクルードやネストされたルックアップが増え、メンテナンスの負担も増大するからです。

手動によるSPFのフラット化は一時的にルックアップ回数を減らすことができますが、ベンダーが送信インフラを更新するにつれて、ハードコードされたIPアドレスの正確性を維持するという新たな問題が生じます。

PowerDMARCのHosted SPF、 またはPowerSPFは、送信インフラストラクチャの変更に合わせてSPFレコードを常に最新の状態に保つことで、根本的な管理上の課題を解決します。静的なSPFフラット化とは異なり、Hosted SPFはバックグラウンドでSPF設定を動的に管理し、組織が継続的なDNSメンテナンスを行うことなくRFC 7208に準拠し続けることを支援します。

PowerSPFを利用することで、組織は以下のことが可能になります：

• ベンダーのIPアドレスが変更された際に、SPFレコードを自動的に更新する
• SPFマクロを使用して、DNS検索の制限数（10件）およびDNSの文字数制限内に収める
• SPFレコードを手動で繰り返し編集する代わりに、一度だけDNS設定を変更してください
• 複数のベンダー、ネストされたインクルード、地域ごとのインフラストラクチャ、およびエンタープライズドメインにまたがる複雑なSPF設定を管理する
• 配信率に影響が出る前に、SPFの失敗、無効な照会、および認証の問題を監視する

これは、Microsoft 365、Salesforce、HubSpot、SendGrid、Mailchimp、その他のサードパーティ製メール送信サービスを同時に利用している組織にとって特に重要です。こうした環境では、ネストされたインクルードにより、SPFレコードがRFCの制限を超えてしまうことがあり、その際、何の前触れもなく発生する可能性があるためです。

あるPowerDMARCのお客様は次のように説明しています： 「PowerDMARCはSPFエラーの解決に大いに役立ちます。特に、技術的な制限により通常は許可されていない数のSPFインクルードが必要な顧客にとって、SPFのフォールディングを容易にする点で大きなメリットがあります。」

自動化された SPFフラット化、リアルタイムのルックアップ監視、エラーアラート、およびSPF、DKIM、DMARC、BIMI向けのツールを備えたPowerDMARCは、組織がSPFレコードをルックアップ制限内に収め、よりクリーンな認証設定を維持できるよう支援します。

まずは、以下のリンクからSPFの照会回数を確認してください PowerDMARCのSPFチェッカー を使用してSPFの照会回数を確認し、メール認証に影響が出る前に問題を特定してください。

よくあるご質問

1. SPF 10のDNS検索制限とは何ですか？

RFC 7208で定義されているSPF仕様では、各SPFチェックにおいてDNSクエリを実行するメカニズムは最大10個までと制限されています。

SPFレコードの評価中に10回を超える照会が必要となる場合、受信サーバーはSPF PermErrorを返します。これはDMARCによって失敗として扱われます。これにより、正当なメールが拒否されたり、スパムフォルダに振り分けられたりする可能性があります。

2. 10回の検索制限には、どのSPFメカニズムがカウントされますか？

以下のメカニズムはDNSルックアップをトリガーし、制限数にカウントされます：

• インクルード
• a
• エムオーエス
• 伝令者
• ある
• リダイレクト=

以下は対象外です：

• ip4, IPv6 (直接IP)
• すべて (包括的)
• v=spf1 (バージョンタグ)
• SPFレコードを取得するための最初のDNSクエリ

3. SPF PermErrorとは何ですか？

受信サーバーがSPFレコードを正しく評価できない場合、SPF PermError（恒久的なエラー）が発生します。

最も一般的な原因は、DNS 検索の制限数（10回）を超過したことですが、以下の理由でも発生する可能性があります：

• 構文エラー
• 複数のSPFレコード
• ルックアップ制限の違反
• 回覧には以下の内容が含まれます

このような状況になると、SPFは完全に機能しなくなり、メールの配信に影響が出る可能性があります。

4. SPFの無効レコード検索の制限とは何ですか？

10回のルックアップ制限に加え、RFC 7208では、結果が返されないDNSクエリ（NXDOMAINまたは空の応答）である「voidルックアップ」も制限しています。

SPFチェックごとに、無効なルックアップは2回までです。

SPFレコードの照会が3回目の無効な照会を引き起こした場合、総照会回数が10回未満であっても、受信サーバーはPermErrorを返します。

5. SPFのフラット化によって、10件のルックアップ制限は解消されますか？

はい、でも一時的なものです。

SPFのフラット化により、 include の仕組みを直接的なIPアドレスに置き換え、DNSルックアップを削減します。しかし、メールサービスプロバイダーは頻繁にIP範囲を更新するため、継続的なメンテナンスが必要となります。

平坦化されたレコードが古くなってしまうと、正当なメールでもSPFチェックに失敗する可能性があります。

6. SPFレコードがDNSルックアップを何回実行しているかを確認するにはどうすればよいですか？

SPFチェッカーツールを使用すれば、レコードを分析し、ネストされたインクルードを含めたDNSルックアップの回数をカウントすることができます。

PowerDMARCのSPFチェッカーには次のように表示されます：

• 総検索回数
• ルックアップ回数
• どのメカニズムがルックアップを消費しているか

これにより、配信率に影響が出る前に問題を特定することができます。

7. SPFフラットニングとSPFマクロの違いは何ですか？

SPFフラット化機能は、インクルードをIPアドレスに静的に置換するため、ルックアップ回数は減少しますが、手動での更新が必要となります。

SPFマクロ（ホスト型SPFソリューションで使用される）は、評価時にSPFレコードを動的に解決するため、IPリストを手動で管理することなく、ルックアップ制限内に収めることができます。

マクロは拡張性が高く、複雑なメール環境や複数のベンダーが関わるメール環境に適しています。

8. SPFレコードはどのくらいの頻度で確認すべきですか？

SPFレコードを確認してください：

• メールサービスを追加または削除するたびに
• インフラの変更後
• 少なくとも月に1回

複雑な設定環境では、検索制限の問題を早期に発見し、配信率を安定させるために、継続的な監視を行うことをお勧めします。