1. SPFが策定された背景

昔は、メール受信に利用されるMXレコードが、そのままメール送信にも用いられるという単純なシステム構成が一般的でした。
しかし、近年ではSaaSの利用や他社のメール配信サービスを通じた送信が増加し、メールの送信経路が多様化・複雑化しています。
その結果、MXレコードだけでは正当な送信元を十分に認証することが難しくなり、柔軟かつ厳格な送信元認証を実現するためにSPF（Sender Policy Framework）が策定されました。

1.1. MXレコードだけでは認証が困難になった

SaaSや他社のメール配信サービスの利用が拡大する中、メール送信の経路は自社のメールサーバーだけでなく、サードパーティーのMTAを経由するケースが増えました。
そのため、メールサーバの正当性をMXレコードのみで担保することができなくなり、SPFレコードでは自社ドメインに加え、サードパーティーのMTAのIPアドレスや、他ドメインのSPFレコードをincludeすることで、多様な配信環境に対応できる仕組みが求められるようになりました。

1.2. FCrDNSの限界

FCrDNS（Forward-confirmed reverse DNS）は、IPアドレスの逆引きと正引きを確認する手法です。
昔は、MXレコードが主にメール送信に利用されていたため、逆引きDNSを確認する手法はスパム対策として有効でした。
しかし、現在ではメール送信環境が多様化しており、以下のような問題点が指摘されています。

設定ミス

正確なDNS設定が求められるため、誤った設定の場合、正当なメールが誤ってブロックされる可能性があります。

偽造可能性

逆引きDNSのエントリは、攻撃者により偽装されるリスクがあるため、必ずしも信頼性の高い検証手法とは言えません。

認証レベルの限界

逆引きDNSはIPアドレスレベルの確認に留まり、送信者のドメインや個々のアカウントを細かく制御することが困難です。

これらの理由から、より柔軟かつ厳格な送信元認証を実現するために、SPFが策定されたのです。

2. SPFの処理プロセス

2.1 SPFレコードの公開

送信管理ドメイン（ADMD）は、自ドメインのDNSにTXTレコード形式でSPFレコードを公開します。
SPFレコードには、許可された送信元IPアドレスやホスト、さらに他のドメインのポリシーを参照する「include」や「redirect」などのメカニズムが含まれます。
受信側が否定的な判断を下すためには、レコード末尾に-all（完全な拒否）を指定することが推奨されます。

2.2 送信時のアイデンティティ

送信MTAは、SMTPセッション開始時にHELOまたはEHLOコマンドで自身のホスト名を提示します。
また、SMTPのMAIL FROMコマンドにより送信者のエンベロープアドレスが指定されます。
SPF検証の際は、基本的にMAIL FROMのドメインが対象となります。
ただし、MAIL FROMがnullの場合は、RFC5321の規定に従い、HELO/EHLOで提示されたホスト名を元に、「postmaster@<HELOのドメイン>」という形式の送信者が使用されます。

2.3 受信側でのSPFチェック

受信MTAは、メール受信時に以下の手順でSPFチェックを実施します。

チェックの実施タイミングと場所

SPFチェックは、SMTPトランザクション中のMAILコマンド処理時に実施されます。
送信者としては、MAIL FROMにより指定されたドメイン（または、MAIL FROMがnullの場合はHELO/EHLOに基づいて合成された「postmaster@<HELOのドメイン>」）が対象となり、送信元IPとの整合性が評価されます。

使用する関数：check_host()

RFC7208で定義されたモデル関数check_host()を使用し、対象のアイデンティティ、送信元IP、DNSから取得したSPFレコードを評価します。

2.4 SPF評価結果

check_host()の評価により、以下の結果が得られます。

None

有効なドメイン名が抽出できない、またはDNSからSPFレコードが取得できなかった場合。

Neutral

ドメイン所有者が認可に関して明示的な主張を行っていない場合。

Pass

SPFレコードにより、送信元IPが正当と明示的に認可されている場合。

Fail

SPFレコードにより、送信元IPが明示的に拒否されている場合。

Softfail

弱い拒否設定（例：~all）で、通常は迷惑メールとして扱われる場合。

Temperror

一時的なDNSエラーなどによりチェックが完了しなかった場合。

Permerror

SPFレコードの解釈エラーなど、恒久的なエラーが発生した場合。

2.5 受信側での処理アクション

SPFチェックの結果に基づき、受信MTAは以下のアクションを実施します。

Pass

通常通りメールを受信・転送。

Fail/Softfail

メールを拒否する、または迷惑メールフォルダへ振り分ける。

Temperror

一時的なエラーとして再試行や保留処理を実施。

Permerror

