Webエンジニア向けプログラミング解説動画をYouTubeで配信中!
▶ チャンネル登録はこちら

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

SPFレコード(エスピーエフ レコード)の意味や読み方など、初心者にもわかりやすいように丁寧に解説しています。

作成日: 更新日:

読み方

日本語表記

エスピーエフレコード (エスピーエフレコード)

英語表記

SPF record (エスピーエフ レコード)

用語解説

SPFレコードとは、電子メールの送信元が詐称されていないかを検証するための認証技術の一つであり、Domain Name System(DNS)に登録される特殊なレコードである。これは、フィッシング詐欺やスパムメールといった悪意のあるメール送信者が、あたかも正規の送信者であるかのように見せかける「メールのなりすまし」を防ぐために非常に重要な役割を果たす。メールを受信するサーバーは、届いたメールの送信元IPアドレスと、送信元ドメインのSPFレコードに記載された情報を照合することで、そのメールが本当にそのドメインから送信されたものなのかを確認できる。もしSPFレコードが正しく設定されていなければ、正規のメールであっても受信側で迷惑メールと判断されてしまったり、最悪の場合ブロックされてしまったりする可能性がある。システムエンジニアを目指す上では、メールシステムの安定運用やセキュリティ対策において、SPFレコードの理解は不可欠である。

メールのやり取りにおいて、送信元のアドレス(Fromヘッダ)は簡単に偽装できてしまうという根本的な問題がある。例えば、実在する銀行や有名企業を騙るフィッシングメールは、この特性を悪用して受信者を騙そうとする。SPF(Sender Policy Framework)はこの問題に対処するため、メール受信側が送信元の正当性を確認できるようにする仕組みを提供する。具体的には、メールの受信サーバーが、受信したメールのエンベロープFromアドレス(メール配送経路で使われる送信元アドレス)からドメイン名を特定し、そのドメインのDNSに問い合わせてSPFレコードを取得する。

SPFレコードは、DNSのTXTレコードとして記述され、そのドメインからのメール送信を許可するIPアドレスやホスト名を明確に定義している。例えば、「このドメインからのメールは、特定のIPアドレスを持つサーバーか、特定のサービスが提供するサーバーからのみ送信されるべきだ」というポリシーを宣言する。SPFレコードの記述は、v=spf1で始まり、その後に送信を許可するIPアドレスやドメイン、そして最後に、ポリシーに一致しない場合の挙動を定義する部分が続く。

具体的な記述例をいくつか挙げる。 v=spf1 ip4:192.0.2.1 -all この例は、「バージョンはSPF1であり、IPアドレス192.0.2.1からのメール送信を許可する。それ以外のIPアドレスからのメールはすべて拒否する」という意味になる。 v=spf1 include:_spf.example.com ~all この例は、「バージョンはSPF1であり、_spf.example.comという別のドメインのSPFレコードに定義されている送信元を許可する。それ以外のIPアドレスからのメールは、ソフトフェイル(疑わしいが拒否しない)として扱う」という意味になる。 includeメカニズムは、Google WorkspaceやMicrosoft 365などの外部のメールサービスを利用している場合に特に重要となる。これらのサービスは自社のメールサーバーではなく、サービスの提供するサーバーからメールを送信するため、そのサービスのSPFレコードを参照するよう設定する必要があるからだ。

SPFレコードの記述における主要な要素には以下のようなものがある。

  • v=spf1: SPFレコードのバージョンを示す。現在はほとんどがSPF1である。
  • ip4: / ip6:: 指定されたIPv4アドレスまたはIPv6アドレスからの送信を許可する。
  • a: ドメインのAレコードで解決されるIPアドレスからの送信を許可する。
  • mx: ドメインのMXレコードで解決されるIPアドレスからの送信を許可する。
  • ptr: 送信元IPアドレスのPTRレコードがドメイン名と一致する場合に許可する。現在ではセキュリティ上の理由から非推奨とされている。
  • include:: 指定されたドメインのSPFレコードを参照し、そのポリシーを適用する。
  • exists:: 指定されたドメインが存在する場合に許可する。
  • redirect=: このドメインのSPFレコードの代わりに、指定されたドメインのSPFレコードを使用する。
  • all: 最後に記述され、これまでに定義されたどのメカニズムにも一致しなかった場合のデフォルトの挙動を定義する。

allの前に付く修飾子(qualifier)は、メールがSPFレコードの定義と一致しなかった場合の受信サーバーの挙動を指示する。

  • + (Pass): 明示的に許可する。デフォルトのため省略可能である。一致すれば正規のメールとして扱う。
  • - (Fail): 不一致の場合、そのメールを拒否するよう強く推奨する。最も厳格な設定であり、なりすましメールのブロックに効果的だが、設定ミスがあると正規メールも拒否されるリスクがある。
  • ~ (SoftFail): 不一致の場合でも、メールを拒否せず、疑わしいメールとしてマークするよう推奨する。一時的な問題やテスト期間中に用いられることが多い。
  • ? (Neutral): 不一致の場合、特に判断しない。SPFチェックを行わないのと同義に近い。

受信側のメールサーバーは、これらの情報に基づいてSPF認証を実行し、結果を記録する。そして、その結果に応じてメールを通常通り受信するか、迷惑メールフォルダに振り分けるか、あるいは完全にブロックするかを決定する。企業や組織が自社のドメインでメールを送信する場合、そのドメインのSPFレコードを正しく設定することが、自社から送信されたメールが受信側で迷惑メールと判断されるのを防ぎ、メールの信頼性を高める上で非常に重要となる。

SPFレコードを設定する際の注意点として、一つのドメインに対して複数のSPFレコードを登録してはいけないというルールがある。複数のSPFレコードが存在すると、受信サーバーはどのレコードを適用すべきか判断できず、SPF認証が失敗する原因となる。また、includeメカニズムを多用しすぎると、DNSルックアップの回数が規定値(通常10回)を超えてしまい、SPF認証がエラーとなる「PermError」が発生することがある。そのため、外部サービスを追加する際には、既存のSPFレコードを見直し、適切に統合する必要がある。自社のメールサーバーだけでなく、メルマガ配信サービス、クラウドベースのメールサービス、その他メールを送信する可能性のある全てのシステムやサービスを網羅し、それらの送信元IPアドレスやドメインがSPFレコードに正しく含まれているかを確認することが極めて重要である。

SPFは、メールのなりすまし対策として効果的だが、それ単体では完璧な対策とは言えない。なぜなら、SPFはメールのエンベロープFromアドレスを保護するものの、受信者が目にするFromヘッダアドレス(表示名)の詐称までは防げないためである。このため、SPFはDKIM(DomainKeys Identified Mail)やDMARC(Domain-based Message Authentication, Reporting & Conformance)といった他のメール認証技術と組み合わせて利用されることが一般的である。DKIMは電子署名によってメールの内容が改ざんされていないことと送信元ドメインの正当性を証明し、DMARCはSPFとDKIMの認証結果に基づいて、受信サーバーがメールをどう処理すべきか(拒否、隔離、何もしない)を指示し、さらに認証失敗のレポートを送信元に送る機能を提供する。これら複数の技術を組み合わせることで、より強固なメールセキュリティを構築できる。

システムエンジニアとして、メールシステムの設計、構築、運用に関わる際には、SPFレコードの役割と設定方法を正確に理解し、メールの信頼性とセキュリティを確保するための重要な要素として適切に管理する必要がある。これは、サービスの可用性を高め、ユーザー体験を保護し、ひいては企業のブランドイメージを守ることに繋がる。

関連コンテンツ