SPF(エスピーエフ)とは | 意味や読み方など丁寧でわかりやすい用語解説

SPF (Sender Policy Framework) は、電子メールの送信元が詐称されていないかを確認するためのメール認証技術の一つである。インターネットを通じて日々大量に送受信される電子メールにおいて、差出人になりすまして送信されるフィッシング詐欺やスパムメールといった悪意のあるメールが後を絶たない。SPFはこのようなメールの脅威に対抗し、メールの信頼性と安全性を高めることを目的としている。具体的には、メールの送信元IPアドレスが、そのメールのエンベロープFrom（Return-Path）ドメインの正当な送信サーバーとして登録されているかを検証する仕組みを提供する。受信側のメールサーバーがこの検証を行うことで、不正なサーバーからのメールを拒否したり、スパムとして分類したりすることが可能になる。これにより、ユーザーはより安全なメール環境を利用でき、ドメイン所有者は自身のドメインが悪用されるリスクを低減できる。

SPFの機能は、DNS（Domain Name System）に公開されるSPFレコードに依存する。SPFレコードは、特定のドメインがメールを送信するために許可するIPアドレスやホスト名を記述したDNSのTXTレコードである。メールを送信する側のドメイン管理者は、自身のドメインからメールを送信することを許可するすべてのメールサーバーの情報をこのSPFレコードに記述し、DNSサーバーに公開する。

SPFレコードの基本的な構文は「v=spf1」で始まり、その後にメール送信を許可する様々な「メカニズム」が続く。主要なメカニズムには、以下のようなものがある。 a: 送信ドメインのAレコード（IPアドレス）と一致するサーバーを許可する。例えば、example.comのSPFレコードにaが含まれていれば、example.comのAレコードが指すIPアドレスからのメールは許可される。 mx: 送信ドメインのMXレコード（メールエクスチェンジャー）として設定されているサーバーを許可する。これは通常、そのドメインのメールを受信するサーバーを指す。 ip4 / ip6: 特定のIPv4またはIPv6アドレス、あるいはCIDR形式のネットワークアドレスを許可する。例えば、ip4:192.0.2.1は特定のIPアドレスを、ip4:192.0.2.0/24は指定された範囲のIPアドレスを許可する。 ptr: 送信元IPアドレスのPTRレコード（逆引きDNSレコード）が、送信ドメインと一致する場合に許可する。ただし、ptrメカニズムはDNSルックアップの負荷が高く、誤判定のリスクがあるため、現在では非推奨とされている。 include: 他のドメインのSPFレコードを参照し、そのドメインが許可するサーバーも自ドメインの許可対象に含める。例えば、クラウドメールサービスを利用する場合、include:_spf.google.comのように記述することで、Googleのメールサーバーも正当な送信元として認められる。 exists: 指定したドメインのAレコードが存在する場合に許可する。これはより高度な用途で用いられる。 all: すべての送信元に適用される。通常はSPFレコードの最後に記述され、その前のメカニズムで許可されなかった送信元に対するポリシーを定義する。

allメカニズムには、ポリシーを決定する「クオリファイア」を付加する。 +all (Pass): すべての送信元を許可する。これはSPFを実質的に無効化するため、使用は推奨されない。 -all (Fail): SPFレコードで明示的に許可されていないすべての送信元からのメールを拒否するよう要求する。最も厳格な設定であり、なりすまし対策として強く推奨される。このポリシーのメールは、受信側でほとんどの場合拒否されるか、隔離される。 ~all (SoftFail): SPFレコードで許可されていない送信元からのメールは疑わしいものとして扱うが、直ちに拒否はせず、スパムとしてマークするなど比較的寛容な処理を推奨する。このポリシーのメールは、スパムフォルダに振り分けられることが多い。 ?all (Neutral): SPFレコードが、送信元が許可されているか否かについて明確な判断を示さない。事実上、SPF認証を適用しないのと同義である。