DNS管理者への通知など、エラー解消のための措置が必要。

None/Neutral

他の認証技術（例：DKIM、DMARC）との併用や、受信側ローカルポリシーに基づく最終判断に委ねる。

3. SPFの動作例

SPFの動作を具体的に示すため、以下の例では、example.comの正しいMTAのIPアドレスが113.149.170.222としてDNSのTXTレコードに登録されているとします。
メール送信時、受信MTAは、送信MTAから送信時に提供されたHELO/EHLOコマンドのホスト名を基にDNSルックアップを実施し、example.comのSPFレコードを参照して、メールが正しいMTAから送信されたかどうかを検証します。

もし悪意のある送信者が、support@example.comというアドレスを偽装し、別のIPアドレス（例：122.197.157.64）のMTAを使用してメールを送信した場合、受信サーバは、送信MTAから提供されたHELO/EHLOのホスト名を基にDNSルックアップを実施し、example.comのDNSに登録されたSPFのTXTレコードを確認します。
その結果、送信に使用されたIPアドレスが一致しないため、メールは正規のMTAから送信されたものではないと判断されます。

4. SPF認証におけるHELO/EHLO認証とMail From認証の違い

SPF認証では、SMTPセッション開始時に送信者が提示するHELO/EHLO認証が原則として優先され、決定的な結果が得られた場合はその結果に基づき認証が完結します。
HELO/EHLO認証で十分な結果が得られない場合や、情報が不十分な場合に限り、Mail From認証（エンベロープ送信者のドメインに基づく認証）が補完的に実施されます。

HELO/EHLO認証

SMTPセッション開始時に提示されるホスト名を基に、送信元サーバー自体の正当性を確認します。
DNSリソースの消費が少なく、迅速かつ決定的な認証が可能であるため、原則として最初に実施されます。

Mail From認証

MAIL FROM（エンベロープ送信者）のドメインに基づいて送信者の正当性を検証します。
HELO/EHLO認証で決定的な結果が得られない場合に補完的に利用され、より正確な送信者ドメインの検証を行います。

以上の通り、通常はHELO/EHLO認証が優先され、必要に応じてMail From認証が補完的に利用されるため、SPF全体としてはHELO/EHLO認証が基本となります。

RFC7208 のセクション 2.3「The 'HELO' Identity」では、SPF検証者はSMTPセッション開始時に送信側が提示するHELO/EHLOのホスト名をチェックすることがRECOMMENDEDとされています。
また、セクション 2.4「The 'MAIL FROM' Identity」では、HELO/EHLOのチェックが行われなかった、または決定的な結果が得られなかった場合に限り、MAIL FROMの認証を必ず実施する必要があると記載されています。

すなわち、原則としてはHELO/EHLO認証が優先され、決定的な結果が得られればその結果に基づいてSPF認証が完了します。
しかし、運用上の選択肢として、両方の認証（HELO/EHLO認証とMail From認証）を強制的に実施するように設定することも可能です。
この方法では、攻撃者が一方（例えば、SPF Bypass攻撃のようにHELO/EHLO のみ）の情報を操作してSPFをバイパスするリスクを大幅に低減でき、より堅牢なメール認証が実現されます。

なお、RFC7208自体には「両方の認証を必ず強制しなければならない（MUST）」という記述はなく、あくまで運用上の推奨事項および実装の選択肢として示されているため、各運用環境に合わせた設定が求められます。

5. SPFの構文

SPFレコードはTXTレコードとしてDNSに登録され、基本構文は以下の通りです：

v=spf1 [mechanisms] [qualifiers]

ここで、v=spf1はSPFのバージョンを示し、続く[mechanisms]と[qualifiers]で送信元の評価ルールを指定します。

5.1 SPFメカニズム

SPFレコードでよく使用されるメカニズムには、以下のものがあります。

all

すべての送信元を意味する。

a

ドメインのAレコードにマッチする送信元。

mx

ドメインのMXレコードにマッチする送信元。

ip4

指定されたIPv4アドレスまたは範囲にマッチする送信元。

ip6

指定されたIPv6アドレスまたは範囲にマッチする送信元。

include

他ドメインのSPFレコードを参照する。

5.2 修飾子

各メカニズムには、次の修飾子が使用され、評価結果を指定します。

+

Pass（通過）

-

Fail（拒否）

~

SoftFail（弱い拒否）

?

Neutral（中立）

5.3 SPFマクロ

SPFマクロを利用することで、変数展開を行い柔軟なポリシー設定が可能です。

%{s}

送信者のドメイン

%{l}

送信者のローカル部分

%{d}

評価中のSPFドメイン

%{i}

送信者のIPアドレス

