SPFレコードとは？正しい書き方やDNSへの設定・確認手順を解説

ベンダーから「SPFレコードの設定をお願いします」と依頼されても、具体的な書き方やDNSへの登録方法が分からず戸惑うケースは少なくありません。SPFレコードとは、自社ドメインを名乗るメールが正規のサーバーから送信されたことを証明する仕組みです。未設定のままでは、Gmailなどの受信側で迷惑メールと判定されたり、受信を拒否されたりするおそれがあります。本記事では、SPFレコードの役割と仕組みから、状況別の具体的な書き方、DNSへの設定・確認手順、設定時の注意点までを順に解説します。

SPFレコードとは？なりすましを防ぐ送信ドメイン認証

SPFレコードは、メール送信元の正当性を証明する仕組みです。DKIMやDMARCとの違いも交えて特徴を整理します。

認証方式	特徴と確認対象
SPF	IPアドレスを用いて送信元の正当性を確認する
DKIM	電子署名を用いてメールの改ざんがないことを確認する
DMARC	SPFとDKIMの結果をもとに認証失敗時の取り扱いを指示する

メール送信元サーバーの正当性を証明する

SPFレコードは、メールの送信元が正規のサーバーであることを受信側に証明します。DNS（インターネット上のドメイン名とIPアドレスを紐づけるシステム）に許可されたIPアドレスをあらかじめ登録しておく仕組みです。DNSは、たとえば「example.com」という名前を「192.0.2.1」という住所に変換する、電話帳のような役割を担うシステムです。受信側が行うのは、届いたメールのIPアドレスとDNSの登録情報を照合する処理です。両者が一致すれば認証成功（pass）と判定されます。一致しない場合は、レコードの書き方に応じてfail（詐称の明示）やsoftfail（詐称の疑い）などの結果が返り、その後の扱いは受信側の運用ポリシーに委ねられます。

混同しやすいDKIMやDMARCとの違いを理解する

SPFがIPアドレスで送信元を認証するのに対し、DKIMは電子署名を用いて改ざんがないことを証明します。一方のDMARCは、SPFとDKIMの認証結果をもとに、認証失敗時のメールの取り扱いを受信側に指示する仕組みです。SPF単体でもなりすまし対策として機能しますが、DKIMやDMARCと組み合わせることでセキュリティがより強固になります。

なりすましメールとは？発生する仕組みと対策について解説

送信ドメイン認証技術（SPF、DKIM ）やDMARCとはどのような仕組みか？

SPFレコードの設定が強く求められる理由

なりすまし被害の防止や到達率の維持など、SPFレコードの設定が強く求められている背景を整理します。

求められる理由	具体的な効果・影響
なりすまし被害の防止	自社ドメインを悪用した詐欺メールをブロックできる
誤判定の回避	正規のメールが迷惑メールフォルダに振り分けられなくなる
Gmailガイドラインへの対応	未設定の場合にGmail宛のメールが受信拒否される事態を防ぐ

自社ドメインを使ったなりすまし被害を防ぐ

SPFレコードを設定しておくと、悪意のある第三者が自社ドメインを騙って送信する詐欺メールを、受信側が不正なメールとして検知しやすくなります。攻撃者は偽の送信元アドレスを簡単に作成でき、取引先や顧客にフィッシングメールを送る事案が絶えません。SPFによる認証があれば、受信側のサーバーが不正なメールを検知できます。認証に失敗したメールを拒否するか、警告を付けて受信するかは受信側のポリシー次第ですが、なりすましを判別する材料を提供できる点が大きな効果です。

迷惑メールフォルダへの誤判定を回避する

正規のメールが迷惑メールとして誤判定されるリスクを大幅に下げられます。多くのメールプロバイダは、送信ドメイン認証の結果をスパム判定の重要な指標として扱っています。SPFやDKIMによる認証を通過できない場合、正当な業務連絡やメールマガジンであっても迷惑メールと判定されたり、受信を拒否されたりするケースも少なくありません。安定した情報伝達を維持するうえで、SPFレコードの設定は重要です。

