SPFレコードとは？仕組み・書き方・設定時の注意点を解説【ドメイン】

「会社名を名乗った怪しいメールが届いた」「自分のドメインを装った迷惑メールが取引先に届いていた」——こうしたメールのなりすまし被害を防ぐために使われるDNSの仕組みのひとつが、今回紹介する「SPFレコード」です。

今回は、SPFレコードとは何か、どういう仕組みでなりすましを防いでいるのか、具体的な書き方、そして設定時につまずきやすいポイントまで、まとめて解説します。

SPFレコードとは

SPFレコード（Sender Policy Framework レコード）とは、「このドメインからのメールは、このサーバーから送られたものだけが正規です」という情報を公開するための、DNSのTXTレコードです。

メールの送受信に使われるSMTP（Simple Mail Transfer Protocol）というプロトコルには、もともと「送信元アドレスが本物かどうかを確認する仕組み」が備わっていません。そのため、何も対策をしていないと、第三者が自分のドメインになりすましてメールを送信できてしまいます。SPFレコードは、この弱点を補うために考え出された仕組みです。

イメージとしては、「このドメインから送っていいメールサーバーのリスト」を、受付名簿のような形でDNS上に公開しておくようなものです。受信側のメールサーバーは、届いたメールの送信元が名簿に載っているかどうかを確認し、載っていなければ「怪しいメール」として処理します。

SPFレコードが必要な理由

SPFレコードを設定していないドメインは、次のようなリスクにさらされます。

• 第三者が自社ドメインを名乗ってフィッシングメールや迷惑メールを送信し、なりすまし被害が発生する
• 自社から送った正規のメールが、受信側のスパムフィルターに引っかかりやすくなる
• 結果として、取引先や顧客に送ったメールが届かない・迷惑メールフォルダに振り分けられるといった、メール到達率の低下につながる

近年は、GmailやYahoo!メールをはじめとする主要なメールサービス側が、SPFやDMARCなどの認証設定を事実上の必須条件として扱うようになってきています。自社ドメインからメールを送る予定があるなら、SPFレコードの設定は「あったほうがいい」ではなく「ないと困る」設定だと考えておいたほうがよいでしょう。

SPFレコードの仕組み（チェックの流れ）

SPFの検証は、メールを受け取った側のサーバーが行います。大まかな流れは次のとおりです。

1. 受信側のメールサーバーが、届いたメールの送信元IPアドレスと、送信ドメイン（Return-Pathのドメイン）を確認する
2. そのドメインのSPFレコード（v=spf1で始まるTXTレコード）をDNSに問い合わせる
3. SPFレコードに記載されている「送信を許可されたIPアドレス・サーバー」のリストと、実際の送信元IPアドレスを照合する
4. リストに一致すればメールを正規のものとして扱い、一致しなければSPFレコードの指定に従って「拒否」または「迷惑メール扱い」などの処理を行う

ポイントは、SPFが検証しているのは「エンベロープFrom（Return-Path）」と呼ばれる、メールの配送管理に使われるアドレスであるという点です。メールソフトの画面に表示される「差出人（Fromヘッダー）」とは必ずしも一致しないため、表示上の差出人のなりすましまで完全には防げません。この部分を補うのがDMARCの役割になります（DMARCについては別記事でも解説しています）。

SPFレコードの書き方

SPFレコードは、DNSのTXTレコードとして登録します。基本的な例は次のとおりです。

v=spf1 ip4:192.0.2.0 ip4:192.0.2.1 include:examplesender.email -all

それぞれの要素の意味は次のとおりです。

要素	役割
v=spf1	SPFレコードであることを示す。必ず先頭に記述する
ip4: / ip6:	送信を許可するIPv4／IPv6アドレスを指定する
a	そのドメインのAレコードに登録されたIPアドレスからの送信を許可する
mx	そのドメインのMXレコードに登録されたメールサーバーからの送信を許可する
include:	外部サービス（メール配信代行会社など）のSPFレコードをそのまま取り込んで許可する
-all	リストにないサーバーからのメールを拒否する（最も厳格）
~all	リストにないサーバーからのメールを「疑わしい」として扱うが、受信は許可する
+all	誰からの送信でも許可してしまう（基本的に非推奨）

