SMTP・API連携で高速メール配信するならブラストエンジン

SPFレコードの確認方法を徹底解説|ツール・コマンド・エラー対処まで

更新日:
執筆者: 森神 佑希

「SPFレコードを設定したはずなのに、メールが迷惑メールに分類されてしまう」「本当に正しく設定されているか不安で、確認方法がわからない」こうした悩みを抱えているエンジニアやメール配信担当者は少なくありません。

SPFレコードはメールのなりすまし対策として欠かせない設定ですが、設定しただけで安心してしまいがちです。実際には、設定後に正しく反映されているかを確認するプロセスが非常に重要です。設定ミスや構文エラーがあれば、せっかく送ったメールが届かなかったり、迷惑メールと判定されたりするリスクがあります

本記事では、SPFレコードの確認に必要な知識を網羅的に解説します。オンラインツールを使ったGUIでの確認方法から、nslookupdigコマンドによるCLIでの確認方法、そしてメールヘッダーを使った実際の送信結果の検証方法まで、順を追って説明します。

さらに、確認時によく遭遇する「None」「Fail」「PermError」などのエラーの原因と対処法も詳しく解説するため、メール到達率の改善に直結する実践的な内容です。メール配信の担当者であれば必ず押さえておきたい情報を凝縮していますので、ぜひ最後までご確認ください。

blastengineのバナー画像2

SPFレコードとは?基本的な仕組みをおさらい

SPFレコードの確認方法に入る前に、まずSPFレコードの基本的な仕組みを正確に理解しておきましょう。確認結果の意味を正しく解釈するためには、SPFが何をしているのかを把握していることが前提となります。

SPFレコードが必要な理由

SPF(Sender Policy Framework)とは、メールの送信元ドメインを認証するための仕組みです。具体的には、あるドメインからメールを送信する権限を持つサーバーのIPアドレスを、DNS(Domain Name System)のTXTレコードとして事前に登録しておく技術です。

メールを受信したサーバーは、送信元のIPアドレスとDNSに登録されたSPFレコードを照合します。一致すれば「正規のサーバーからの送信(Pass)」と判定し、一致しなければ「不正な送信の可能性あり(Fail)」と判定します。

この仕組みが必要になった背景には、電子メールのプロトコル(SMTP)の設計上の問題があります。SMTPは本来、送信元アドレスを自由に偽装できる構造になっており、なりすましメールやフィッシング詐欺が発生しやすい要因の一つとなっていました。SPFはこの問題を解決するために生まれた認証技術です。

2024年2月のGmailガイドライン改定により、1日5,000通以上のメールを送信する場合は、SPF認証およびDKIM認証の設定が必須要件となりました。これにより、SPFの設定とその確認は、すべてのメール配信担当者にとって避けられない作業となっています。

【2026年最新】Gmail送信者ガイドラインを1から10まで解説|Outlook・Yahoo!の最新要件にも対応

SPFレコードの構文と読み方

SPFレコードはDNSのTXTレコードとして登録され、以下のような形式で記述します。

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~all

各要素の意味は以下の通りです。

要素意味
v=spf1SPFバージョン1の宣言。必ず先頭に記述する
ip4:203.0.113.0/24IPv4アドレス(範囲指定も可)を送信許可サーバーとして指定
ip6:2001:db8::/32IPv6アドレスの指定
include:_spf.google.com外部ドメインのSPFレコードを参照・包含する
a対象ドメインのAレコードに登録されたIPを許可
mx対象ドメインのMXレコードに登録されたサーバーを許可
~allリスト外のIPはSoftFail(受信は許可するが疑わしいと判定)
-allリスト外のIPはHardFail(受信拒否)
?all結果に関わらず通過(Neutral)

記述にはいくつか重要な制約があります。1つのドメインに対してSPFレコードは必ず1つだけでなければなりません。複数のTXTレコードとしてSPFを設定すると認証が無効になります。また、includeなどによるDNSルックアップ回数の上限は10回までという制約があり、これを超えると「PermError」となります。

SPFレコードの確認方法3選

SPFレコードの確認には、大きく分けて3つのアプローチがあります。それぞれの特徴と手順を詳しく解説します。

オンラインツールで確認する

