ほとんどの組織は、認証が破綻した後にSPFレコードの制限を発見します。その時点で、正当なメールはすでにバウンスし、スパムに入り込み、または目に見えるエラーなしに静かに失敗しています。10 DNS検索制限は推奨事項ではありません。これはSPF評価を終了し、恒久的なエラーを返す厳格な技術的境界であり、通常、他の認証が通過していてもDMARC整合性の失敗を引き起こします。

最近のメール認証ベンチマークデータによると、3つ以上のサードパーティメールプラットフォームを使用している組織の63%が、初期展開から18ヶ月以内にSPF検索制限を超えています。この失敗は構造的なものです。include:メカニズムを通じてSPFに追加されるすべての承認された送信者がDNSクエリ数を増加させ、ほとんどの組織は、クエリを間違ってカウントしていることに気付くずっと前に制限に達します。

この記事では、SPF検索制限がどのように機能するか、制限を超えたときに何が破綻するか、配信に影響を与える前に失敗を特定する方法、およびベンダーカバレッジを維持しながら技術的境界内に留まるためにSPFを再構築する方法を説明します。

I. SPF検索制限とは何か?

3つ以上のメールプラットフォームを利用する組織の63%が、18か月以内にSPFのDNSルックアップ上限である10回を超え、恒久的なメール認証エラーが発生しています。

SPF(Sender Policy Framework)は、送信メールサーバーがドメインの代わりにメールを送信する権限を持っていることを検証します。受信サーバーは、SPFレコードを解決し認証チェーンを評価するためにDNS検索を実行します。RFC 7208は、悪用、無限再帰、およびDNS増幅攻撃を防ぐために、SPF評価ごとに10 DNS検索の厳格な制限を設定しています。

SPF評価が10 DNS検索を超えると、受信サーバーは処理を停止し、permerrorを返します。これは一時的な条件ではなく、恒久的な失敗です。この結果は、ほとんどの実装でSPF失敗として扱われ、次のことを意味します:

  • DKIMが通過してもDMARC整合性が失敗します。SPFが通過せず整合しなかったためです。
  • レピュテーションシグナルが低下します。メールボックスプロバイダーが認証の不整合を認識するためです。
  • 配信が予測不可能になります。一部の受信サーバーは静かにフィルタリングし、他はリジェクトし、多くはバウンスメッセージで失敗を表示しません。

制限は固定です。ドメインサイズ、メール量、またはビジネスの複雑さに応じてスケーリングしません。すでに10検索に達している時に承認された送信者を1つ追加すると、SPFレコード全体が破綻します。

II. DNS検索のカウント方法

SPFメカニズムとDNSルックアップコストの比較表：include、a、mx、ptr、redirect、exists は10回のDNSルックアップ制限にカウントされますが、ip4、ip6、all はカウントされません。

SPF検索のカウントは、SPFレコード内のすべてのメカニズムがDNS検索をトリガーするわけではないため、しばしば誤解されています。以下のメカニズムは10検索制限にカウントされます:

  • include: – 各include:メカニズムは少なくとも1つの検索をトリガーし、含まれるレコードに追加のinclude:、a、mx、またはptrメカニズムが含まれている場合、それらは再帰的にカウントされます。
  • a – ドメインのAレコードをクエリします。
  • mx – ドメインのMXレコードをクエリし、各MXターゲットは追加のAレコード検索を必要とします。
  • ptr – PTRレコードをクエリします(非推奨で使用すべきではありません)。
  • redirect= – 1つの検索をトリガーし、リダイレクトされたレコード内の検索も含みます。
  • exists: – 指定されたドメインのAレコードをクエリします。

以下のメカニズムはカウントされません:

  • ip4: – 静的IPアドレス、DNSクエリは不要です。
  • ip6: – 静的IPv6アドレス、DNSクエリは不要です。
  • all – デフォルトアクションを定義するメカニズム、DNSクエリはありません。