メールを受信する側のメールサーバーは、メールを受け取ると、まずそのメールのエンベロープFromアドレス（SMTPトランザクションのMAIL FROMコマンドで指定されるアドレス）のドメイン名を特定する。次に、そのドメインのDNSサーバーに問い合わせを行い、SPFレコードを取得する。取得したSPFレコードに記述されているメカニズムと、実際にメールを送信してきたサーバーのIPアドレスを照合する。この照合の結果に基づいて、受信側サーバーはSPF認証の結果を判断する。

SPF認証の結果には、主に以下の種類がある。 Pass: 送信元のIPアドレスがSPFレコードで許可されている範囲内であり、正当な送信元と判断された場合。メールは通常通り配信される。 Fail: 送信元のIPアドレスがSPFレコードで明示的に許可されていない場合。通常は-allポリシーが適用されている。この場合、受信側サーバーはメールを拒否したり、隔離したりする可能性が高い。 SoftFail: 送信元のIPアドレスが許可されていないが、-allのような厳格な拒否ポリシーが適用されていない場合（通常は~all）。疑わしいメールとして扱われ、スパムフォルダに振り分けられることが多い。 Neutral: SPFレコードが、送信元が許可されているか否かについて明確な判断を示さない場合（?allポリシー）。受信側はSPF以外の要素で判断を行う。 None: 送信ドメインにSPFレコードが存在しない場合。SPF認証が行えないため、受信側はSPFに関する判断をしない。 TempError: SPFレコードの処理中に一時的なDNSエラーが発生した場合。一時的な問題のため、受信側は再試行するか、SPF認証を保留することがある。 PermError: SPFレコードの構文が間違っている、複数のSPFレコードが存在する（これはRFCに違反する）、またはDNSルックアップが多すぎるなど、恒久的なエラーがある場合。この場合、SPF認証の結果は信頼できないものとなる。

SPFは非常に有効な技術だが、いくつかの限界も存在する。一つは、メール転送の問題である。メールが転送されると、元の送信元のIPアドレスではなく、転送サーバーのIPアドレスから受信側に届くため、SPF認証がFailとなることがある。もう一つ重要なのは、SPFが保護するのはエンベロープFromアドレスであり、ユーザーがメールクライアントで目にする「From:」ヘッダーアドレスではない点である。ヘッダーFromアドレスは、通常、メールの本文に記載され、エンドユーザーが誰からメールが来たかを確認する際に参照するアドレスである。このため、ヘッダーFromアドレスを偽装しつつ、エンベロープFromアドレスを正当なものにするタイプのなりすましに対しては、SPFだけでは不十分な場合がある。

これらの限界を克服し、より強固なメール認証を実現するために、DKIM（DomainKeys Identified Mail）やDMARC（Domain-based Message Authentication, Reporting, and Conformance）といった他のメール認証技術と併用することが強く推奨される。DKIMは電子署名によってメールの改ざんを検出し、メールの正当性を確認する。DMARCはSPFとDKIMの認証結果に基づいて、メールの処理ポリシー（拒否、隔離、なし）を受信側に指示し、認証結果のレポート機能を提供する。これらの技術を組み合わせることで、ドメインの信頼性を多角的に保護し、より広範囲ななりすましやフィッシング攻撃からユーザーを守ることができる。

SPFレコードを設定する際の注意点として、DNSルックアップの回数制限がある。RFC 7208では、SPFレコードの処理中に発生するDNSルックアップの合計回数を10回までに制限している。a, mx, ptr, exists, includeメカニズムはそれぞれ1回とカウントされ、この制限を超えるとPermErrorが発生し、SPF認証が正しく行われなくなる。また、1つのドメインに対して複数のSPFレコードを公開してはならない。複数のSPFレコードが存在すると、受信側がどのレコードを参照すべきか判断できず、PermErrorとなる。ドメイン管理者は、自身のドメインのメールが正しく認証され、安全に配信されるよう、適切なSPFレコードを設定し、継続的に管理することが求められる。