SPF（Sender Policy Framework）を痛い目に遭って学びました—金曜日の午後に本番ドメインの設定をsoftfailからhardfailに切り替えたら、メールの流れが一気に消えてしまったのです。実は、数か月前に設定したイベントプラットフォームのことを忘れていたのです。その失敗から学んだ重要なことは、SPFレコードに手を加える前に、自分のメールがどこから送信されているのかをすべて把握し、間違えた場合の結果を受け入れる覚悟を持つことです。

ここで本当に重要なポイントを解説します。SPF（Sender Policy Framework）は、あなたのドメインが受信サーバーに対して、「こちらが正当な送信元です」と伝える仕組みです。具体的には、DNSのTXTレコードに、どのホストが正当にメールを送信できるかをリストします。メールが届くと、受信側はあなたのSPFレコードを返送ドメイン（Return-Pathドメイン）と照合し、mechanism（ip4、ip6、a、mx、include）を評価し、どう処理するかを決定します。この判断は、最後に付けるqualifier（修飾子）—モード次第です。

ここで人々を混乱させる核心的な違いがあります。softfail（~all）は、「これは許可されていないようだけど、もしかしたら問題ないかもしれない—注意して進めてください」という意味です。通常はスパムフィルタリングのトリガーになり、完全に拒否されることは少ないです。一方、hardfail（-all）は、「リストしたホストだけが正当な送信元です—それ以外はすべてブロックします」という厳格な設定です。これは決定的であり、DMARCと組み合わせると、実際にメッセージの拒否が行われます。

これを、ステージングと本番環境に例えるとわかりやすいです。softfailは、まだ調整中の慎重なステージングモードです。hardfailは、本番でブレーカーを落とし、その結果を受け入れる覚悟を持つ状態です。

私が実践している方法は、段階的に進めることです。まずは`?all`で純粋に観察し、次にDMARCの集計レポートを見ながらsoftfail（~all）に切り替え、最終的にすべての正当な送信者を検証し、誤検知がほぼゼロになった段階でhardfail（-all）に切り替えます。焦らずに進めるのが基本です。すべてをリストアップし、CRM、マーケティング自動化、チケッティング、HR、請求、さらにはプリンターのような奇妙なものまで確認します。DKIMやDMARCの整合性をサポートしているベンダーも確認し、変更点の所有者を記録します。

早くやってしまいがちな落とし穴の一つは、SPFのDNSルックアップ制限が10回であることです。多くの人は、includeを深くネストさせすぎて、その制限に引っかかり、すべてが壊れてしまいます。includeを減らし、IPレンジを優先し、不要なサービスを整理しましょう。大量送信者がIPを頻繁にローテーションしている場合は、SLA付きの安定したincludeを推奨します。

転送（フォワーディング）も注意点です。これにより、送信元IPが変わるため、SPFが壊れます。もしフォワーダーがSRS（Sender Rewriting Scheme）を使っているなら問題ありませんが、そうでなければsoftfailが唯一の防御策となる場合もあります。こうしたケースでは、DKIMやDMARCの整合性に頼る方が安全です。

私が長年洗練させてきた実践的なロールアウトのチェックリストは次の通りです：すべてのメールサーバーとワークフローをマッピングし、すべての場所でDKIMを検証し、テレメトリーのためにDMARCをp=noneで有効化し、SPFをsoftfail（~all）に設定して少なくとも2回の送信サイクルを観察し、未承認の送信者を調査して承認するかフローを停止し、最後にDMARCの強制とrejectポリシーを段階的に導入します。最終段階は、正当な送信者のカバレッジが完全になったときだけ、hardfailに切り替えることです。これが絶対条件です。

もう一つ気づいた点は、GoogleやYahooが規制をかなり強化していることです。メールポリシーの適用は、SPFモード、DKIM署名、DMARCポリシー、コンテンツ分析、レピュテーションスコアを組み合わせたものになっています。だからこそ、SPFだけを孤立させて考えないことが重要です。SPFのhardfailだけでは、しばしばフォワーディングが多い環境では配信に支障をきたすこともあります。

人々が犯しやすい最大の落とし穴は、includeをネストさせすぎて10回のルックアップ制限を超えること、季節的なベンダーがあなたのドメインでメールを送ることを忘れること、DMARCだけが壊れたSPF設定を救うと誤信すること、softfailを永遠に頼り続けて攻撃者に適応されること、またはDKIMがすべてに行き渡る前にhardfailに切り替えることです。特に後者は、セキュリティには良いですが、フォワーディングが多い場合の配信性には大きな悪影響を及ぼします。

もし今、softfailの状態で切り替えを迷っているなら、答えは「準備が整ったときだけ」です。すべての送信者を検証しましたか？DKIMは整合していますか？誤検知はほぼゼロですか？これらすべてに「はい」なら、hardfailに進むのが理にかなっています。そうでなければ、焦らず待ちましょう。softfailは永遠の状態ではなく、あくまで通過点です。