例:隠れた検索の爆発

一見シンプルなSPFレコードが、制限を素早く超える可能性があります:

v=spf1 include:_spf.google.com include:sendgrid.net include:spf.protection.outlook.com include:mail.zendesk.com include:_spf.salesforce.com ~all

見かけの検索数: 5
実際の検索数: 12+

理由は以下の通りです:

  • include:_spf.google.com → 3検索(Googleはネストされたincludeを使用)
  • include:sendgrid.net → 2検索
  • include:spf.protection.outlook.com → 2検索
  • include:mail.zendesk.com → 2検索
  • include:_spf.salesforce.com → 3検索

合計: 12検索。このレコードはpermerrorを返し、SPF認証に失敗します。

組織は、5つのinclude:ステートメントが5つの検索に等しいと想定することがよくあります。しかし、そうではありません。含まれる各ドメインは複数のネストされた検索に展開される可能性があり、それらは合計にカウントされます。

III. 制限を超えたときに何が破綻するか

1. SPFがpermerrorを返す

受信サーバーが10検索制限に達すると、SPF評価は停止し、permerrorを返します。これはAuthentication-Resultsヘッダーに次のように記録されます:

spf=permerror (too many DNS lookups)

メールはSPF認証の恩恵を受けません。DKIMが存在しないか整合しない場合、DMARCは失敗します。

2. DMARC整合性の失敗

DMARCは、SPFまたはDKIMのいずれかが通過し、From:ドメインと整合することを要求します。SPFがpermerrorを返す場合、整合できません。DKIMが欠落している、署名されていない、または整合していない場合、DMARCは完全に失敗します。

p=quarantineまたはp=rejectでは、これはメールがフィルタリングまたはブロックされることを意味します。p=noneでは、失敗は見えませんが、集約レポートに記録され、時間とともにレピュテーションが低下します。

3. 静かなフィルタリング

すべてのメールボックスプロバイダーがSPF permerrorのメールを拒否するわけではありません。一部は静かに配信を格下げします:

  • メールは受信トレイではなくスパムに入ります。
  • メールは遅延またはスロットリングされます。
  • メールは配信されますが、受信者のメールクライアントで疑わしい可能性があるとフラグが立てられます。

失敗が静かなため、組織は、苦情率が上昇したり、エンゲージメントが低下したり、主要なキャンペーンが失敗するまで、SPFが破綻していることに気付かないことがよくあります。

4. ベンダー固有の影響

影響はベンダーによって異なります:

  • Gmail: permerrorを失敗シグナルとして扱いますが、DKIMが通過し、ドメインレピュテーションが強い場合は配信される可能性があります。ただし、受信トレイの配置は時間とともに低下します。
  • Microsoft 365: permerrorをSPF失敗として扱います。DKIMが整合しない場合、ポリシーとレピュテーションに応じてメールがフィルタリングまたは拒否されます。
  • Yahoo、AOL: 厳格な実施。permerrorは拒否またはスパムフィルタリングをもたらすことが多いです。
  • メーリングリスト、転送者: エンベロープ送信者が整合しないため、転送中にSPFが破綻します。元のSPFレコードがすでにpermerrorの場合、転送されたメールには認証カバレッジがありません。

5. DMARCレポートに失敗が表示される

DMARCポリシーが集約レポートを有効にしたp=noneに設定されている場合、DMARC集約レポートのspf結果フィールドにpermerrorが表示されます。レポートには次のように表示されます:

<auth_results>
  <spf>
    <domain>example.com</domain>
    <result>permerror</result>
  </spf>
</auth_results>

失敗は記録されますが、DMARCレポートを積極的にレビューしていない場合、配信の問題が表面化するまで気付きません。これが、多くの組織が配信の問題が表面化するまでSPF制限を超えていることに気付かない理由です。

IV. 破綻する前にSPF検索数を特定する方法

手動SPF検索カウント

