SPFとは？メール送信元の認証を強化してフィッシングを防ぐ方法を解説！

メールが届かない、なりすましメールが送られている――そんな経験はありませんか？

ビジネスにおける信頼の鍵は、実は「SPFレコード」にあります。

この記事では、SPFの基本から設定方法、他の認証技術との連携、よくあるトラブルの対処法までをわかりやすく解説。

メールセキュリティの第一歩を踏み出しましょう。

SPFとは何か？

SPF（Sender Policy Framework）は、メールの送信元ドメインを検証することで、なりすましメールの被害を防ぐ技術です。

このセクションでは、SPFの基礎と重要性についてわかりやすく解説します。

1-1. SPFの基本概念と役割

SPFは、自分のドメイン名を使って送信されるメールが「正当な送信元」から来ているかを確認するための仕組みです。

DNSに登録された「SPFレコード」により、許可された送信サーバーを明示します。

1-1-1. SPFの目的とは？

SPFの目的は、以下の2点に集約されます。

• なりすまし対策（スプーフィングの防止）
  差出人を偽ったメールが増えており、特にビジネスメール詐欺（BEC）などの被害が深刻です。SPFを設定することで、自分のドメインが悪用されるリスクを減らすことができます。
• メールの信頼性向上
  SPFを正しく設定しているメールは、受信サーバーからの評価が上がり、迷惑メールフォルダに入れられにくくなります。結果として、メールの到達率が向上します。

1-1-2. SPFレコードとは？

SPFレコードとは、DNSにテキスト形式で登録する情報で、「どのIPアドレス（またはドメイン）がこのドメインのメールを送って良いか」を示すものです。

例えば、以下のような形式です：

この記述は、「192.0.2.0/24の範囲にあるIPアドレスと、example.comドメインに許可されたサーバーがメール送信可能である」ことを意味します。

1-2. なぜSPFが重要なのか？

SPFの導入は、セキュリティだけでなく、メールマーケティングや業務上のコミュニケーションでも重要です。

1-2-1. なりすましメールの被害例

近年、企業を騙るフィッシングメールによって個人情報やパスワード、クレジットカード情報が盗まれる事件が多発しています。

こうした詐欺は、見た目では本物のメールと区別がつかないため、SPFのような送信元検証が非常に効果的です。

1-2-2. SPFがビジネスに与える影響

SPFを導入していないと、以下のようなリスクがあります。

• 顧客にメールが届かない（迷惑メールとして弾かれる）
• 企業ドメインが悪用され、ブランドイメージが低下する
• セキュリティ対策が不十分と判断され、信頼を失う

つまり、SPFはメール送信における「信用の証明」であり、企業や団体の信頼性を守るためにも不可欠な技術です。

SPFの仕組み

SPF（Sender Policy Framework）は、メールの送信元を確認することで、ドメインのなりすましを防ぐ技術です。しかし、実際にどのように機能しているのかは少し複雑に感じられるかもしれません。

このセクションでは、SPFの技術的な仕組みと、なりすまし防止における実際の働きを、わかりやすく解説します。

2-1. メール送信時のドメイン認証プロセス

SPFは、メールが送信された瞬間から受信されるまでの間に行われる「ドメイン認証」のプロセスに深く関わっています。

具体的には、受信側のメールサーバーが、送信元のIPアドレスとドメインのSPFレコードを照合し、送信者が正当かどうかを判断します。

2-1-1. SPF認証の流れ

SPFによる認証の一般的な流れは以下の通りです。

ステップ	内容
1	メールが送信される（SMTP通信）
2	受信側サーバーが送信者のIPアドレスとドメイン情報を確認
3	DNSからそのドメインのSPFレコードを取得
4	SPFレコードと送信者の情報を照合
5	判定結果（Pass, Fail, Softfailなど）に基づき、メールを受信するかどうかを決定

このプロセスによって、正規のメールサーバー以外から送られたメールを自動的に検出・拒否できる仕組みになっています。

2-1-2. SPF検証結果の種類

SPF認証には複数の結果があります。それぞれの意味は以下の通りです。

• Pass：認証成功。正当な送信元からのメール。
• Fail：認証失敗。なりすましの可能性が高い。
• Softfail：暫定的な失敗。許可されていないが、すぐにはブロックしない。
• Neutral：判断不能。
• None：SPFレコードが見つからない。

