SPF生成ツール

自社ドメインで送信するサービスをすべて洗い出します。メールボックスプロバイダー（Google WorkspaceまたはMicrosoft 365）、マーケティング、トランザクションメール、CRM、ヘルプデスク、自社のメールサーバーなどです。それぞれに公式のSPFメカニズムがあり、通常はincludeです。生成ツールでそれらを選び、それ以外の送信元の扱い（最初は~all）を選んで、ドメインのルートにTXTレコードとして公開します。難しいのは構文ではなく、全サービスを漏れなく把握することです。漏れはDMARCの集計レポートで見つかります。

いいえ。SPFの規格では1つだけと定められています。受信側がv=spf1のTXTレコードを2つ見つけるとpermerrorとなり、どちらも事実上無視されます。レコードがない場合より悪い状態です。すでにSPFレコードがある場合は、新しいメカニズムをそこに統合します。先頭のv=spf1は1つにし、includeとipのメカニズムをまとめ、末尾のall修飾子も1つにします。

受信側は、DNSルックアップが10回に達するとSPFレコードの評価を止めます。それを超えるとpermerrorとなり、メールボックスプロバイダーは失敗として扱います。a、mx、include、exists、redirect、ptrの各メカニズムはそれぞれ1回のルックアップを使い、include内でさらにルックアップが発生することも多いため、includeを6つ並べたレコードが気づかないうちに上限を超えることがあります。ip4とip6は回数に含まれないため、長すぎるレコードの対処は通常、includeをプロバイダーが公開するIP範囲に置き換えるか、フラット化サービスを使うことです。

メールを送信するドメインなら~all、まったく送信しないドメインだけ-allを使います。~all（softfail）は、未登録の送信元を受け入れつつ印を付けるよう求めます。-all（hard fail）は即座に拒否させるため、正規の転送メールまで拒否されます。DMARCのポリシーを強化した後は、なりすまし対策としての効果はどちらも同じです。送信するドメインでは、~allは-allへの途中段階ではなく最終形です。時間をかけて強化するのはDMARCポリシーのほうです。?allは避けてください。意見なしと同じで保護効果はなく、管理が行き届いていない印象を与えます。

Google Workspaceはinclude:_spf.google.com、Microsoft 365はinclude:spf.protection.outlook.comを公式に案内しています。どちらもincludeは1つで、この生成ツールに組み込み済みです。GoogleやMicrosoftが送るメールはこの1つですべて対象になるため、個別のサーバーIPは不要です。マーケティングやトランザクションメールのサービスでも送信する場合は、そのincludeを同じレコードに加えます。2つ目のレコードは作りません。

いいえ。意外に思われるかもしれません。SPFが検証するのは隠れたエンベロープ送信者（Return-Path）で、受信者に表示されるFromアドレスではありません。そのため攻撃者は、自分のドメインでSPFに合格しながら、Fromには自社ドメインを表示できます。この穴を塞ぐのがDMARCです。SPFで検証されたドメインと表示上のFromドメインの一致を求め、失敗したメールを拒否するよう受信側に指示できます。SPFを公開し、DKIMとDMARCポリシーを追加してください。なりすましを実際に防ぐのは、この3つの組み合わせです。

v=spf1 -all、つまり何も許可しないレコードです。メールを送信しないドメインは誰も監視していないため、なりすましの格好の標的です。メールボックスプロバイダーも、こうしたドメインにはすべてを拒否するSPFの公開を明確に推奨しています。生成ツールでパーキングドメインにチェックすると作成でき、p=rejectのDMARCレコードと組み合わせれば完全に封鎖できます。

共有のSPF includeを使わないサービスも増えています。たとえばKlaviyo、HubSpot、Mailchimp Transactional（Mandrill）、Constant Contact、SparkPostは、管理画面で生成されるCNAMEレコードやアカウント固有の値で認証します。こうしたサービスに汎用のincludeを追加しても効果はありません。プロバイダーのドメイン認証またはDNS設定のページを確認してください。include値が示されていれば上の「他のinclude」欄に貼り付け、CNAMEレコードが示されていればそれを公開し、SPFはそのままにします。

SPFチェックにかけてください。公開中のレコードを取得して構文を検証し、DNSルックアップ数を数え、レコードの重複や解決できないincludeなどの問題を指摘します。次にGmailのアドレスにテストメールを送り、「メッセージのソースを表示」でspf=passを確認します。すべての送信サービスについて継続的に確かめるには、DMARCの集計レポートで、世界中の受信側から見たSPFの結果を確認できます。