各include:メカニズムを再帰的に展開し、遭遇したすべてのinclude:、a、mx、redirect=、exists:メカニズムを集計することで、手動でSPF検索をカウントできます。

ステップバイステッププロセス:

  1. SPFレコードをクエリします:
   dig TXT example.com
  1. 各include:メカニズムについて、含まれるドメインをクエリします:
   dig TXT _spf.google.com
   dig TXT sendgrid.net
  1. プライマリレコードとすべてのネストされたレコード内のDNS検索をトリガーするすべてのメカニズムをカウントします。

このプロセスは時間がかかり、エラーが発生しやすく、特にベンダーが通知なしにSPFレコードを変更する場合に顕著です。

自動SPF検索検証

DNS検索を自動的にカウントし、合計に貢献するメカニズムを特定するSPFレコードチェッカーを使用します。次のようなツールがあります:

  • Skysnag Domain Checker – ドメインをスキャンし、SPF検索をカウントし、10検索制限を超えるか近づいているレコードにフラグを立てます。
  • dig + 手動再帰(技術的ですが包括的)。
  • サードパーティのSPFバリデーター(精度は様々で、一部はネストされた検索を正しくカウントしません)。

Skysnag Domain Checkerは次を表示します:

  • 現在の検索数
  • どのinclude:メカニズムが複数の検索に展開されるか
  • レコードがすでにpermerrorにあるかどうか
  • フラット化または再構築の推奨事項

V. SPF検索制限の問題を修正する方法

1. 可能な場合はinclude:をip4:またはip6:に置き換える

サードパーティ送信者が静的IP範囲を提供している場合、include:メカニズムを明示的なIPアドレスに置き換えます:

変更前:

v=spf1 include:mail.vendor.com ~all

変更後:

v=spf1 ip4:203.0.113.0/24 ip4:198.51.100.5 ~all

これにより、その送信者のDNS検索が排除されます。ただし、このアプローチは、ベンダーが静的IPを使用し、頻繁にインフラストラクチャをローテーションしない場合にのみ機能します。多くのSaaSプラットフォームはIPをローテーションするため、静的リストは実用的ではありません。

2. SPFレコードをフラット化する

SPFフラット化は、すべてのinclude:メカニズムを最終的なIPアドレスに解決し、それらを単一のレコードに統合します。これによりDNS検索が削減されますが、運用リスクが生じます:

  • ベンダーのIP変更により認証が破綻します。 ベンダーがIPアドレスを追加またはローテーションすると、フラット化されたSPFレコードが古くなり、正当なメールが認証に失敗します。
  • 手動更新が必要です。 ベンダーのSPFレコードを監視し、変更が発生するたびにフラット化されたレコードを更新する必要があります。
  • ベンダーが変更したときに通知がありません。 ほとんどのベンダーはSPFレコードの変更を発表しないため、メールがバウンスし始めたときにのみ失敗を発見します。

フラット化は短期的な修正として機能しますが、継続的なメンテナンスと監視が必要です。

3. サブドメインを使用して送信者をセグメント化する

特定のメールストリームを専用のサブドメインに移動し、それぞれに個別のSPFレコードを作成します:

例:

  • example.com → プライマリビジネスメールの認証(Microsoft 365)
  • marketing.example.com → マーケティングプラットフォームの認証(SendGrid、Mailchimp)
  • support.example.com → サポートツールの認証(Zendesk、Intercom)

各サブドメインには独自のSPFレコードがあり、各レコードは10検索制限内に収まります。このアプローチは、明確な送信者セグメンテーションを持つ組織に適していますが、以下が必要です:

  • サブドメイン送信のメールプラットフォームサポート(すべてのプラットフォームがこれをサポートしているわけではありません)。
  • 各サブドメインのDNS設定。
  • サブドメイン間でのDMARCポリシーの整合性(設定されていない場合、DMARCが失敗する可能性があります)。