つまり、SPF認証は単なる「合格／不合格」ではなく、柔軟な対応が可能な仕組みとなっており、メールの信頼性評価の基礎となっています。

2-2. なりすましメール防止におけるSPFの働き

SPFの最大の目的は、なりすましメール（スプーフィング）の防止です。なぜなら、フィッシング詐欺やビジネスメール詐欺（BEC）の多くは、信頼されたドメインを装って行われるためです。

2-2-1. なりすましの典型例とSPFの防御効果

以下のようなケースで、SPFは非常に有効に機能します。

なりすましメールの例

• 「銀行名義」や「有名企業名義」で届くメール
• 社内の上司を装って送られる送金依頼メール
• オンラインサービスを装ったパスワード変更通知

SPFによる防御効果

• 不正なIPアドレスから送られたメールは、SPFチェックで「Fail」になり、受信拒否またはスパム判定される
• 正規のドメインしか利用できないため、ブランドイメージや顧客の信頼を守れる

2-2-2. SPFだけでは防げないケースとその対策

しかし、SPFにも限界があります。たとえば、Fromアドレスは偽装できるため、見た目は正規のドメインのように見えることもあります。したがって、以下のような対策も併用することが推奨されます。

• DKIM（DomainKeys Identified Mail）：メール本文の改ざん検出
• DMARC（Domain-based Message Authentication, Reporting & Conformance）：SPFとDKIMの結果に基づいてポリシーを設定

このように、SPFは単体でも有効ですが、他の技術と組み合わせることで、より高いセキュリティを実現できます。

SPFレコードの設定方法

SPF（Sender Policy Framework）を導入するには、まず「SPFレコード」を正しく設定することが必要です。

SPFレコードは、ドメインのDNSに登録することで、どのサーバーがそのドメインのメールを送信できるかを宣言する情報です。

このセクションでは、SPFレコードの意味と作成方法、設定時の注意点までを丁寧に解説します。

3-1. SPFレコードとは？

SPFレコードは、メールを送信できる「許可されたサーバーの一覧」をDNSに記述する仕組みです。

つまり、送信元ドメインの持ち主が「このIPアドレスやドメインからのメールは正規です」と宣言するための設定です。

3-1-1. SPFレコードの基本構造

SPFレコードは、次のような形式でDNSにTXTレコードとして記述します。

この例の意味を分解すると、以下のようになります。

要素	意味
v=spf1	SPFレコードのバージョン（現在はv=spf1が一般的）
ip4:192.0.2.1	指定されたIPアドレスからの送信を許可
include:_spf.google.com	他のSPF設定を参照（Gmailなどを利用している場合）
-all	上記以外はすべて拒否（Fail）

このように、SPFレコードはシンプルに見えて、正しく構成することで高いセキュリティ効果が得られます。

3-2. DNSへのSPFレコード追加手順

実際にSPFレコードを設定する手順は、利用しているドメイン管理サービスやDNSホスティングサービスによって異なりますが、基本的な流れは共通です。

3-2-1. SPFレコードの設定手順（一般的な手順）

1. 送信元のメールサーバーを確認する
   自社で使用しているメールサーバーや外部サービス（Google Workspace、Microsoft 365など）をリストアップします。
2. 必要な情報をもとにSPFレコードを作成する
   使用しているIPアドレスやドメインをSPF形式でまとめます。
3. DNS管理画面にログイン
   ドメインを管理しているDNSホスティングサービスにログインします。
4. TXTレコードを追加
   ホスト名（多くの場合空欄または「@」）に、作成したSPFレコードを追加します。
5. 変更を保存して反映を確認
   設定後は反映までに数分〜数時間かかることがあります。確認にはSPFチェックツールを使うと便利です。

3-2-2. SPFチェックツールの活用

設定後は、以下のような無料ツールでSPFレコードの正しさを確認しましょう。

• MXToolbox
• Kitterman SPF Validator
• DMARC Analyzer

これにより、設定ミスによるメール不達を未然に防ぐことができます。

3-3. 設定時の注意点とベストプラクティス

SPFレコードを設定する際には、正しい書き方をしないと、逆にメールの配信に悪影響を与える可能性があります。

そこで、以下の注意点とベストプラクティスを意識することが大切です。

3-3-1. 注意すべきポイント

• SPFレコードは1つのドメインに1つだけ
  SPFレコードを複数登録すると、検証エラーの原因になります。
• includeの使いすぎに注意
  外部サービスのSPFを参照する場合、includeを多用するとDNSルックアップ数が増え、上限（10回）を超えると失敗します。
