「またincludeを追加してほしい」と言われるたびに..。SPFの10回制限、根本から解決する方法

あなたの会社のシステム部門あるいは総務部門等でメール配信用のサーバー回りを管理している方は、

• またマーケティング部門から、新しい配信ツールを導入したいと連絡が来た
• 営業部門が、新しいSFAツールからメールを送りたいと言っている

という依頼を耳にするたびに、言われるがままSPFレコードにincludeを1行追加し、そして、また追加し、ある日、突然メールが届かなくなったという連絡を受ける。

原因を調べると、こう表示されている。

Too many DNS lookups(DNSルックアップが多すぎます)

改めてDNSサーバーのincludeを消そうと思っても、消せるレコードがなく、手が止まった経験はありませんか。

今回は、「何かを消して減らす」ではなく、上手くまとめてしまう技術があるということをお伝えしたいと思います。

1. なぜ「増える一方」なのに「10個まで」というルールがあるのか

SPFは「送信元の身分証チェック」の仕組み

SPF(Sender Policy Framework)は、

「このドメインからのメールは、このIPアドレスから送られたものだけを正規として扱って」

と、送信元のルールをDNSに登録しておく仕組みです。当社のブログ記事ではよくお住まいの自治体に届出をする住民票と称しております。

Googleの送信者ガイドラインで記載が必須になってから、なりすましメール対策の基本として多くの企業がすでに導入済みだと思います。

問題は、この「正規の送信元」が、事業が成長するにつれてどんどん増えていくことです。

• 基幹のメールは Google Workspace / Microsoft 365 から
• マーケティングのメルマガは HubSpot から
• 営業のフォローメールは Salesforce から
• 請求書送付は SendGrid から

それぞれのサービスを許可するたびに、SPFレコードにinclude:サービス名という記述を1行足します。

このincludeは、実は「そのサービス側の許可リストを、DNSにもう一度問い合わせに行く」という動作( = DNSルックアップ)を1回発生させています。

訪れてしまう「lookup数10回」という壁

SPFの仕様(RFC 7208)では、1回のメール認証につきDNSルックアップは10回までという上限が定められています。

マーケティングやセールス、管理部門がツールを追加するたびに、この10回にじわじわと近づき、ある日突然その枠を超えます。そして、超えるとどうなるか気になりますよね。

SPFの照合結果はpermerrorという状態になり、そのドメインから送られるメール全体が影響を受ける可能性が出てきます。

技術的に厳密に言うと、SPFの評価はincludeなどのメカニズムを上から順番に確認し、送信元IPと一致した時点で判定を終えます。

そのため、リストの早い位置に書かれているサービスほど影響を受けにくく、後から追加したものほど巻き込まれやすいという性質があります。

ただし、受信側のメールサーバーの実装によっては、メカニズムの順番に関係なく、lookup数が10回を超えた時点でレコード全体を無効と判定してしまうケースも実際には存在します。

どちらの挙動になるかは受信側次第でこちらからは制御できないため、

「新しいツールだけの問題のはずが、いつの間にか全社のメール基盤の問題に発展しているかも!?」

という予測しづらさこそが、この制限の本当に厄介なところです。

ここで、冒頭の悩みに戻ります。

「じゃあ、どのincludeを削ればいいの!?」

2. 「何を消すか」を考える前に、知っておいてほしいこと

「どのincludeを消すべきか」を担当者の一存で判断するのはリスクが高い作業です。きちんとどの部署の、どんな種類のメール配信に使っているのか理解のうえ作業する必要があるからです。

「たぶんもう使っていないはず」という消去法で削ってしまうと、忘れた頃に請求書メールや採用メールが届かなくなる、という事故につながりかねません。

かといって、マーケティングやセールスの各担当に「このツール、もう使っていませんか」と1つずつ聞いて回るのも、担当者にとってはそれだけでかなりの工数です。

つまり、この問題の本質は「どのincludeを消すか」ではなく、

「includeがいくつ増えても、10回という制限に引っかからない仕組みに切り替える」

ことにあります。

これから説明する2つの方法は、どちらも「何かを我慢して削る」のではなく、「増え続けることを前提にした上で、DNSルックアップの回数だけを一定に保つ」という発想の解決策です。

3. 解決策は2つある:フラット化とSPFマクロ

DNSの深い知識がなくても、この仕組みの違いさえ理解しておけば、自社にどちらが合うかは判断できます。

3-1. その前に:自分でやるか、任せるか(Host化という考え方)

フラット化・マクロ化の説明に入る前に、もう一つ知っておいてほしい軸があります。それが「Host化」です。

フラット化とマクロ化は「SPFレコードの中身をどう計算するか」という方式の違いですが、Host化は

「その”計算・更新”作業を、”誰が・どこ”で行うか」

という運用形態の違いです。この2つは対立する選択肢ではなく、実は重なり合う関係にあります。

フラット化を例に説明します。フラット化は、各サービスの許可IPアドレスを調べ上げてSPFレコードに書き込む方式ですが、これを

