SPF（Sender Policy Framework）とは？｜メール認証の仕組み・SPFレコードの書き方までわかりやすく解説

SPFとは、「このメールは正しい送信元から送られています」と受信側に証明するための仕組みのことです。「Sender Policy Framework」の略で、メールのなりすましを防ぐ送信ドメイン認証技術のひとつです。

SPFは、DKIM・DMARCと並び、メールの送信ドメイン認証技術の「土台」にあたります。2024年に行われたGmailやYahoo!メールをはじめとする主要メールプロバイダのガイドライン強化により、自社ドメインのアドレスからメールを利用するほぼすべての企業にとって、SPFの設定は必須となりました。

本記事では、SPFとは何かという基本から、SPF認証の仕組み、SPFレコードの書き方・設定・確認方法、よくあるエラーの対処法までを、わかりやすく解説していきます。

SPFとは？メールのなりすましを防ぐ送信ドメイン認証技術

SPF（Sender Policy Framework）とは、メールの送信元が正規のサーバーから送られたものかを受信側が検証するための、送信ドメイン認証のひとつです。

メールの差出人アドレスは、技術的には誰でも偽装ができてしまいます。そこでSPFでは、「このドメインのメールは、このサーバーから送られる」という情報をあらかじめ公開しておき、受信者側がその情報と実際の送信元を照合します。一致すれば正規のメール、一致しなければなりすましの疑いあり、と判断する仕組みです。

SPF認証の仕組み

SPF認証は、送信側と受信側の役割分担で成り立っています。ここでは、メールが送られてから認証されるまでの流れを整理します。

送信側：DNSにSPFレコードを公開する

送信側がやるべきことは、「自社ドメインのメールは、どのサーバーから送られるか」をDNS（ドメイン名とサーバーの情報を管理する、インターネット上の住所録のようなもの）に記載しておくことです。この登録情報がSPFレコードです。

SPFレコードは、DNSに登録するTXTレコードとして公開され、受信側からいつでも参照できる状態になります。

受信側：SPFレコードを照合して認証する

受信側のサーバーは、メールを受け取ると次の手順で認証を行います。

ここで照合されるのは、メールの中身でも差出人の表示名でもなく、実際に送信したサーバーのIPアドレスです。

SPFの設定を行わないままメールを送ると、認証に失敗し、受信拒否されたり迷惑メールフォルダに振り分けられたりする可能性が高くなります。

SPFは「メール転送に弱い」

SPFは送信元IPアドレスを基準にするため、メールが転送されると認証に失敗しやすいという弱点があります。転送によって送信元IPが転送サーバーのものに変わり、元のSPFレコードに登録されていないためです。この弱点は、別の認証技術であるDKIMを併用することで補えます。

SPFレコードの書き方

それでは、実際にDNSに記載するSPFレコードの書き方を見ていきましょう。

SPFレコードの記述例は次のようになります。

v=spf1 ip4:192.0.2.1 include:spf.example.com ~all

（意味：IPアドレス192.0.2.1と、spf.example.comが指定するサーバーからの送信を許可する。それ以外はソフトフェイルとする）

上記のSPFレコードを分解すると、3つの要素で構成されていることがわかります。

メール配信システムを利用する場合、システムの提供会社から送信元の正しい記述方法を指示されることが多いので、それに従ってレコードを記述しましょう。

たとえば、弊社が提供するメール配信システム「ブラストメール」を使用する場合、SPFレコードは下記のように記述します。

v=spf1 include:spf.bmv.jp ~all

「~all（ソフトフェイル）」と「-all（ハードフェイル）」の違い

SPFレコードの末尾には、許可リストに合致しなかったメールの扱いを指定する記述を置きます。よく使われるのが ~all と -all です。

はじめてSPFを設定する場合や、外部サービスを複数併用している場合は、まず ~all で運用を始め、すべての送信元を把握できてから -all への引き上げを検討するのが安全です。

SPFレコードをDNSへ登録する

SPFレコードを実際に登録する作業は、ドメインを管理しているDNSサーバーの管理画面で行います。

自社ドメインを管理しているサービス（お名前.com、ムームードメイン、Xserver、AWSなど）の管理画面でTXTレコードを追加します。社内の担当者に、上記のSPFレコードを記載するように依頼しましょう。

なお、外部のメール配信システムを使う場合は、配信システム側のドメインであらかじめSPFが設定されていることがほとんどです。そのため、厳密には自社で設定しなくても、SPF認証そのものはパスします。

ただし注意したいのが、docomoやauなどの国内キャリアメールに対しメールを送る場合です。これらは配信システム側のドメインだけでなく、自社ドメイン（受信者の画面に表示される送信元）のSPFレコードも認証します。ここが未設定だと迷惑メール扱いをされることがあるため、メール配信システムを使う場合でも、自社ドメインのDNSにはSPFレコードを設定しましょう。

【注意】SPFレコードは1ドメインに1つだけ