• 最後のallの指定方法に注意
  -all（すべて拒否）と~all（ソフト拒否）の使い分けが重要です。初期設定では~allがおすすめです。

3-3-2. ベストプラクティス

• まずは~all（Softfail）で設定し、ログを確認しながら本番運用へ切り替える
• SPFだけでなく、DKIM・DMARCとの連携を検討する
• SPFレコードの内容を定期的に見直す

このように、SPFレコードの設定は一度やれば終わりではなく、運用と保守も含めて継続的に管理することが重要です。

SPF設定の具体例

SPF（Sender Policy Framework）を実際に導入するためには、SPFレコードを適切に記述する必要があります。

しかし、設定ミスによってメールが正しく配信されなかったり、逆にセキュリティが不十分になってしまうことも少なくありません。

このセクションでは、実際に使えるSPFレコードの記述例と、複数のメールサーバーを併用する場合の対応方法を紹介します。

4-1. 一般的なSPFレコードの記述例

SPFレコードは、利用しているメールサーバーやサービスによって記述内容が異なります。ここでは、よく使われるケースに応じた例を紹介します。

4-1-1. 自社サーバーのみでメール送信している場合

自社の固定IPアドレスを使ってメールを送信している場合、以下のようなSPFレコードをDNSに設定します。

この記述の意味は以下の通りです。

要素	内容
ip4:203.0.113.10	このIPアドレスからの送信を許可
-all	その他すべての送信元は拒否

つまり、この設定により「このIP以外から送信されたメールはすべて不正」と判断されます。

4-1-2. GmailやMicrosoft 365など外部サービスを使っている場合

外部のメールサービスを使っている場合は、そのサービスが提供しているSPF情報をincludeで参照します。

Gmail（Google Workspace）の場合：

Microsoft 365の場合：

このように、正規のサービスプロバイダーをincludeすることで、そのプロバイダーの送信元IP全体を許可することができます。

4-2. 複数のメールサーバーを利用する場合の設定方法

現代のビジネスでは、メール送信元が1つだけとは限りません。たとえば、社内サーバーの他にメールマーケティングサービス（MailchimpやSendGridなど）も利用している場合、それぞれの送信元をSPFレコードに反映する必要があります。

4-2-1. SPFレコードの統合例

以下は、Google WorkspaceとSendGridを併用している場合の例です。

このように複数のincludeを使うことで、両方のサービスからの送信を許可する設定が可能になります。

4-2-2. DNSルックアップ回数に注意

ただし、SPFレコードはDNSルックアップ10回までという制限があります。多くのサービスを含めすぎると上限を超えてしまい、SPFチェックが失敗する原因になります。

対策例：

• 利用していないサービスのincludeは削除する
• 自社サーバーのIPアドレスはip4:で直接記述してルックアップ回数を減らす
• 不要なredirectや複雑な構造を避ける

4-2-3. メンテナンス性を意識した構成

複数のサービスを利用する場合は、記述の可読性とメンテナンス性も重要です。設定後も定期的に見直し、不要なサービスが含まれていないかチェックすることをおすすめします。

SPFと他のメール認証技術との関係

SPF（Sender Policy Framework）は、メールの送信元を検証する強力なセキュリティ対策ですが、それだけでは完全ななりすまし対策とはいえません。

SPFは、DKIM（DomainKeys Identified Mail）やDMARC（Domain-based Message Authentication, Reporting & Conformance）と組み合わせて使うことで、さらに高いレベルのメール認証と保護を実現できます。

このセクションでは、SPFと他の技術との違いや連携方法について詳しく解説します。

5-1. SPFとDKIMの違いと連携

SPFとDKIMは、どちらも「送信者の正当性」を確認するための技術ですが、その仕組みやチェックポイントには明確な違いがあります。

5-1-1. SPFとDKIMの違い

項目	SPF	DKIM
検証対象	送信元IPアドレスとドメイン	メール本文とヘッダー
登録場所	DNSのTXTレコード（SPFレコード）	DNSのTXTレコード（公開鍵）
改ざん検知	できない	可能（メールの内容が変更されていないか検証できる）
特徴	メール送信元のIPを制限	メールに署名を付与して改ざんを防止

つまり、SPFは送信元の「場所」を確認し、DKIMは「内容の整合性」を保証する技術です。

5-1-2. SPFとDKIMの連携メリット