• 自前でやる場合：担当者が手作業でIPアドレスを調べ、SPFレコードを書き換える。各サービス側のIPアドレスが変更されるたびに、自分で気づいて、また手作業で更新し続けなければならない。更新を忘れた瞬間、また同じエラーが再発する
• Host化されたサービスを使う場合：自社のSPFレコードには、最初にinclude:_spf.autospf.comのような参照を1行設定するだけ。実際のIPリストの計算・更新は、すべてベンダー側のDNS基盤で自動的に行われ続ける

という2通りのやり方が存在します。

マクロ化についても同様で、理屈のうえでは自前でマクロを組むことも不可能ではありませんが、現実的にはAutoSPFやPowerSPFのような専門サービスに「Host化」された形で提供してもらうのが一般的です。

つまり、この記事でこの後ご紹介するAutoSPFやPowerDMARC（PowerSPF）は、いずれも

「フラット化・マクロ化のどちらの方式であっても、Host化された（=自社では最初の1回しかDNSを触らない）形で提供してくれるサービス」

だと理解しておくと、この先の説明がスムーズに頭に入ってくるはずです。

DNS操作に苦手意識がある方にとって一番の不安は「またDNSを触らないといけないかもしれない」という点だと思いますが、Host化されたサービスを選んでいる限り、その不安の大部分は解消されます。

3-2. SPFのフラット化(Flattening)：「今ある許可リストを、まとめて1回分に圧縮する」方式

フラット化は、手間がかかる作業ですが各サービス(include先)の許可IPアドレスをすべて調べ上げて、その結果を確定した1つのリストとしてSPFレコードに直接書き込んでしまう方法です。

たとえば、

• Google Workspaceの許可IPが4つ
• Salesforceの許可IPが6つ

あったとして、毎回includeで問い合わせに行く代わりに、最初からその10個のIPアドレスをそのままSPFレコードに書いてしまう、というイメージです。

こうすることで、受信側は何個のincludeがあったかに関係なく、実質1〜3回程度のDNSルックアップで済むようになります。

この「IPアドレスが変わったら更新し直す」という作業は、手作業でやると地味に手間がかかります。

ここを自動化・Host化してくれるサービス(AutoSPF、PowerDMARCなど)を使えば、DNSに詳しくなくても、この更新作業自体を意識せずに済むようになります。

3-3. SPFマクロ(Macro化)：「その都度、外部の管理基盤に照合を任せる」方式

もう一つの方法がSPFマクロです。

フラット化が「その時点のリストを固定で書き込む」のに対し、マクロ方式はSPFレコードには実際のIPアドレスを一切書かず、認証が発生するたびに、外部の管理基盤にリアルタイムで照合を任せる仕組みです。

「また新しいツールを入れたい」と言われるたびに不安になる状況を根本的になくしたいなら、このマクロ方式は、includeの数そのものを気にしなくてよくなるという点で、精神的な負担を大きく減らしてくれる選択肢です。

3-4. フラット化とマクロ化の比較まとめ

配信ツールがどんどん増えていく組織であれば、長期的にはマクロ方式の方が「またincludeで悩む」というストレスから解放されやすい、というのが実務上の傾向です。

いずれの方式を選ぶ場合も、自前運用ではなくHost化されたサービスを選ぶことで、「自社では最初の1回しかDNSを触らない」という運用に変えられる点は共通しています。

4. SPFがFailしても、DKIMが生きていればメールはおおむね届くが..

「10回を超えたら、今日から全部のメールが届かなくなるの!?」

と背筋を冷やす必要はありません。メールの到達性に関する正しい知識を身に着けてください。

DMARCは「SPFかDKIM、どちらか一方が合格すればOK」という判定

SPFのほかに、メール本文に電子署名を付けて改ざんの有無を証明するDKIM(DomainKeys Identified Mail)という仕組みがあります。そして両者を統括するDMARCには、次のルールがあります。

「SPFかDKIM、どちらか一方が正しく認証されれば、DMARCとしては合格と判定される」

つまり、SPFがpermerrorになっていても、DKIM署名さえ正しく機能していれば、DMARCの判定上はセーフになり、メールは通常通り受信ボックスに届く可能性がかなり高いのです。

SPFのFailを放置してはいけない理由

SPFは送り先の社内転送やメーリングリスト経由の場合、転送時のIPアドレスが使われることになるためFailになることが多いです。

また、転送の過程でセキュリティソフトによる件名やヘッダーの書き換えが行われると、実はDKIM署名の方も無効になってしまうことがあります。

このSPFとDKIM、両方の命綱が同時に切れれば、DMARCは正真正銘の不合格で、迷惑メールフォルダに入る可能性が極めて高くなります。

“DKIMが生きているから大丈夫”という安心感は、あくまで受信側の対応に委ねられています。

SPFのpermerrorそのものを不審な兆候として迷惑メール判定に加点する受信サーバーも存在するため、DMARCとは別の理由で迷惑メール扱いされるリスクは残ります。

5. 自社はどちらを選ぶべきか