%{p}

検証されたドメイン名

%{v}

IPアドレスのバージョン（IPv4またはIPv6）

%{h}

送信メールのHELO/EHLOドメイン

例として、以下のSPFレコードは、ドメイン名を小文字に変換して参照する設定です。

v=spf1 include:%{d|lower}._spf.example.com -all

6. メール送信しないドメインでのSPF設定

キャンペーンサイトや防御用に取得したドメインなど、メール送信を行わない場合でもSPF設定が必要です。
SPFレコードに-allを指定することで、そのドメインからのメール送信は全て拒否されることを示します。

6.1. Defensive SPFレコードの設定

v=spf1 -all

6.2 Defensive MXレコードの設定

また、MXレコードも以下のように設定することで、そのドメイン宛のメール受信を防止できます。

Type: MX 
Preference: 0
Host: @
Value: .

これはNull MXレコードとして、RFC7505で定義されています。

7. SPFの制限事項

7.1 文字数制限

各TXTレコードは最大255文字までの制限があるため、SPFレコードが長くなる場合はincludeを使用して分割する必要があります。

7.2 DNSルックアップ数制限

SPFレコード内でのDNSルックアップは10回までと定められており、これを超えるとSPF permanent errorが発生します。
SMTPでは550番エラーが返されるため、DNS設定の管理に注意が必要です。

7.3 タイムアウト

受信サーバーはDNSからの応答を最大20秒間待機し、タイムアウトするとSPFはTempErrorと評価されます。
これにより、DKIMやDMARCなど追加の認証処理が行われる場合があります。

8. SPFの限界と注意点

8.1. SPF Bypass攻撃

SPF Bypass攻撃は、主にHELO/EHLO認証のみが利用されている場合に、攻撃者が自分で管理するドメインのSPFレコードを都合よく設定し、SMTP送信時にHELOコマンドでそのドメインを提示することで、受信側のSPF検証を突破しようとする手法です。
つまり、もし受信側がHELO/EHLO認証のみで認証を完結させている場合、攻撃者はMAIL FROMの検証を回避でき、正当なメール送信と誤認されるリスクがあります。

8.2. 一部のincludeのエラーがSPF構文全体をエラーにする

SPFレコードでは、サードパーティーのサービスのためのincludeなどを利用することが一般的です。
しかし、これらのうち1つでもDNS問い合わせが失敗（Temperror）や、文法上のエラー（Permerror）を返した場合、RFC7208 Section 5.2 "include"に記載があるとおり、SPF検証全体がエラーとなり、認証が成立しなくなります。
そのため、参照先のドメインのSPFレコードが正しく記述され、かつDNSルックアップが正しく応答するかを定期的に確認する必要があります。

8.3. 一部のincludeでSoftfailとなると、全体が抜け穴になる

自社ドメインではHardfail (-all)で厳格に運用していても、includeで参照しているサードパーティーのSPFレコードがSoftfail (~all)の場合、その部分だけは緩やかに評価されます。
これにより、攻撃者がその弱点を突く可能性があり、結果として全体の認証強度が低下するリスクがあります。

8.4. Void Lookupの制限（実装依存）

SPFレコード評価時には、DNSルックアップの総数が10回に制限されていますが、さらに一部の実装では、問い合わせ結果が空（＝Void Lookup）となった場合の回数に個別の制限（例：2回まで）を設けている場合があります。
そのため、SPFマクロやその他のメカニズムによってVoid Lookupが2回を超えると、以降の評価が行われず、その部分が無視される、または全体の評価に影響を与える可能性があります。
※この制限はRFC7208の標準仕様ではなく、実装依存の動作となるため、使用しているMTAやSPFライブラリの仕様を確認する必要があります。

• 1つめのSPFマクロ exists: %{i}.spf.maildeliverservice.com
• 2つめのSPFマクロ exists: %{i}.spf.marketingautomation.com
• 3つめのSPFマクロ exists: %{i}.spf.transactionmail.com ←評価されない

8.5. 共用MTA/MDP環境におけるSPFの脆弱性

共用MTAやメール配信プラットフォーム（MDP）を利用している場合、SPFの効果が十分に発揮されないケースがあります。
例えば、共用のMTAでは複数の利用者が同一の送信IPアドレスを共有しているため、そのIPアドレスがSPFレコードに登録されていれば、悪意のある利用者が同じIPアドレスを使ってなりすましメールを送信するリスクが高まります。
また、MDPの場合、利用者全体で同じSPF設定（たとえば同一のinclude設定）が適用されるため、攻撃者がそのMDPのアカウントを取得すれば、正規のSPF認証を通過するなりすましメールの送信が可能になる懸念があります。