SPFとDKIMを併用することで、それぞれの弱点を補完し合い、以下のようなメリットがあります。

• なりすまし対策の強化
• メールの改ざん検知
• 正当なメールとしての信頼性向上（迷惑メール扱いされにくくなる）
• DMARCポリシーの適用が可能になる（次項で解説）

したがって、メールのセキュリティを高めたい場合は、SPFとDKIMの両方を導入すべきです。

5-2. DMARCを活用した総合的なメール認証戦略

SPFとDKIMを設定した後、それらの認証結果を管理し、なりすまし対策をより厳格に運用するには「DMARC（ディーマーク）」の導入が不可欠です。

5-2-1. DMARCとは？

DMARCは、SPFとDKIMの認証結果に基づき、受信側に対して「不正なメールをどのように処理すべきか」を指示するポリシーを設定する技術です。

例：

このポリシーは以下のような意味になります。

項目	内容
v=DMARC1	DMARCのバージョン
p=reject	認証失敗時はメールを拒否する
rua=mailto:	認証結果のレポート送信先

5-2-2. SPF・DKIM・DMARCの三位一体戦略

3つの技術を組み合わせて使用することで、強固なメール認証体制が整います。

理想的な認証フロー

1. SPFで送信元IPの正当性を確認
2. DKIMでメール本文の改ざんがないかを確認
3. DMARCでポリシーを定義し、違反メールの扱いを制御

この戦略により、自社ドメインを悪用したなりすましを防ぎ、メールの信頼性を最大限に高めることができます。

5-2-3. DMARC導入のベストプラクティス

• SPFとDKIMの導入が先（DMARCは後）
• 最初はp=noneから始め、ログを収集して問題点を把握
• 徐々にquarantineやrejectへポリシーを強化
• レポートを活用して、認証失敗の原因を分析・改善

このように、DMARCはSPFやDKIMの次のステップとして、メールセキュリティを「運用・改善」フェーズへと導く重要な技術です。

SPF設定後の確認とトラブルシューティング

SPF（Sender Policy Framework）レコードを正しく設定した後でも、メールが受信されない、認証に失敗するなどのトラブルが発生することがあります。

したがって、設定後の検証と継続的な監視が非常に重要です。

このセクションでは、SPFレコードの検証方法と活用できる無料ツールについて解説します。

6-1. SPFレコードの検証方法とツールの紹介

SPFレコードは、DNSに正しく登録されていても、構文ミスやルックアップの上限超過などがあると、うまく機能しないことがあります。

従って、設定後は必ず検証を行いましょう。

6-1-1. SPFレコードの確認ポイント

以下は、SPFレコードの検証で特に注意すべき項目です。

• 構文が正しいか
  v=spf1 から始まり、許可IPやドメイン、最後に all を含んでいるか
• DNSに正しく反映されているか
  反映までに時間がかかる場合があります。TTL設定も確認しましょう。
• ルックアップ数が10回を超えていないか
  SPFにはDNSルックアップの回数制限があり、これを超えると認証失敗になります。
• レコードが1つだけ存在するか
  SPFレコードは1ドメインにつき1つのみ。複数あるとエラーになります。

6-1-2. SPF検証に使える無料ツール

以下の無料ツールを使えば、SPFレコードの正当性や問題点を簡単に確認できます。

ツール名	特徴
MXToolbox SPF Record Check	DNSに登録されたSPFレコードを即時チェック。構文エラーやルックアップ数も表示されます。
Kitterman SPF Validator	SPFポリシーの詳細な解析が可能で、構文と挙動をシミュレーションできます。
DMARC Analyzer SPF Check	SPFだけでなく、DMARCやDKIMも含めた統合的なチェックが可能です。

これらのツールは無料で使えるうえ、初心者でも直感的に操作できるため、SPF導入直後の確認や定期的な見直しに最適です。

6-1-3. トラブルが発生したときの対処法

SPF設定後にメールが届かない、あるいはSPF認証で失敗する場合は、以下をチェックしてみてください。

• SPFレコードに誤ったIPやドメインを指定していないか
• include先のサービス側で変更がないか（GoogleやSendGridなどは仕様が変わることがあります）
• メールの送信元が、SPFで許可した範囲外になっていないか

対処のポイント：

• エラーがある場合は、まず構文を修正し、反映後に再検証
• ~all ではなく -all を使用していると、想定外のブロックが起こることもあるので注意