メルマガの迷惑メール・スパム扱いによる配信停止の対策とは？

Gmailが定める最新の送信者ガイドラインに対応する

Googleが公開しているGmailの送信者ガイドラインに従うためにも設定が必要です。このガイドラインでは、Gmail宛にメールを送るすべての送信者に対してSPFまたはDKIMの認証を求めています。未対応のまま送信を続けると、メールが受信拒否されたり迷惑メールフォルダに隔離されたりします。事業活動におけるメールの不達を防ぐうえで重要な対応です。

参考：メール送信者ガイドライン-Gmailヘルプ

【2024年2月以降】Gmail送信者ガイドライン変更！メルマガ送信者は要注意

認証が完了するまでのSPFレコードの仕組み

送信側によるDNSへの登録から、受信側による照合までの一連の流れを整理します。

担当	処理内容
送信側	許可するIPアドレスをDNSのTXTレコードに登録する
受信側	メールの受け取り時に送信元のIPアドレスとSPFレコードを照合する

送信側はDNSのTXTレコードに許可リストを登録する

送信側は、メールの送信を許可するサーバーのIPアドレス情報を自社ドメインのDNSに登録します。具体的には、TXTレコード（DNSサーバーにテキスト情報を登録するための領域）を利用してSPFの構文を記述する流れです。TXTレコードは、おもにドメインの所有権の証明や送信ドメイン認証の情報を記述する際に利用されます。これにより、インターネット上の誰でも「このドメインが許可しているIPアドレス」を参照できる状態が整います。

受信側はメール受け取り時に送信元のIPアドレスを照合する

受信側のサーバーは、メールを受け取るとエンベロープFrom（メールの配送制御に使われる実際の送信元アドレス）のドメインを確認します。これは配送エラーが発生した際の返信先として機能するアドレスです。そのドメインのDNSに問い合わせてSPFレコードを取得し、実際に通信を行ってきたIPアドレスと比較します。リストに含まれていれば認証成功（pass）と判定され、迷惑メールとして扱われるリスクを下げられます。含まれていない場合は、「-all」を指定していれば拒否の対象となり、「~all」を指定している場合は受信したうえで警告や追加のフィルタリングの対象となるのが一般的です。

状況別にみるSPFレコードの具体的な書き方

基本となる構成要素を踏まえ、送信環境に応じた記述パターンを解説します。

送信環境	記述例
単一のIPアドレス	v=spf1 ip4:192.0.2.1 ~all
外部サービス経由	v=spf1 include:example.com ~all
複数の送信元	v=spf1 ip4:192.0.2.1 include:example.com ~all

基本となる3つの構成要素（バージョン・メカニズム・限定子）を把握する

SPFレコードを構成するのは、「v=spf1」「メカニズム」「限定子」の3つの要素です。「v=spf1」はSPFのバージョン1を利用するという宣言です。メカニズムには許可するIPアドレスやドメインを指定します。限定子は各メカニズムの直前に付ける「+（許可）」「-（拒否）」「~（ソフトフェイル）」「?（中立）」の記号で、省略した場合は「+」として扱われます。末尾の「~all」は、「all」というメカニズムに限定子「~」を付けた記述であり、リスト以外のIPアドレスから送られた場合の扱いを定義しているのです。

自社の単一IPアドレスのみを許可する

自社のメールサーバー1台だけから送信している場合は、IPアドレスを直接指定して記述します。具体的には「v=spf1 ip4:192.0.2.1 ~all」のように記載する形式です。この記述は、指定したIPアドレスからの送信を許可し、それ以外からの送信は疑わしいメールとして扱うという意味を持ちます。構造がシンプルで設定ミスが起こりにくい手法です。

メール配信システムなど外部サービス経由の送信を許可する