たとえば、自社のメールサーバーに加えて、Google WorkspaceとSendGridを併用している場合は、次のように複数のincludeを並べて記述します。

v=spf1 include:_spf.google.com include:sendgrid.net -all

SPFレコードのメリット・設定時の注意点

• 自社ドメインを装ったなりすましメール・フィッシングメールを受信側で拒否しやすくなる
• 正規のメールがスパム扱いされにくくなり、メールの到達率（デリバラビリティ）が向上する
• DKIM・DMARCと組み合わせることで、ドメイン全体の送信者としての信頼性を高められる
• 1つのドメインに設定できるSPFレコードは1つだけ。複数設定すると、SPFレコード自体が無効になってしまう
• SPFレコードの検証時に行われるDNS参照（includeやネストした参照など）は最大10回までという制限があり、超えるとSPF自体がエラー扱いになる
• レコードの末尾は必ず-all・~all・+allのいずれかの「all」か、redirect=で終える必要がある
• SPFレコードにはアルファベットの大文字を使わないのが推奨されている
• かつて専用のレコードタイプ（TYPE99／SPFレコードタイプ）も存在したが、現在はRFC 7208に基づき、必ずTXTレコードとして公開する必要がある

このうち特につまずきやすいのが、「SPFレコードを増やしてしまう」ミスです。新しいメール配信サービスを導入するたびに、既存のSPFレコードを編集せず、新しいSPFレコードを追加で作ってしまうケースがよく見られます。SPFレコードは1ドメインにつき1つしか認識されないため、その場合は既存のレコードにincludeを追記する形で、1つのレコードにまとめる必要があります。

自分のドメインのSPFレコードを確認する方法

設定したSPFレコードが正しく機能しているかどうかは、次のような方法で確認できます。

• 当サイトのドメインチェッカー：ドメイン名を入力するだけで、SPFを含むDNSレコードをまとめて確認できます
• digコマンド：dig example.com TXT を実行し、v=spf1から始まる行を確認します
• SPFレコード専用のチェックツール：MXToolboxやMimecastのSPF Record Checkerなど、SPFの構文エラーやDNS参照回数の超過を自動で診断してくれる無料ツールも複数公開されています

特に、複数のincludeを使っている場合や、他社のサービスと併用している場合は、DNS参照回数が10回を超えていないかどうかを、こうしたチェックツールで一度確認しておくと安心です。

SPFの設定でよくある落とし穴が、「メール配信サービスを解約したのに、SPFレコードのincludeだけ消し忘れている」というケースです。使っていないサービスのincludeが残っていても、すぐにメールが届かなくなるわけではありませんが、DNS参照回数の上限を無駄に消費してしまいます。サービスの導入・解約のたびに、SPFレコードも合わせて棚卸しする習慣をつけておくのがおすすめです。

DKIM・DMARCとの違い

SPFは「送信元サーバーが正規かどうか」をチェックする仕組みですが、これだけでメールのなりすまし対策が完結するわけではありません。

• DKIM：メールに電子署名を付与し、内容が途中で改ざんされていないかを検証する仕組み
• DMARC：SPFとDKIMの結果をもとに、認証に失敗したメールをどう扱うか（受信する・迷惑メール扱いする・拒否するなど）を定めるポリシーで、認証結果のレポートを受け取ることもできる

SPF単体では、表示上の差出人（Fromヘッダー）のなりすましまでは防げないため、実際の運用ではSPF・DKIM・DMARCの3つを組み合わせて設定するのが基本です。

まとめ

SPFレコードは、「このドメインからのメールは、このサーバーからのものだけが正規です」という情報をDNS上に公開し、メールのなりすましを防ぐための仕組みです。書き方自体はシンプルですが、1ドメイン1レコードまでという制限や、DNS参照10回までという制限など、見落としやすいルールもいくつか存在します。

設定したら終わりにせず、チェックツールを使って構文エラーや参照回数の超過がないかを確認し、DKIM・DMARCと組み合わせて、ドメイン全体でのメール認証の精度を高めていくことをおすすめします。