ステップ1:現状のLookup数を確認する

無料のSPFチェッカーで、現状のドメインのLookup数をまず確認しましょう。10回未満であれば、まだ慌てる必要はありません。私が好きなのはこちらのCheckerです。

https://easydmarc.com/tools/spf-lookup

ステップ2:Lookup数と、今後の追加ペースで選ぶ

• 10〜20回程度で、社内からのツール追加依頼が今後も落ち着かなそうな場合
  → フラット化でひとまず十分ですが、依頼が続くようであれば早めにマクロ方式への切り替えを検討してください。
• 20回を超えている、あるいは複数ドメイン・複数ブランドを運用している場合
  → マクロ方式に切り替えるタイミングです。以降は「あと何個追加できるか」を気にせず、依頼に応じられるようになります。
• 複数の顧客ドメインを代理管理している
  → マクロ方式一択と考えて問題ありません。

大事なのは、「今は小規模だから安いフラット化で」と選んでも、事業やマーケティング施策の拡大でサービス数が増えてきたら、途中でマクロ方式に切り替えるのは自然な流れだということです。

多くのサービスはプランのアップグレードでこの移行をスムーズに行えます。

6. 技術方式だけでなく、「どのサービスを使うか」も重要な選択

ここまでは「フラット化かマクロ化か」という技術方式の話でした。実務では、もう一段階、「どのベンダーのサービスを使うか」という選択も必要です。

当社が取り扱いをしている、代表的な2つのサービスとして、AutoSPFとPowerDMARC(付属サービスのPowerSPF)があります。

AutoSPFの特長

• SPF管理そのものに特化したシンプルな設計
• 月間メール送信数は全プランで無制限(通数による超過課金がない) ← これがオススメポイント
• DNSの再スキャンは15分ごとに自動実行
• フラット化とマクロ方式(Premiumプラン)の両方を提供、いずれもHost化された状態で提供
• サブドメインを別途登録すると、それぞれ独立した1ドメインとして課金対象にカウントされる
• DMARCレポーティング機能は含まれておらず、必要な場合は姉妹サービスを別途利用
• 管理画面・サポートは英語のみ

SPFの自動フラット化サービス

PowerDMARC(付属機能であるPowerSPF)の特長

• SPFだけでなく、DMARC・DKIM・BIMI・MTA-STSまで含めたメール認証基盤を一体で運用できるプラットフォーム
• 月間メール送信数はプランごとに上限がある(例:Plusプランで50万通まで、Premiumプランで5,000万通まで)
• サブドメイン(レベル2ドメイン)はメインのドメインに含まれる扱いとなり、独立した課金対象にならない
• SPFはマクロ方式を標準として提供、Host化された形で運用
• DMARC集約レポート、脅威インテリジェンス、アラート機能、監査ログ、SSOなど、ガバナンス・レポーティング機能が豊富
• 日本語を含む11言語に対応した管理画面

PowerDMARC

どちらを選ぶべきか、目的別の整理

• とにかく配信量が多く、SPFのエラーだけを解消したい
  → 通数無制限のAutoSPFが有利。ただしサブドメインが多い組織は見積もり時にドメイン数を精査してもらいましょう。
• 社内に複数のサブドメイン(部門サイト、サービスサイトなど)がある
  → サブドメインが個別課金されにくいPowerDMARCの方がトータルコストを抑えやすい傾向にあります。
• 日本語でのサポート・管理画面が必須
  → PowerDMARCが安心です。
• DMARCポリシーを「p=none」から「p=quarantine/reject」へ引き上げる途中にある
  → DMARCレポート分析が標準搭載のPowerDMARCの方が運用を一本化しやすいでしょう。
• すでにDMARC運用は固まっており、SPFの安定運用だけが課題
  → 機能を絞ったAutoSPFの方がシンプルでコストパフォーマンスに優れる場合があります。

最後に

マーケティングやセールスからの配信ツール追加依頼は、これからも止まらないはずです。そのたびに「今度はどのincludeを消そうか」と悩む必要はありません。

大切なのは次の3段階で考えることです。

1. まず自社の現状(何回のLookupを使っているか)を正しく把握する
2. 「フラット化」と「マクロ化」という技術的な違いを理解した上で、自社の追加ペース・将来性に合った方式を選ぶ
3. その上で、AutoSPFとPowerDMARCのように設計思想の異なるサービスの中から、自社の運用体制に合ったものを選ぶ

もう一つ覚えておいてほしいのは、フラット化・マクロ化のどちらを選ぶ場合でも、自前運用ではなくHost化されたサービスを選べば、自社でDNSを触るのは最初の1回だけで済むということです。

当社(プリモポスト)は、AutoSPFとPowerDMARCの両方を取り扱っており、特定のベンダーに偏ることなく、お客さまの

• メール送信環境
• 組織構成
• 今後の運用計画

に合わせた最適なプランをご提案しています。

「社内からまた依頼が来て困っている」という段階からでも、現状のSPFレコードを確認するところからお気軽にご相談ください。