外部のメール配信システムやクラウドサービスを利用する場合は、include構文を用いてサービス提供者のSPFレコードを参照します。記述例は「v=spf1 include:example.com ~all」です。サービス側で送信元IPアドレスが変更された場合でも、自社のDNS設定を書き換える手間がかかりません。多くのSaaSベンダーが自社サービスのドメインを指定するよう案内しています。

なお、include構文で指定できるのは、SPFに標準対応しているサービスに限られます。ツールを選ぶ段階であれば、SPFやDKIMへの標準対応が明記されているか、指定すべきincludeドメインが案内されているかを事前に確認しておくと設定の手戻りを防げるでしょう。

メール配信システムの仕組みとは？わかりやすく解説！

複数の送信元がある場合はレコードを1行にまとめる

自社サーバーと外部システムの両方を利用している場合は、すべての許可リストを半角スペースで区切って1行で記述します。「v=spf1 ip4:192.0.2.1 include:example.com ~all」のように並べて記載するのが基本です。複数行に分けてSPFレコードを登録すると恒久的なエラー（permerror）となり、認証が正しく行われないため注意が必要です。

SPFレコードをDNSサーバーへ設定する手順

送信元サーバーの洗い出しから、DNSサーバーへの追加までの手順を順番に紹介します。

手順	実施内容
1.送信元の洗い出し	メール送信に利用しているシステムとIPアドレスをすべて特定する
2.管理画面へログイン	契約しているDNSサーバーの管理画面にアクセスする
3.TXTレコードの追加	特定した情報をもとにSPFレコードを記述して登録する

自社で利用中のすべての送信元サーバー情報を洗い出す

設定を始める前に、自社ドメインを使ってメールを送信しているすべてのシステムをリストアップします。社内のメールサーバーだけでなく、マーケティング用の配信システムや勤怠管理システムの自動通知なども対象です。漏れがあると、そのシステムから送られたメールがなりすましの疑いがあるものとして扱われるおそれがあります。各サービスの管理画面やマニュアルから、指定するIPアドレスやincludeドメインを確認します。

契約中のDNSサーバー管理画面へログインする

必要な情報が揃ったら、自社ドメインを管理しているDNSサーバーの管理画面にアクセスします。レンタルサーバーを利用している場合は、サーバーのコントロールパネルからDNS設定画面を開くのが一般的です。クラウド事業者が提供する専用のDNSサービスを利用している場合は、該当サービスの管理コンソールにログインします。権限がない場合は、社内のネットワーク管理者に作業を依頼します。

新規のTXTレコードとしてSPFの記述を追加する

DNSの設定画面から新規レコードの追加画面を開き、種類として「TXT」を選択します。ホスト名（または名前）の欄は空欄にするか「@」を入力し、値の欄に先ほど作成したSPFレコードを記述する流れです。設定を保存するとDNSサーバーに変更が反映されます。インターネット全体に情報が行き渡るまでの時間は、レコードに設定されたTTL（キャッシュの有効期間）に依存します。TTLが長いほど古い情報が参照され続けるため、反映まで時間がかかるケースも珍しくありません。

正しく設定できたか確認するには？

設定完了後にエラーや記述ミスがないかを確認する方法を3つ紹介します。

確認方法	特徴・用途
Webチェックツール	ブラウザ上でドメインを入力するだけで構文エラーを診断できる
nslookupコマンド	コマンドプロンプトを用いてDNSサーバーの応答を直接確認できる
テストメールの送信	実際のメールヘッダーを確認して最終的な認証結果を判定する

無料のWebチェックツールで構文エラーがないか診断する

設定後すぐに確認したい場合は、ブラウザ上で利用できる無料のSPFチェックツールを活用します。「MxToolbox」などのサイトに自社ドメインを入力すると、DNS上に登録されたSPFレコードが瞬時に表示される仕組みです。構文エラーの有無やルックアップ回数も同時に診断されるため、記述ミスにいち早く気づけます。