4. 未使用または冗長なinclude:メカニズムを削除する

多くのSPFレコードには、もはや使用されていない送信者が含まれています:

  • レガシーマーケティングプラットフォーム
  • 廃止されたサポートツール
  • 重複したinclude:ステートメント(例:同じベンダーの2つのエントリ)
  • テストされたが展開されなかったベンダー

SPFレコードを監査し、アクティブな送信者に対応しないinclude:メカニズムを削除します。Skysnag Protectを使用して、どの送信者がアクティブにメールを送信しているか、どのinclude:エントリが未使用かを特定します。

5. 可能な場合はベンダーを統合する

複数のマーケティングプラットフォーム、サポートツール、またはトランザクションメールプロバイダーを使用している場合は、より少数のベンダーに統合します。これにより、include:メカニズムの数が減り、SPF管理が簡素化されます。

例えば:

  • 3つではなく1つのトランザクションメールプラットフォームを使用する。
  • 単一のESPを通じてマーケティングメールを統合する。
  • 1つのチケットシステムを通じてサポートメールをルーティングする。

これは技術的な修正だけでなくビジネス上の決定ですが、SPFの複雑さを軽減する最も持続可能な方法です。

VI. SPF検索制限とDMARC実施

SPFが検索制限を超えてpermerrorを返すと、DMARC評価はDKIMが通過して整合するかどうかに依存します。

シナリオ1: SPF permerror + DKIM通過 + DKIM整合

DKIMが必要な認証と整合性を提供するため、DMARCは通過します。SPF失敗は配信をブロックしませんが、全体的な認証姿勢を弱めます。

シナリオ2: SPF permerror + DKIM失敗または欠落

DMARCは失敗します。ポリシーがp=quarantineまたはp=rejectに設定されている場合、受信サーバーがポリシーを尊重すると、SMTP配信中にメールがフィルタリングまたは拒否されます。ポリシーがp=noneの場合、失敗は記録されますが実施はトリガーされません。

シナリオ3: SPF permerror + DKIM通過だが整合せず

DMARCは失敗します。DKIMはFrom:ドメインと整合する必要があります(厳格または緩和された整合のいずれか)。DKIMが通過しても整合せず、SPFがpermerrorの場合、DMARCには有効な認証パスがありません。

最も一般的な失敗モードはシナリオ2です。SPFが破綻し、サードパーティ送信者にDKIMが設定されておらず、DMARCが完全に失敗します。

VII. 時間の経過とともにSPF検索数を監視する方法

承認された送信者を追加または削除すると、SPFレコードが変更されます。検索数を監視することで、配信に影響を与える前に認証失敗を防ぎます。

継続的なSPF監視のためにSkysnag Protectを使用する

Skysnag ProtectはSPFレコードを継続的に監視し、DNS検索数を追跡します。ベンダーがSPFレコードを更新し、合計検索数が増加すると、Skysnagは10検索制限を超える前にアラートを送信します。

仕組み:

  1. SkysnagがSPFレコードを毎日スキャンします。
  2. すべてのinclude:メカニズムの検索数を追跡します。
  3. 検索数が制限に近づくか超えるとアラートを送信します。
  4. フラット化、サブドメインセグメンテーション、またはIP統合の推奨事項を提供します。

これにより、SPFが破綻し、配信が低下してからそれを発見するという静かな失敗モードを防ぎます。

Skysnag ProtectでSPFレコードの監視を開始しましょう。

VIII. SPFの代替案:MTA-STSとDKIMのみの認証

一部の組織はSPFを完全に排除し、認証にDKIMに依存しています。これにより検索制限を回避できますが、エンベロープレベルのなりすまし防止におけるSPFの役割が削除されます。

DKIMのみの認証

DKIMは暗号署名を使用してメッセージ本文とヘッダーを認証します。SMTP中に使用されるアドレスであるエンベロープ送信者を検証しないため、特定のタイプのなりすましを防ぐことはできません。ただし、DKIMには検索制限がなく、転送中に破綻せず、SPFよりも強力な暗号保証を提供します。

