SPF

1. SPFが策定された背景

【要点】SaaSやサードパーティーのメール配信サービスの普及により、MXレコードだけでは送信元認証が困難になったため、2006年にSPFが策定されました。

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

2000年より前は、メール受信に利用されるMXレコードが、そのままメール送信にも用いられるという単純なシステム構成が一般的でした。
しかし、2000年以降、インターネットが一般家庭や企業に普及すると、メールマーケティングが一般的になり、自社のMXのMTAからのメール送信では、大量のメール送信を捌ききれなくなりました。
そこで、メール送信専用のメール配信サービスの利用が増加し、メールの送信経路が多様化・複雑化しました。

その結果、MXレコードだけでは正当な送信元を十分に認証することが難しくなり、柔軟かつ厳格な送信元認証を実現するためにSPF（Sender Policy Framework）が2006年に策定されました。

1.2. FCrDNSの限界

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

設定ミス

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

偽造可能性

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

認証レベルの限界

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

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

2. SPFの処理プロセス

【要点】SPFは「①送信側がDNSにSPFレコードを公開 → ②送信MTAがHELO/EHLO・MAIL FROMを提示 → ③受信MTAがcheck_host()関数で検証 → ④Pass/Fail等の結果に基づき処理」という流れで動作します。

2.1 SPFレコードの公開

SPFの仕様においては、自社ドメインを送信管理ドメイン（ADMD: Administrative Management Domain）という名称で定義しています。

送信管理ドメインは、自ドメインの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の動作例

【要点】受信MTAは、送信元IPアドレスとDNSに登録されたSPFレコードを照合し、一致すればPass、不一致ならFailと判定します。

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では原則として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レコードは「v=spf1」で始まり、ip4/ip6/include/a/mx等のメカニズムと、+（Pass）/-（Fail）/~（SoftFail）/?（Neutral）の修飾子で構成されます。

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設定

【要点】メール送信を行わないドメインでも、「v=spf1 -all」を設定することで、そのドメインを騙ったなりすましメールを防止できます（Defensive SPF）。

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

6.1. Defensive SPFレコードの設定

v=spf1 -all

6.2 Defensive MXレコードの設定

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

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

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

7. SPFの制限事項

【要点】SPFには①TXTレコード255文字制限、②DNSルックアップ10回制限、③タイムアウト20秒制限があり、これらを超えるとエラーが発生します。

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の限界と注意点

【要点】SPFには、HELO/EHLO認証のみを狙うBypass攻撃、includeのエラー伝播、共用MTA環境での脆弱性など、単独では防げない限界があります。DKIM・DMARCとの併用が推奨されます。

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. 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.4. 共用MTA/MDP環境におけるSPFの脆弱性

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

よくある質問（FAQ）

Q1. SPFはヘッダFromのドメインのSPFレコードを参照するのですか？

A. いいえ、SPFは、SMTPのHELO/EHLOのホストのドメイン名、そしてEnvelopeFromのドメイン名のSPFレコードを参照します。

Q2. メール送信しないドメインはSPF設定は要らないですよね？

A. いいえ、メール送信しないドメインには「v=spf1 -all」を設定することで、そのドメインを騙ったなりすましメールを防止できます。
（Defensive SPF）

Q3. SPFレコードは、メールが届きやすいように、~all(Softfail)に設定するのが良いのでは？

A. いいえ、「~all」（Softfail）は、SPFでの失敗判定となる事に変わりはありません。
失敗判定ではあるものの、受信側MTAの判断で、受信しても良い、という意味です。
そして、Softfailだからといって、受信側MTAがメールを受信することを保証しません。

Q4. DNS Lookup回数は、includeの数を数えればいいですか？

A. includeだけでなく、a、mx、ptr、exists、redirectもDNSルックアップを消費します。
また、includeの中に更にincludeがネスト（内包）されている場合も多く、それらも回数に含める必要があります。
ip4とip6はDNSルックアップを消費しません。

Q5. SPFレコードが複数あるとどうなりますか？

A. 1つのドメインに対してSPFレコード（v=spf1で始まるTXTレコード）は1つだけ許可されています。
複数あるとPermerror（恒久的エラー）となり、認証が失敗します。

Q6. メール転送するとSPFは必ず失敗しますよね？

A. そうとも限りません。
メール転送時に、自社が使っているメール配信プラットフォーム（Gmail/Google Workspace、Microsoft365、SendGrid、AmazonSES、各種レンタルサーバ）から転送されると、SPFのincludeは同じになるため、合格します。
転送サーバのIPアドレスが、自社が使っているメール配信プラットフォームとは異なる場合に、SPF認証が失敗します。

Q7. メール転送なのに、SPFが合格しています。

A. RFCの正式仕様にはなっていませんが、SRS(Sender Rewriting Scheme)という仕組みを実装しているメール配信プラットフォームが多いです。
これは、メール転送時にSPFが失敗するのを防ぐために、転送時にMailFromを転送元のドメインに書き換える仕組みです。
HELO/EHLOでのSPF検証は失敗しますが、MailFrom検証では合格できるというわけです。

