SPF

SPF（Sender Policy Framework）とは、メールの送信元ドメインが正当なものであるかを検証するための送信ドメイン認証技術です。ドメインの所有者がDNSのTXTレコードにメール送信を許可するIPアドレスやサーバーの一覧を公開し、受信側のメールサーバーがその情報を参照して、送信元の正当性を判定します。なりすましメール（スプーフィング）やフィッシング攻撃への基本的な防御手段として広く利用されています。

SPFの仕組みは、メールのエンベロープFrom（MAIL FROM）に記載されたドメインのDNS TXTレコードを受信サーバーが問い合わせ、送信元IPアドレスが許可リストに含まれているかどうかを確認するというものです。許可されていればSPF Pass、許可されていなければSPF Failとして判定されます。この判定結果は、DMARCやスパムフィルタリングの判断材料としても活用されます。

SPFは導入が比較的容易で、DNS TXTレコードを1行追加するだけで基本的な設定が完了します。しかし、SPFには10回のDNSルックアップ制限や、メール転送時に認証が失敗するといった制約があるため、DKIMやDMARCと組み合わせて多層的なメール認証体制を構築することが推奨されています。

DNS TXTレコードとSPFレコードの構造

SPFレコードは、ドメインのDNS TXTレコードとして公開されます。基本的な書式は「v=spf1」で始まり、その後にメカニズムや修飾子を列挙し、最後に「~all」や「-all」といったデフォルトポリシーで締めくくります。例えば「v=spf1 include:_spf.google.com ip4:203.0.113.0/24 -all」のように記述します。

SPFレコードは1つのドメインに対して1つだけ設定する必要があり、複数のSPFレコードが存在するとPermerror（永続エラー）として処理されます。レコードの文字数はDNS TXTレコードの制限（255文字/文字列、複数文字列で450文字推奨）にも注意が必要です。

SPFメカニズム（include, a, mx, ip4）

SPFレコードでは、送信を許可するサーバーを指定するために複数のメカニズムが用意されています。主要なメカニズムは以下の通りです。

• ip4 / ip6：特定のIPv4またはIPv6アドレス（CIDR表記可）を直接指定。最も明確で推奨される指定方法
• include：別ドメインのSPFレコードを参照。Google WorkspaceやMicrosoft 365などの外部サービスを利用する場合に使用
• a：ドメインのAレコードに登録されたIPアドレスを許可
• mx：ドメインのMXレコードに登録されたメールサーバーのIPアドレスを許可
• exists：指定したドメインのAレコードが存在するかどうかで判定。マクロと組み合わせた高度な設定に使用
• all：すべての送信元に対するデフォルトルール。通常はレコードの末尾に配置

SPF修飾子（Qualifier）

各メカニズムの前に修飾子を付与することで、マッチした場合の処理を指定できます。修飾子を省略した場合は「+」（Pass）として扱われます。

• +（Pass）：送信を許可する（デフォルト）
• -（Fail）：送信を明確に拒否する。最も厳格な設定であり、SPF認証に失敗したメールは拒否される可能性が高い
• ~（SoftFail）：送信を非推奨とする。メールは受け入れるが、スパムフォルダに振り分けられる可能性がある
• ?（Neutral）：判定に関与しない。SPFの検証結果に影響を与えない

10回DNSルックアップ制限

SPFの仕様（RFC 7208）では、1回のSPF認証処理においてDNSルックアップの回数は最大10回に制限されています。この制限は、include、a、mx、exists、redirectなどのDNS問い合わせを伴うメカニズムに適用されます。ip4やip6はDNS問い合わせを行わないためカウントされません。

多数の外部メール配信サービスを利用している場合、includeの連鎖によりこの制限を超過し、PermErrorが発生してSPF認証が失敗することがあります。この問題を回避するには、includeをip4/ip6に置き換える、SPFフラットニング（SPF Flattening）ツールを使用する、サブドメインごとにSPFレコードを分割するなどの対策が必要です。

SPF判定結果の種類

SPF認証の結果は複数のステータスで返されます。Passは送信元IPが許可リストに含まれていることを示し、Failは明示的に拒否されていることを示します。SoftFailは非推奨だが完全な拒否ではないことを意味し、NeutralはSPFレコードが判定に関与しないことを示します。

さらに、NoneはSPFレコードが存在しないこと、TempErrorはDNS問い合わせの一時的なエラー、PermErrorはSPFレコードの構文エラーや10回ルックアップ制限の超過などの永続的なエラーを示します。受信サーバーはこれらの結果に基づいてメールの処理を決定します。

SPFの限界とメール転送問題

SPFにはいくつかの重要な制約があります。最大の課題はメール転送（フォワーディング）です。メールが転送されると、送信元IPアドレスが転送サーバーのものに変わるため、元のドメインのSPFレコードと一致しなくなり、認証が失敗します。

この問題に対処するためにSRS（Sender Rewriting Scheme）が提案されていますが、普及は限定的です。また、SPFはエンベロープFromのみを検証し、ユーザーに表示されるヘッダーFromは検証しないため、表示名の詐称（Display Name Spoofing）には対応できません。これらの制約を補完するために、DKIMとDMARCの併用が不可欠です。

• 01
  厳格なSPFポリシーの設定：SPFレコードの末尾には「-all」（HardFail）を設定し、許可されていないサーバーからのメール送信を明確に拒否してください。導入初期は「~all」（SoftFail）で運用し、影響を確認した後に「-all」に移行するのが安全な手順です。
• 02
  DNSルックアップ数の最適化：includeの連鎖を最小限に抑え、可能であればip4/ip6メカニズムに置き換えてください。SPFフラットニングツールを活用し、DNSルックアップが10回を超えないように定期的に確認しましょう。
• 03
  SPFレコードの定期的な監査：利用しなくなったメール配信サービスのincludeや、不要になったIPアドレスがSPFレコードに残っていないか定期的に確認してください。不要なエントリはセキュリティリスクとなり、ルックアップ数の増加にもつながります。
• 04
  サブドメインのSPF保護：メール送信に使用しないサブドメインにも「v=spf1 -all」を設定し、なりすましに悪用されることを防いでください。攻撃者はSPFが未設定のサブドメインを狙ってフィッシングメールを送信する手口を使います。
• 05
  DKIMおよびDMARCとの併用：SPF単独では十分な保護が得られないため、必ずDKIM（電子署名認証）とDMARC（ポリシー制御）を併用してください。DMARCのアライメント機能により、エンベロープFromとヘッダーFromの整合性も検証できます。
• 06
  SPF認証結果の監視と分析：DMARCの集約レポート（Aggregate Report）を活用して、SPF認証の成功・失敗の傾向を継続的に監視してください。認証失敗が多発している場合は、正規の送信元がSPFレコードに含まれていない可能性があります。