参考：SPF Check & SPF Lookup - Sender Policy Framework (SPF) - MxToolbox

コマンドプロンプトのnslookupコマンドでDNS応答を確かめる

Windowsのコマンドプロンプトを利用すれば、外部ツールを使わずにDNSの応答を確認できます。「nslookup -type=TXT example.com」と入力して実行すると、TXTレコードの内容が直接返ってくる仕様です。自身が設定した「v=spf1〜」から始まる文字列が正しく表示されていれば、DNSへの登録自体は成功しています。

参考：nslookup|Microsoft Learn

実際のテストメールを送信してヘッダー情報の認証結果を見る

設定が反映された後、実際のテストメールを外部のメールアドレス宛に送信して確認します。受信したメールの詳細メニューから「メッセージのソースを表示」などの項目を開き、メールヘッダーを確認する作業です。「spf=pass」と記載されていれば、認証は正常に完了しています。ここで「fail」や「softfail」と表示された場合は、記述内容やIPアドレスを見直します。

設定時にエラーを引き起こす3つの注意点

設定時に陥りやすいルックアップ回数や文字数の制限など、注意すべきポイントを整理します。

注意点	対応策
ルックアップの回数制限	includeなどの使用によるDNS参照を10回以内に抑える
レコードの重複登録	1つのドメインに対してSPFレコードは必ず1つに統合する
レコードの文字数制限	1つのTXTレコードの文字数を255文字以内に収める

includeなどによるDNSルックアップの回数を10回以内に抑える

SPFレコード内でinclude構文などを使用する場合、DNSルックアップの回数を10回以内に抑える必要があります。DNSルックアップとは、ドメイン名からIPアドレスなどの情報を検索する処理です。たとえば、ブラウザでURLを入力した際に接続先のサーバーを特定するために実行されます。SPFの処理ではこの検索回数が10回を超えるとエラーになるため、利用する外部サービスが増えた際は特に注意が必要です。

1つのドメインに対して複数のSPFレコードを重複して登録しない

1つのドメインに対して、SPFレコード（「v=spf1」から始まるTXTレコード）は1つに統合します。用途別に複数のTXTレコードを作成してそれぞれにSPFを記述すると、受信側はどれを参照すべきか判断できず、認証結果が恒久的なエラー（permerror）となるためです。新しく外部システムを導入する際は、既存のレコードにincludeを追記する形で更新します。

1つのTXTレコードの文字数が255オクテットを超過しないよう調整する

DNSの仕様上、1つのTXTレコードに含まれる「文字列」は255オクテットまでと決められています。これを超える場合は文字列を分割して記述し、受信側が連結して1つのSPFレコードとして解釈する仕組みです。ただしDNSの応答サイズは450オクテット以内に収まることが推奨されているため、不要なIPアドレスを削除するか、別のドメインに分けてincludeで参照させるなどの工夫が有効です。

まとめ

SPFレコードは、自社のメールがなりすましではないことを証明し、メールの到達率を高めるための仕組みです。自社の送信元IPアドレスをDNSに漏れなく登録し、ルックアップ回数や文字数制限に注意してエラーを防ぐことで、メールの信頼性を高く維持できます。

ただし、設定は一度完了すれば終わりではありません。外部サービスの追加や送信元の変更にあわせて見直しが必要で、複数の配信システムを併用していれば、ルックアップ回数の超過や設定漏れにも気を配らなければなりません。設定に不備があると、業務連絡や顧客宛のメールが届かなくなるリスクも生じます。

こうした運用負荷を抑えて確実なメール配信を実現するには、送信ドメイン認証に標準対応したメール配信システムの活用が有効です。「Cuenote FC」は、SPF・DKIMに標準対応し、SPFレコードの設定状況を管理画面から確認できるメール配信システムです。詳細は以下をご確認ください。