Q8. SPF Bypass攻撃とは何ですか？

A. 攻撃者が自分で管理するドメインのSPFレコードを設定し、HELO/EHLOコマンドでそのドメインを提示することで、受信側のSPF検証を突破しようとする手法です。
HELO/EHLO認証とMAIL FROM認証の両方を実施することで対策できます。

Q9. BreakSPF攻撃とは何ですか？

A. 攻撃者がDNSのSPFレコードをクローリングして、どのメール配信プラットフォームを使っているかを洗い出し、そのメール配信プラットフォームの脆弱性を利用する攻撃です。
2025年は、Microsoft365のExchange OnlineのDirect Sendを利用した攻撃が多発しました。
メール配信プラットフォームの脆弱性を利用した攻撃の事例もありました。
SPFマクロによる隠蔽化を設定すれば、対応できます。

Q10. SPFフラットニングとは何ですか？

A. SPFフラットニングは、includeで参照している外部ドメインのSPFレコードを展開し、直接ip4/ip6メカニズムに置き換えることでDNSルックアップ数を削減する手法です。
ただし、参照先のIPアドレスが変更された場合に追従できないリスクがあります。
また、BreakSPF攻撃を防げるわけではありません。

Q11. SPFの運用でDNS応答サイズに関して注意すべき点は？

A. SPFレコードはDNSのTXTレコードとして登録されますが、DNS応答サイズの制限に注意が必要です。
従来のDNS（RFC 1035）ではUDP応答は512バイトまでに制限されています。
Zone APEX（例: example.com）には、SPFレコード以外にもドメイン検証用のTXTレコード（google-site-verification等）が設定されることがあり、これらすべてが1つのDNS応答に含まれます。
応答サイズが大きくなると、以下の問題が発生する可能性があります。

• TC（Truncation）フラグが設定され、TCPでの再クエリが必要になる
• 一部のファイアウォールがDNS over TCP（TCP/53）をブロックしている場合、応答が得られない
• EDNS0で大きなUDPバッファを使用する場合も、経路上のミドルボックスでパケットがドロップされることがある

これらの場合、SPF検証はTempErrorとなり、メールの配信に影響を与える可能性があります。

Zone APEXの不要なTXTレコードを整理し、SPFレコード自体も可能な限り短く保つことで上記の問題に対応できます。

SPFレコード設定手順

【要点】SPFレコードを正しく設定するための手順を、前提条件から検証方法まで解説します。

前提条件

• 対象ドメインのDNS管理権限があること
• メール送信に使用するサーバ・サービスのIPアドレスまたはinclude先を把握していること

入力情報の収集

• 自社メールサーバのIPアドレス（例: 203.0.113.10）
• 利用中のサードパーティーサービスのinclude先（例: _spf.google.com、spf.protection.outlook.com）

設定手順

1. DNSの管理画面にログインする
2. 対象ドメインのTXTレコードを追加する
3. レコード値に v=spf1 ip4:203.0.113.10 include:_spf.google.com -all を入力する
4. TTLを適切に設定する（推奨: 3600秒）
5. 保存してDNS反映を待つ（通常数分〜最大48時間）

出力結果の確認

$ dig TXT example.com +short
"v=spf1 ip4:203.0.113.10 include:_spf.google.com -all"

検証方法

dig/nslookupコマンド

dig TXT example.com でレコードを確認

オンラインツール

ドメインメールセキュリティチェッカー で構文エラーやルックアップ数を検証

テストメール送信

Gmailなどに送信し、メールヘッダの Received-SPF: pass を確認

よくある設定ミスと対策

複数のSPFレコードを登録してしまう

1つのドメインに対してSPFレコードは1つのみ。複数あるとPermerrorになります。

DNSルックアップ数が10回を超える

includeやa、mxメカニズムの数を減らすか、SPFフラットニングを検討します。

末尾に-allを付け忘れる

認証の効果が弱まるため、本番運用では必ず-allを指定します。

SPFの限界を超えるためのDKIM

【要点】SPFはメール転送時に失敗しやすく、ヘッダFromの検証もできません。これらの限界を補完するために、DKIMが登場しました。

SPFには以下のような限界があります。

メール転送時の問題

メールが転送されると、転送サーバのIPアドレスは元の送信ドメインのSPFレコードに含まれていないため、SPF認証が失敗します。

ヘッダFromの検証ができない

SPFはEnvelope FromとHELO/EHLOのドメインを検証しますが、受信者が実際に目にするヘッダFromは検証しません。

メール内容の改竄検知ができない

SPFは送信元IPの検証のみを行い、メール本文やヘッダの改竄は検知できません。

これらの問題に対処するために、DKIM（DomainKeys Identified Mail）が登場しました。
DKIMは、メールに電子署名を付与し、受信側で署名を検証することで、メール内容の改竄検知と送信ドメインの認証を行います。
署名はメール本文に含まれるため、メール転送時にも検証が可能です。

SPFとDKIMを併用し、さらにDMARCでポリシーを適用することで、より強固なメール認証が実現できます。