注意したいのが、すでに別のシステムのSPFレコードが登録されている場合です。Google WorkspaceやMicrosoft 365を利用していると、すでに v=spf1… が存在していることがあります。

このとき、新しいSPFレコードを2行目として追加するのはNGです。SPFレコードは1つのドメインにつき1つのみというルールがあり、複数行に分けると両方が無効になってしまいます。

誤った例（2行に分けてしまう）

v=spf1 include:_spf.google.com ~all
v=spf1 include:spf.bmv.jp ~all

正しい例（1行にまとめる）

v=spf1 include:_spf.google.com include:spf.bmv.jp ~all

すでに設定がある場合は、include:〇〇 の部分をスペースで区切って追記し、前後を v=spf1 と ~all で挟む形で1行に統合してください。

SPFレコードが正しく反映されているか確認する

SPFレコードが正しく設定されていないままメールを送ると、迷惑メールとして扱われる可能性が高くなります。SPFの設定を確認する3つの方法を紹介します。

コマンド（nslookup / dig）で確認する

パソコンのコマンドラインから、ドメインに設定されたTXTレコードを直接確認できます。

Windowsの場合

「コマンドプロンプト」（スタートメニューで「cmd」と検索）を開き、次のコマンドを入力してEnterキーを押します。

nslookup -type=txt 確認したいドメイン

Mac・Linuxの場合

「ターミナル」（Macではアプリケーション＞ユーティリティ内）を開き、次のコマンドを入力してEnterキーを押します。

dig 確認したいドメイン txt +short

実行結果に v=spf1… から始まる文字列が表示されれば、SPFレコードが反映されています。表示されない場合は、設定が誤っているか、DNSへの反映が完了していない可能性があります。

SPFチェックツール（Webサービス）で確認する

コマンド操作に不慣れな場合は、ドメイン名を入力するだけで診断できるWebの確認ツールが便利です。「SPF check」「SPFレコード 確認」などで検索すると、無料で使えるツールが見つかります。

こうしたツールの多くは、SPFレコードの構文ミスや、後述するDNSルックアップ回数の超過といった問題まで可視化してくれます。設定後に一度チェックしておくと安心です。

受信メールのヘッダーで認証結果を確認する

実際に送ったメールがSPF認証に成功しているかは、受信したメールのヘッダー情報で確認できます。

GmailやOutlookなどでメールの「原文を表示」「メッセージ ヘッダー」を開きます。

すると、そのメールの認証結果が表示されます。

SPF：PASSと表示されていれば、SPF認証は成功しています。

SPF設定でよくあるエラーと対処法

「設定したはずなのに認証に失敗する」というケースは少なくありません。ここでは、つまずきやすい代表的なエラーと対処法を解説します。

DNSルックアップ10回制限の超過（PermError）

SPFの仕様（RFC 7208）では、受信側が認証時に行うDNSへの問い合わせ（ルックアップ）の回数を最大10回までと定めています。これを超えると、SPFは「PermError（永続的エラー）」となり、認証そのものが失敗します。

注意したいのは、include や a、mx といったメカニズムがそれぞれルックアップを消費する点です。たとえば include:_spf.google.com は内部でさらに複数の参照を行っており、それだけで4回程度を消費します。複数のメール配信サービスやSaaSを併用していると、知らないうちに10回を超えてしまうのです。

対処法としては、次のような方法があります。

なお、ip4 と ip6 による直接指定はルックアップにカウントされないため、何個並べても制限には影響しません。

参照：公式（RFC Editor）RFC 7208 Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1

SPFレコードが2つ以上存在している

前述の通り、1つのドメインに複数のSPFレコードが存在すると、SPFはPermErrorとなり無効になります。新しいサービスを追加する際は、必ず既存のSPFレコードを確認し、1行に統合してください。

設定の反映に時間がかかる（DNSの反映待ち）

SPFレコードを追加・変更しても、すぐには反映されないことがあります。DNSの情報がインターネット全体に行き渡るまでには、数分から長い場合で数十時間かかることがあるためです。設定直後に確認して反映されていなくても、しばらく時間をおいてから再度チェックしてみてください。

あわせて設定したいDKIM・DMARC

送信ドメイン認証は、SPF・DKIM・DMARCという3つの技術がセットで語られます。それぞれ役割が異なり、補完し合うことでなりすまし対策の精度が高まります。

ここからは、残るDKIMとDMARCの役割を見ていきましょう。

DKIM：メールの内容が改ざんされていないかを検証する

DKIM（DomainKeys Identified Mail）は電子署名を使って、メールの内容が改ざんされていないかを検証する仕組みです。

SPFは、メールが送信されたIPを認証で確認するため、転送されると失敗しやすいという弱点がありますが、DKIMはメール自体に署名を付与するため、転送されても認証が維持されやすいという特徴があります。両方を導入することで、なりすまし対策の精度を高められます。

DKIMの仕組みについては、以下の記事で図解とともに詳しく解説しています。あわせてご覧ください。

DMARC：認証に失敗したメールの扱いを決める