DKIMのみの認証を展開する場合:

  • すべての承認された送信者にDKIMが設定されていることを確認します。
  • サブドメインの柔軟性を許可するために、aspf=r(緩和された整合)でDMARCを使用します。
  • DMARC集約レポートを監視してDKIMカバレッジを確認します。

トランスポートセキュリティのためのMTA-STS

MTA-STS(Mail Transfer Agent Strict Transport Security)は暗号化された配信を強制しますが、SPFやDKIMを置き換えるものではありません。これにより、中間者攻撃を防ぐTLS経由でメールが配信されることが保証されますが、送信者を認証するものではありません。

MTA-STSはDMARCと並行して機能し、代替ではありません。

IX. 一般的なSPF検索制限のミス

1. ベンダーのSPFレコードが決して変更されないと仮定する

ベンダーは、インフラストラクチャの追加、IPのローテーション、またはホスティングプロバイダーの変更のためにSPFレコードを更新します。SPFレコードをフラット化し、ベンダーの変更を監視しない場合、認証が静かに破綻します。

2. DNS検索ではなくinclude:ステートメントをカウントする

5つのinclude:メカニズムを持つSPFレコードは、含まれる各レコードに追加のネストされたinclude:、a、またはmxメカニズムが含まれている可能性があるため、12以上のDNS検索をトリガーする可能性があります。

常に、トップレベルのメカニズムだけでなく、合計再帰的DNS検索をカウントします。

3. ptrメカニズムの使用

ptrメカニズムは非推奨で非効率的です。逆DNS検索をトリガーし、クエリ数を増やします。最新のSPFレコードではptrを使用しないでください。

4. 公開前にSPF変更をテストしない

テストなしにSPF変更を公開すると、すべてのメールの認証が破綻する可能性があります。本番に適用する前に、テストドメインまたはサブドメインを使用してレコードを検証します。

5. DMARC集約レポートを無視する

DMARCレポートはSPF permerror失敗を表示しますが、多くの組織はレポートを定期的にレビューしていません。配信に影響を与える前にSPFの問題を表面化するために、Skysnagを通じて監視を設定します。

X. 重要なポイント

SPFルックアップ制限に柔軟性はありません。10DNSルックアップという境界は固定された技術的制約であり、これを超えるとpermerrorが返され、SPF認証が破綻し、多くの場合DMARC失敗を引き起こします。

複数のサードパーティメールプラットフォームを使用している組織は、気づかないうちに制限を超えることがよくあります。これは、DNSルックアップが再帰的にカウントされること、そしてベンダーのSPFレコードが予告なく変更されることが理由です。

失敗は多くの場合、静かに発生します。メールは依然として配信される可能性がありますが、スパムフォルダに振り分けられたり、スロットリングされたり、時間の経過とともに評価が低下したりします。DMARC集約レポートにはpermerrorの結果が表示されますが、レポートが積極的に監視されていない場合、配信性の問題が表面化するまで失敗は気づかれません。

SPFルックアップ制限内に収めるには:

  • ベンダーが静的IPを使用している場合、include:メカニズムをip4:またはip6:に置き換える。
  • メールストリームをサブドメイン間で分割し、ルックアップ数を分散させる。
  • 使用していないまたはレガシーのinclude:エントリを削除する。
  • ベンダーを統合してSPFの複雑さを軽減する。
  • SPFレコードを継続的に監視し、ベンダーの変更を検出する。

Skysnag Protectを使用して、DNSルックアップ数を監視し、どの送信者がルックアップの増加に寄与しているかを特定し、SPFが破綻する前にアラートを受信しましょう。Skysnagは、SPF構造の可視性を提供し、ベンダーレコードの変更を追跡し、認証が失敗する前にレコードを再構築するのを支援します。