最も手軽な方法は、オンラインのチェックツールを利用することです。ブラウザからアクセスするだけで、ドメインのSPFレコードの内容、構文の正確性、ルックアップ回数のカウントなどを視覚的に確認できます。

MXToolBox

公式ページ:https://mxtoolbox.com/spf.aspx

世界的に広く使われているメール診断ツールです。ドメイン名を入力するだけでSPFレコードを取得し、ルックアップの詳細、Pass/Fail判定、構文エラーの有無をわかりやすく表示してくれます。英語サイトですが、表示結果の意味は後述の一覧で確認できます。

  1. https://mxtoolbox.com/spf.aspx にアクセス
  2. 「Domain Name」欄に確認したいドメイン(例:example.com)を入力
  3. 「SPF Record Lookup」ボタンをクリック
  4. 結果画面でSPFレコードの文字列、判定結果、ルックアップ数を確認

PowerDMARC SPFチェッカー

公式ページ:https://powerdmarc.com/ja/spf-record-lookup/

日本語対応のツールで、SPFレコードのルックアップだけでなく、PermError発生リスクの診断や、DKIMやDMARCとの連携状況も確認できます。

ラッコサーバープラス SPFレコード確認ツール

公式ページ:https://rakkoserver.com/plus/tool-spf-checker/

日本語に特化したツールで、ドメインに設定されているSPFレコードの文字列をそのまま表示します。設定内容の確認や複数サービスのincludeが正しく入っているかを確認する際に便利です。

コマンドで確認する(nslookup・dig)

より詳細な確認や、ツールに依存しない方法として、コマンドラインからDNSを直接照会する方法があります。Windowsではnslookup、Mac/Linuxではdigコマンドを使います。

Windowsの場合(nslookup)

コマンドプロンプトを開き、以下を入力します。

nslookup -type=TXT example.com

example.com を確認したいドメインに置き換えてください。出力の中に "v=spf1 ..." という文字列が含まれていればSPFレコードが設定されています。

Mac/Linuxの場合(dig)

ターミナルを開き、以下を入力します。

dig txt example.com

もしくは、よりシンプルに結果だけを表示したい場合は以下のオプションが便利です。

dig txt example.com +short

+short オプションを付けることで、SPFレコードの文字列のみが出力されます。

確認結果の例:

"v=spf1 include:_spf.blastengine.jp ~all"

このような出力が得られれば、SPFレコードが正しく設定・反映されています。何も出力されない場合や、NXDOMAIN が返る場合は、SPFレコードが設定されていないか、DNSへの反映がまだ完了していない可能性があります。

コマンドによる確認は、プログラムやスクリプトによる自動チェックにも応用できるため、CI/CDパイプラインや監視ツールへの組み込みにも適しています。

メールヘッダーで確認する

実際に送信されたメールのヘッダーを解析することで、受信側でSPF認証が通過しているかどうかをリアルタイムで確認できます。これは「設定が存在するか」だけでなく「実際の送信で認証が成功しているか」を確認する最も確実な方法です。Gmailでの確認手順は以下の通り。

  1. テスト用メールを送信し、Gmailで受信する
  2. 受信メールを開き、右上の「…(その他)」をクリック
  3. 「メッセージのソースを表示」を選択
  4. ヘッダー内の Authentication-Results または Received-SPF を探す

ヘッダーの表示例:

Authentication-Results: mx.google.com;
  spf=pass (google.com: domain of sender@example.com designates 203.0.113.1 as permitted sender) smtp.mailfrom=sender@example.com

spf=pass と表示されていれば認証成功です。spf=failspf=softfail が表示されている場合は、SPFレコードの設定に問題がある可能性があります。

SPFレコードの確認結果の見方

確認ツールやメールヘッダーに表示される判定結果には、複数の種類があります。それぞれの意味を正確に理解することが、問題解決の第一歩です。

判定結果意味対応方針
Pass送信元IPがSPFレコードで許可されている。認証成功問題なし
Fail(HardFail)送信元IPがSPFレコードに存在しない。明示的に拒否SPFレコードに送信IPを追加する
SoftFailIPが一致しないが、~allによる緩やかな判定。受信はされるが疑わしいとマークされる送信元IPをSPFに追加することを検討
Neutral?all で明示的な判定なし。結果に関わらず通過セキュリティ向上のために~all-allへの変更を検討
NoneSPFレコードが存在しない、またはドメインに設定がないSPFレコードを新規設定する
PermErrorSPFレコードに永続的なエラーがある(構文ミス、ルックアップ上限超過など)エラー内容を特定して修正する
TempErrorDNSの一時的なエラー。再試行すれば解決することが多い時間をおいて再確認する