DMARC（Domain-based Message Authentication, Reporting and Conformance）は、SPFとDKIMの認証に失敗したメールをどう扱うかを受信側に指示するためのポリシー宣言です。

「認証に失敗したメールは迷惑メールに入れる（quarantine）」「完全に拒否する（reject）」といった指示を出せるほか、自社ドメインがなりすましに悪用されていないかのレポートを受け取る機能も持っています。SPFとDKIMが「認証する技術」であるのに対し、DMARCはそれらを統括する「運用と防御のルールを決める司令塔」と言えます。

DMARCの設定方法や、ブランドロゴを表示する最新規格BIMIまでを知りたい方は、以下の記事で詳しく解説しています。

なぜ今、SPF設定が必須なのか（Gmail・Yahoo!送信者ガイドライン）

かつてSPFの設定は「推奨事項」でしたが、現在はビジネスでメールを送るすべての企業にとって避けられない「必須要件」になりました。背景にあるのが、主要メールプロバイダによる送信者ガイドラインの強化です。

2024年2月のGmail送信者ガイドライン強化

2024年2月より、Googleは「メール送信者のガイドライン」を大幅に強化しました。この変更により、Gmailアカウント宛てにメールを送るすべての送信者に対し、SPFまたはDKIMによる認証設定が求められるようになりました。Yahoo!メールも同様の方針を打ち出しており、対応は業界全体の流れとなっています。

関連情報：メール送信者のガイドライン（Google公式）

5,000通/日以上の大量送信者はSPF・DKIM・DMARCすべてが必須

特に、1日に5,000通以上のメールを送る「大量送信者」には、より厳しい要件が課されています。具体的には、SPF・DKIM・DMARCの3つすべての設定が必要です。要件を満たさない場合、正当なビジネスメールであってもブロックされたり迷惑メールに振り分けられたりする可能性が高くなります。

Gmailの送信者ガイドラインの全体像は、以下の記事で詳しく解説しています。確認したい方はこちらをご覧ください。

SPF・DKIMに対応するならメール配信システムを活用する

ここまで見てきたSPFやDKIMの設定を簡単に確実に行うには、送信ドメイン認証に標準対応したメール配信システムを活用するのがおすすめです。

メール配信システムを使うメリット

メール配信システムは、なりすまし対策と大量配信を両立させるための仕組みを備えています。SPF・DKIM対応の観点では、主に以下のメリットがあります。

おすすめのメール配信システム「ブラストメール」

ブラストメール（blastmail）は、15年連続で導入社数シェアNo.1（※）を獲得しているメール配信システムです。27,000社以上の導入実績に裏打ちされた高い到達率と、専門知識がなくても直感的に操作できるシンプルな管理画面が支持されています。

SPF・DKIMの設定に不安がある方でも、ガイドライン対応の配信基盤をそのまま利用できるのが大きな強みです。最もリーズナブルなプランなら月額4,000円台から始められます（DKIMはStandardプランから利用可能）。無料トライアルも提供しているので、まずは気軽にお試しください。

公式サイト：シェア1位のメール配信システム「ブラストメール」

※ミックITリポート2025年8月号「クラウド型eメール一斉配信サービスの市場動向と中期予測（売上高/アクティブ法人顧客数）」より

おすすめのメール配信システム「blastengine」

blastengine（ブラストエンジン）は、お客様のシステムとSMTPリレーやAPIで連携することで、一斉配信やトランザクションメールを簡単に行えるメール配信サービスです。自動送信メールやシステム連携が必要な場面に適しており、運用・メンテナンスはブラストエンジン側で行うため、常に高いIPレピュテーションを維持できます。

Gmailやキャリアメールへの未達・遅延を解消し、エンジニアを面倒なサーバー運用から解放する高速かつ確実なメール配信サービスです。初期費用無料・月額3,000円から利用でき、メールアドレスの入力だけで無料トライアルを開始できます。

ブラストエンジン公式サイト：https://blastengine.jp/

まとめ

SPF（Sender Policy Framework）とは、送信元サーバーのIPアドレスを照合し、メールが正規の送信元から送られたものかを検証する送信ドメイン認証技術です。SPFレコードをDNSに正しく公開することで、なりすましを防ぎ、メールの到達率を高められます。

設定で特に押さえるべきポイントは、SPFレコードは1ドメインに1つだけであること、DNSルックアップは10回までという制限があること、そしてメール配信システム利用時も自社ドメインにSPFを設定することの3点です。

また、SPF単独では転送時の認証失敗などの弱点があるため、改ざんを検知するDKIM、認証失敗時の対応を決めるDMARCとあわせて整備することで、より確実なメール配信体制を構築できます。2024年2月以降のGmail送信者ガイドラインに対応するためにも、SPFを起点とした送信ドメイン認証の整備を進めましょう。

SPF・DKIMの設定に対応したメール配信システムを活用すれば、ガイドラインに沿った確実な配信が可能になります。自社の配信環境を見直すきっかけにしてみてください。