最も重要なポイントは、Pass 以外の状態では、送信したメールが迷惑メールとして判定されるリスクがあるという事実です。特に FailPermError は早急な対応が必要です。

SPFレコード確認でよく見つかるエラーと対処法

実際にSPFレコードを確認すると、さまざまなエラーに遭遇することがあります。よくあるエラーのパターンと、それぞれの対処法を解説します。

Noneと表示される場合

確認結果が None の場合、対象ドメインにSPFレコードが存在しないことを意味します。SPFレコードを一度も設定したことがないドメインや、設定後にDNSへの反映がまだ完了していない場合に表示されます。対処法は以下の通り。

  • DNSの管理画面にログインし、対象ドメインのTXTレコードを確認する
  • SPFレコードが未設定であれば、新規でTXTレコードとして追加する(例:v=spf1 include:_spf.example.com ~all
  • 設定済みの場合は、DNSの反映には最大72時間かかることがあるため、時間をおいて再確認する

Failになる場合

Fail が出る場合、メールを送信したIPアドレスがSPFレコードに記載されていないことを意味します。特に、新しいメール配信サービスを追加した際や、送信サーバーのIPアドレスが変更になった際に発生しやすいエラーです。対処法は以下の通り。

  • メール配信サービスのドキュメントを確認し、include: で追加すべきドメインを特定する
  • 既存のSPFレコードを更新し、新しい送信元を追加する
  • 例:v=spf1 include:_spf.blastengine.jp include:_spf.google.com ~all
  • 注意点として、1ドメインにつきSPFレコードは必ず1つのTXTレコードにまとめること

PermError(ルックアップ上限超過)が出る場合

PermError の中でも特に多いのが、DNSルックアップ回数の上限(10回)を超えることで発生するエラーです。複数のメール配信サービスを利用していると、各サービスのinclude:が積み重なり、ルックアップ回数が10回を超えてしまうことがあります。具体的なルックアップ回数の数え方は以下の通り。

  • include: → 1回(参照先でさらにinclude:があれば追加でカウント)
  • a → 1回
  • mx → 1回
  • ptr → 1回
  • ip4 / ip6 → 0回(ルックアップ不要)
  • exists → 1回

対処法は以下の通り。

  • MXToolBoxなどのツールでルックアップ回数を確認し、10回以内に収まるように整理する
  • include: の代わりに、実際のIPアドレスを ip4: または ip6: で直接記述することで回数を削減できる
  • SPFフラット化ツール(SPF Flattening)を利用して、include:を解決済みのIPアドレスに変換する方法も有効

複数のSPFレコードが存在する場合

DNSのTXTレコードとして、v=spf1 で始まるレコードが複数登録されている場合も PermError の原因になります。これは、担当者の引き継ぎ不足や、設定作業を複数回行ったことで重複登録が生じるケースでよく見られます。対処法は以下の通り。

  • dig txt yourdomain.com または nslookup -type=TXT yourdomain.com で現在のレコード一覧を確認する
  • 複数のv=spf1レコードが存在する場合、すべての送信元を1つのレコードに統合する
  • 統合後、古いレコードを削除する

SPFレコードを正しく設定するためのポイント

エラーなくSPFレコードを運用し続けるためには、設定時の注意点と、継続的なメンテナンスの視点が必要です。

メール配信サービスを追加するときの手順

新しいメール配信サービスを導入する際には、SPFレコードの更新が必要になります。手順を誤ると「Fail」や「PermError」につながるため、以下のステップで確実に作業を進めましょう。

STEP 1:現在のSPFレコードを確認する

dig txt yourdomain.com +short で現在のSPFレコードを確認し、すでに設定されている内容をメモしておきます。

STEP 2:追加するサービスのinclude:値を確認する

利用するメール配信サービスのドキュメントやサポートページで、SPFレコードに追加すべきinclude:の値を確認します。

STEP 3:ルックアップ回数を事前にカウントする

既存のルックアップ回数と追加後の合計を計算し、10回以内に収まることを確認します。超過する場合は、IPアドレスの直接記述など、回数を削減する対策を検討します。

STEP 4:既存のTXTレコードを更新する(新規追加ではない)

新しいTXTレコードとして追加するのではなく、既存のSPFレコード(TXTレコード)を編集して、include:の値を追記します。

STEP 5:反映後にオンラインツールで確認する

DNS反映後(数分〜数時間)に、MXToolBoxなどで最新のSPFレコードが正しく反映されていることを確認します。

Gmailガイドライン対応のためのSPF設定

2024年2月に強化されたGmailのメール送信者ガイドラインでは、1日5,000通以上のメールを送信する場合、SPF認証のPassが必須となっています。さらに、DKIM認証も同時に必要であり、将来的にはDMARCの設定も推奨されています。

Gmailへの到達率を最大化するためには、SPFレコードで認証がPassになることを確認するだけでなく、送信ドメインとFromアドレスのドメインが一致している「SPFアライメント」も意識する必要があります。

SPF・DKIM・DMARC三点セットで認証を強化する

SPFは非常に重要な認証技術ですが、単独で使うよりもDKIM・DMARCと組み合わせることで、はるかに強力なメール認証環境を構築できます。

  • DKIM(DomainKeys Identified Mail):メールの内容が送信後に改ざんされていないかを電子署名で検証する技術。SPFが「送信元サーバーの正当性」を証明するのに対し、DKIMは「メール内容の完全性」を証明します。
  • DMARC(Domain-based Message Authentication, Reporting, and Conformance):SPFとDKIMの認証結果をもとに、認証に失敗したメールをどう処理するか(なにもしない・隔離・拒否)のポリシーを定義し、受信側サーバーに指示する仕組み。DMARCレポートにより、自ドメインが不正利用されていないかの監視もできます。

SPF認証の確認をきっかけに、DKIM・DMARCの設定状況もあわせて確認してみることをおすすめします。

SPFレコード確認ならメール配信システムを活用する

SPFレコードの設定と確認は、メールの到達率を守るための基盤です。特に、大量のメールを安定して配信し続けるためには、SPF・DKIM・DMARCに標準対応したメール配信システムの活用が非常に効果的です。

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

自社のメールサーバーで配信するよりも、専門のメール配信システムを利用することで、認証設定の手間とリスクを大幅に低減できます。

  • 認証設定のサポートが充実:SPF・DKIM・DMARCの設定方法が明確にドキュメント化されており、設定ミスを防ぎやすい
  • IPレピュテーションの維持:サービス提供者側でIPアドレスの評判を管理するため、メールの到達率が安定する
  • Gmailガイドライン対応が容易:最新のガイドラインへの対応が自動的に提供されることが多い
  • バウンス管理の自動化:送信エラーが自動的に処理されるため、IPレピュテーションの悪化を防ぐ

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

ブラストエンジン

blastengine(ブラストエンジン)は、SMTPリレーやAPIで連携することで、高速・大量のメール配信を実現するエンジニア向けメール配信サービスです。SPF/DKIM/DMARC対応を標準搭載しており、メール認証の設定・確認がスムーズに行えます。

  • SPF/DKIM/DMARC対応:送信ドメイン認証技術に標準対応し、なりすまし・迷惑メール判定を回避
  • API連携・SMTPリレー:既存システムへの組み込みが容易で、最短当日から利用開始可能
  • IPレピュテーション管理:blastengine側で運用・管理するため、常に高い送信者評価を維持
  • バウンスメール自動対応:エラーメール管理を自動化し、エンジニアの運用負荷を大幅に削減
  • 99%以上の高いメール到達率:国内キャリア・ISPへの個別送信ロジックで確実に届ける

メール認証の設定や確認に手間をかけず、エンジニアが本来の開発業務に集中できる環境を提供します。初期費用無料で月額3,000円から利用でき、メールアドレス入力のみで無料トライアルが可能です。

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

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

ブラストメール

ブラストメール(blastmail)は、15年連続で導入社数シェアNo.1を獲得し、27,000社以上に導入されているメール配信システムです。SPF/DKIM設定に対応しており、Gmailガイドラインへの対応もサポートしています。

  • 迷惑メール判定対策(SPF/DKIM):主要な送信ドメイン認証に対応し、高い到達率を実現
  • Gmailガイドライン対応:Gmailへの一括配信でも到達率を高く維持できる配信基盤
  • 効果測定機能:開封率・クリック率・エラーカウントをリアルタイムで把握可能
  • 業界最安クラスの料金:月額4,000円〜で大規模配信も低コストで実現(配信通数無制限)
  • 充実したサポート体制:電話・メール・チャットで導入前から利用中まで手厚くフォロー

マーケティング担当者がSPFレコードの設定に悩まずメール配信に集中できる環境を提供します。

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

まとめ

SPFレコードの確認方法について、ツール・コマンド・メールヘッダーの3つのアプローチを解説しました。重要なポイントを整理します。

  • 確認方法は3種類:オンラインツール(MXToolBox等)、コマンド(nslookup/dig)、メールヘッダーの確認
  • 判定結果の意味を理解する:Pass以外の状態(Fail・SoftFail・PermError等)はメール到達率に直結するため、早急な対応が必要
  • よくあるエラー:None(未設定)、Fail(IP未登録)、PermError(ルックアップ上限超過)、複数レコードの重複
  • SPFはDKIM・DMARCと組み合わせる:三点セットで認証を強化することで、Gmailガイドラインへの対応と迷惑メール判定の回避が容易になる

次のアクションとして、まずdig txt yourdomain.com +shortまたはMXToolBoxで現在のSPFレコードを確認してみてください。Pass以外の判定が出ている場合は、本記事のエラー対処法を参考に設定を見直しましょう。

FAQ

SPFレコードの確認はどのツールで行うのがおすすめですか?
A:最も手軽なのはMXToolBox(https://mxtoolbox.com/spf.aspx)です。ドメインを入力するだけでSPFレコードの内容、ルックアップ回数、Pass/Fail判定を一括で確認できます。日本語対応を希望する場合はPowerDMARCやラッコサーバープラスのツールも利用できます。
SPFレコードを設定してもNoneと表示される場合はどうすれば良いですか?
A:NoneはSPFレコードが存在しない状態を示します。SPFレコードが未設定の場合は新規追加が必要です。設定済みの場合はDNSへの反映に時間がかかっている可能性があり、最大72時間待ってから再確認することをおすすめします。
SPFレコードのルックアップ回数が10回を超えるとどうなりますか?
A:ルックアップ回数が10回を超えると「PermError(永久エラー)」が発生し、受信サーバーはSPF認証失敗として扱うことがあります。メール到達率が低下する原因となるため、ip4:やip6:による直接IPアドレス指定や、不要なinclude:の削除で10回以内に収まるよう整理してください。
複数のメール配信サービスを使う場合、SPFレコードはどう記述しますか?
A:1つのTXTレコードにすべての送信元を記述します。例えばblastengineとGmailの両方を使う場合は、v=spf1 include:_spf.blastengine.jp include:_spf.google.com ~all のように、1行で複数のinclude:を記述します。2つ目のSPFレコードとして別TXTレコードを追加するのは誤りで、認証エラーの原因になります。
SPFレコードを設定してもメールが迷惑メールに入ってしまいます。原因は何ですか?
A:SPF認証がPassになっていても、DKIM認証や送信元IPのレピュテーション、コンテンツの内容など複数の要因が迷惑メール判定に影響します。メールヘッダーのAuthentication-Resultsを確認してSPF・DKIMの両方がPassになっているかを確認し、DKIMが未設定の場合は設定を追加することを検討してください。

森神 佑希
この記事の執筆者

株式会社ラクスライトクラウド Webマーケティングリーダー
森神 佑希

顧客導入社数シェアNo.1のメール配信システム「blastmail」・「blastengine」のWebマーケティング担当。2年以上メルマガ配信の実務を行っており、先頭に立ってPDCAを回してきた。メルマガのノウハウは日本最高クラスと言っても過言ではない。

blastengine(プラストエンジン)ロゴ

エンジニアを面倒なメールに関するトラブルから解放するために作られたブラストエンジン
まずは無料トライアルで、その使いやすさを実感してみませんか?

\メールアドレス入力のみ/

無料トライアル

販売パートナー募集

クライアント企業様へブラストエンジンの提供をお考えの企業様はパートナープログラム登録も併せてご検討ください。
SIer・マーケティング支援・Web制作企業様におすすめの制度です。

パートナープログラム詳細open_in_new