メールのなりすましは、インターネット上で最も多い攻撃手法の一つです。攻撃者はあなたのドメインから送信されたように見えるメールを送りますが、実際にはまったく別のサーバーから発信されています。受信者は「From」欄に表示される会社名を見て信頼してしまいます。SPF(Sender Policy Framework)はこの脅威に対する第一の防衛線であり、正しく設定することはドメインのメールセキュリティで最も重要な対策の一つです。

このガイドでは、SPFレコードについて知っておくべきすべて、つまりSPFとは何か、どのように動作するのか、そしてあなたのドメインでどのように設定すればよいのかを解説します。

SPFとは何か、なぜ重要なのか?#

SPF(Sender Policy Framework)は、RFC 7208で定義されているメール認証プロトコルです。ドメイン所有者が、自分のドメインを名乗ってメールを送信できるメールサーバーを指定できる仕組みです。受信側のメールサーバーは、あなたのドメインから来たと主張するメールを受信した際、SPFレコードを確認して、送信元のサーバーが正規に認可されているかを検証します。

SPFが重要な理由#

SPFレコードがないと、誰でもあなたのドメインから送信されたように見えるメールを送れてしまいます。これはいくつかの深刻な問題を引き起こします。

メールのなりすましとフィッシング: 攻撃者があなたのブランドになりすまし、顧客・取引先・従業員を騙して機密情報を引き出したり、悪意のあるリンクをクリックさせたりする可能性があります。
配信性能への悪影響: Gmail、Outlook、Yahooといった主要メールプロバイダーは、メールを受信トレイに届けるか迷惑メールに振り分けるかを判断する際の指標としてSPFを利用しています。SPFレコードがないドメインは、正規のメールでもフィルタリングされやすくなります。
ブランドレピュテーションの低下: スパム送信者があなたのドメインを使って大量の迷惑メールを送ると、メールプロバイダーのネットワーク全体でドメインのレピュテーションスコアが下がります。これは正規の業務連絡を含め、すべての送信メールの配信性能に影響します。
コンプライアンス要件: 多くの業界標準や規制では、組織にメール認証の実装が求められています。SPFはその基本となります。

SPFの仕組み#

SPFの動作原理を理解しておくと、正しく設定でき、問題が起きたときのトラブルシューティングにも役立ちます。

SPFチェックのプロセス#

あなたの組織が、認可されたメールサーバーからyou@yourdomain.comとしてメールを送信します。
受信側のメールサーバーが、エンベロープ送信者(Return-Pathヘッダ。Fromヘッダではありません)からドメイン部分を取り出します。
受信側サーバーはyourdomain.comに対してDNS TXTルックアップを実行し、SPFレコードを取得します。
サーバーは、送信元のIPアドレスをSPFレコードに記載された認可済みIPおよびホスト名のリストと照合します。
照合結果に基づき、サーバーは次のいずれかの結果を返します。
- Pass: 送信元サーバーは認可されています。メールはそのまま処理されます。
- Fail: 送信元サーバーは認可されておらず、ドメイン所有者は明示的に拒否を求めています。
- SoftFail: 送信元サーバーは認可されていませんが、ドメイン所有者はまだ完全に拒否を求めるほど自信がありません。通常はメールを受け入れつつフラグを立てます。
- Neutral: ドメイン所有者は送信元サーバーについて何も主張しません。

SPFレコードのフォーマット#

SPFレコードは、ドメインに公開されるDNS TXTレコードです。次のような構文に従います。

v=spf1 [mechanisms] [qualifier]

v=spf1は必須で、このレコードがSPFバージョン1であることを示します。
メカニズム(mechanisms)はどのサーバーが認可されているかを定義します。
末尾のクオリファイア(qualifier)は、どのメカニズムにも一致しないサーバーに対する既定のポリシーを定義します。

実例は次のとおりです。

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

このレコードは、「Googleのメールサーバー、SendGridのメールサーバー、および特定IPアドレス203.0.113.50からの送信を許可し、それ以外は拒否する」ことを意味します。

SPF設定のステップバイステップ#

以下の手順に沿って、ドメインのSPFレコードを作成・公開しましょう。

ステップ1: メール送信サービスをすべて洗い出す#

SPFレコードを書く前に、あなたのドメインを名乗ってメールを送信しているサービスやサーバーをすべてリストアップする必要があります。これは最も見落とされやすい手順で、送信元を漏らすとそのメールはSPFチェックに失敗してしまいます。

代表的なメール送信元には以下のようなものがあります。

メールプロバイダー: Google Workspace、Microsoft 365、Zoho Mail、ProtonMailなど。
トランザクションメールサービス: SendGrid、Mailgun、Amazon SES、Postmark、Resendなど。
マーケティングメール基盤: Mailchimp、HubSpot、ActiveCampaign、ConvertKitなど。
Webサーバー: お問い合わせフォーム、パスワードリセット、注文確認などでサイトが直接メールを送信している場合。
CRM・サポートツール: Zendesk、Freshdesk、Intercom、Salesforceなど。
その他のSaaSツール: あなたのドメインからメールを送るすべてのアプリケーション。

すべてのサービスを書き出しましょう。社内のいろいろな部署にも確認してください。マーケティング部門が使っているプラットフォームをエンジニアリング部門が知らないこともあれば、その逆もあります。

ステップ2: SPFのインクルード値を集める#

各メールサービスプロバイダーは独自のSPFインクルードドメインを公開しています。主要プロバイダーのインクルード値は次のとおりです。

プロバイダー	SPFインクルード
Google Workspace	`include:_spf.google.com`
Microsoft 365	`include:spf.protection.outlook.com`
SendGrid	`include:sendgrid.net`
Mailgun	`include:mailgun.org`
Amazon SES	`include:amazonses.com`
Mailchimp	`include:servers.mcsv.net`
Postmark	`include:spf.mtasv.net`
Zoho Mail	`include:zoho.com`
HubSpot	`include:hubspot-email.com`
Freshdesk	`include:email.freshdesk.com`

正確なインクルード値はプロバイダーのドキュメントで確認してください。プロバイダーは時々これらを更新するため、必ず最新のドキュメントを参照しましょう。

ステップ3: SPFレコードを組み立てる#

バージョンタグ、すべてのインクルードメカニズム、クオリファイアを1つのレコードにまとめます。

テンプレート:

v=spf1 [include:provider1] [include:provider2] [ip4:your.server.ip] [qualifier]

Google WorkspaceとSendGridを使う企業の例:

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

Microsoft 365、Mailchimp、独自メールサーバーを使う企業の例:

v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net ip4:198.51.100.25 -all

ステップ4: クオリファイアを選ぶ#

SPFレコードの末尾にあるクオリファイアは、レコードに記載されていないサーバーから送信された場合の挙動を定義します。

-all(Fail): 認可されていないサーバーからのメールは拒否すべき、という意味です。最大限の保護を得るための推奨設定です。リストの完全性に自信があり、未掲載サーバーからのメールは詐欺だと宣言することになります。
~all(SoftFail): 認可されていないサーバーは疑わしいものの、完全に拒否はしない、という意味です。すべての正規送信元を洗い出し終える前の初期セットアップやテスト期間に使います。
?all(Neutral): 何の主張もしません。保護効果はほぼなく、推奨されません。
+all(Pass): 全員を許可します。SPFの目的を完全に台無しにしてしまうため、絶対に使用しないでください。

おすすめ: 初期導入とテスト期間中は~allから始め、すべての正規メールがSPFチェックを通ることを確認できたら-allに切り替えて、本格的な保護を有効にしましょう。

ステップ5: DNSにレコードを公開する#

DNSプロバイダー(Cloudflare、Route53、GoDaddy、Namecheapなど)にログインし、TXTレコードを追加または更新します。

ドメインのDNS管理画面にアクセスします。
新しいTXTレコードを追加するか、既存のSPFレコードを編集します。
Host/Nameを@に設定します(これはルートドメインを表します)。
Value/Contentに完成したSPFレコードの文字列を設定します。
TTLは3600(1時間)、またはプロバイダーの既定値に設定します。
レコードを保存します。

DNSの変更が世界中に伝播するには最大48時間かかることがありますが、多くは15分〜1時間ほどで反映されます。

ステップ6: SPFレコードを検証する#

公開後は、レコードが正しく設定されているかを検証しましょう。Nova Uptime メール配信ヘルスチェッカーを使えば、SPF検証を含むドメインのメール設定を総合的にチェックできます。SPFレコードの構文確認、クオリファイアポリシーの評価、DNSルックアップ数の集計、潜在的な問題の検出を行います。

コマンドラインからも確認できます。

dig TXT yourdomain.com +short

または

nslookup -type=TXT yourdomain.com

v=spf1で始まるTXTレコードを探してください。期待しているインクルードメカニズムがすべて含まれており、クオリファイアが正しいかを確認します。

SPFメカニズムを理解する#

SPFレコードは、認可された送信元を柔軟に定義できる複数のメカニズムタイプをサポートしています。

`include`

別ドメインのSPFレコードを参照します。メールサービスプロバイダーが自社の認可IPレンジを公開する手段として、最もよく使われるメカニズムです。

include:_spf.google.com

受信サーバーはこれに出会うと、追加のDNSルックアップを行ってGoogleのSPFレコードを取得し、送信元IPがGoogleの認可レンジに含まれているかを照合します。

`ip4` と `ip6`

メール送信を許可する個別のIPアドレスやCIDRレンジを指定します。

ip4:203.0.113.50
ip4:198.51.100.0/24
ip6:2001:db8::/32

自社のメールサーバーや、特定のIPアドレスが分かっているサービスに対して使います。

`a`

ドメインのAレコードが指すIPアドレスを認可します。Webサーバーがメールも送信する場合に、簡潔に許可できる方法です。

`mx`

ドメインのMX(メール交換)サーバーのIPアドレスを認可します。MXサーバーは受信用ですが、返信・バウンス・転送など送信が必要になることも多いため、よく使われます。

mx

`redirect`

自分のSPFレコードを完全に置き換える形で、別ドメインのSPFレコードを参照します。補完するincludeと異なり、置換になる点が違います。

redirect=_spf.example.com

ありがちなSPFの間違いと回避方法#

間違い1: 10回のDNSルックアップ上限を超える#

SPFの仕様(RFC 7208)では、DNSルックアップの合計を10回までに制限しています。include、a、mx、redirectの各メカニズムが1回ずつカウントされ、ネストされたインクルード(さらにインクルードを含むインクルード)もこの上限に含まれます。

10回を超えると、SPFチェックはPermErrorを返し、多くの受信サーバーはSPFレコードがない状態と同じように扱います。

修正方法:

可能な限りincludeをip4/ip6に置き換えます(IP系メカニズムはDNSルックアップにカウントされません)。
SPFフラット化ツールを使って、インクルードを実際のIPアドレスに展開します。
可能であればメールサービスを統合します。
使わなくなったサービスのインクルードを削除します。

間違い2: SPFレコードを複数公開してしまう#

ドメインに公開できるSPFレコードは1つだけです。v=spf1で始まるTXTレコードが2つあると、SPFチェックはPermErrorを返します。これは、既存のSPFレコードを削除・更新せずに新しいSPFレコードを追加してしまったときによく起こります。

修正方法: すべての認可送信元を1つのSPFレコードにまとめます。

誤り:

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

正しい例:

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

間違い3: `+all` を使う

クオリファイアに+allを設定すると、世界中のすべてのサーバーがあなたのドメインを名乗ってメールを送信できることになってしまいます。SPFの目的を完全に否定する重大なセキュリティリスクです。

間違い4: プロバイダー変更後に更新を忘れる#

メールプロバイダーを切り替えたり、マーケティング基盤を移行したり、新しいSaaSツールを追加したりする際は、SPFレコードを更新する必要があります。使わなくなったサービスのインクルードはDNSルックアップを無駄に消費し、新しいサービスのインクルードを欠くと正規メールがSPFチェックに失敗します。

間違い5: 変更後のテストを怠る#

SPFレコードを変更したら、必ずテストしてください。すべてのサービスからテストメールを送り、SPFチェックを通過していることを確認します。Nova Uptime メール配信ヘルスチェッカーなどのツールで、レコードの構文と設定を検証しましょう。

SPFとメール認証の全体像#

SPFは、メール認証における3大プロトコルの一つです。包括的な保護を実現するには、3つすべてを実装するべきです。

SPF + DKIM + DMARC#

SPFは、送信元サーバーがそのドメインに対して認可されているかを検証します。
DKIM(DomainKeys Identified Mail)は送信メールに暗号署名を付与し、メッセージが転送中に改ざんされていないこと、そして認可された送信者によって送られたことを保証します。
DMARC(Domain-based Message Authentication, Reporting, and Conformance)は、SPFとDKIMをまとめ、認証に失敗した場合に受信サーバーが取るべき行動をポリシーとして指定します。さらにレポート機能により、誰があなたのドメインを名乗ってメールを送っているかを把握できます。

これら3つのプロトコルを組み合わせることで、なりすましやフィッシングに対する強固な保護が実現します。SPFだけでも有力な出発点になりますが、DKIMやDMARCと併用することで真価を発揮します。

SPFレコードのテスト#

SPFレコードを設定したら、入念にテストすることが重要です。テスト用のチェックリストを以下に示します。

DNS検証: DNSルックアップツールでレコードが存在し、構文が正しいことを確認します。
テストメールの送信: 認可されたすべてのサービスからメールを送り、受信側のメールヘッダでspf=passになっていることを確認します。
ルックアップ数の確認: DNSルックアップの合計が10回以下であることを確認します。
SPFレコードが1つだけであることの確認: SPFのTXTレコードが重複していないかを確認します。
未認可サーバーからのテスト: 可能であれば、未認可の送信元からメールを送り、SPFがFailまたはSoftFailになることを確認します。

Nova Uptime メール配信ヘルスチェッカーは、これらのチェックの大半を自動化します。ドメインを入力するだけで、SPFレコードのポリシー強度、構文上の問題、改善提案などを含むレポートを瞬時に得られます。DKIMやDMARCの設定もあわせてチェックできるので、メール認証の状況を一画面で把握できます。

SPFレコードの運用#

SPFは「設定したら終わり」ではありません。定期的なレビューを計画しましょう。

四半期ごとの監査: 現在のメール送信サービス一覧と照らし合わせ、不要なインクルードを削除し、新しいインクルードを追加します。
インフラ変更時: メールサービスプロバイダーを追加・削除・変更したときは、すぐにSPFレコードを更新します。
配信トラブル発生時: メールが迷惑メールに入るようになったら、まずSPFレコードを確認してください。設定ミスはよくある原因です。
自動モニタリング: メール配信ヘルスを継続的に監視するツールを使い、SPF設定が壊れた際にアラートを受け取れるようにしましょう。

まとめ

SPFを正しく設定することは、ドメインのメールセキュリティと配信性能を高めるうえで、最も費用対効果の高い改善策の一つです。要点を振り返ります。

ドメインを名乗ってメールを送るすべてのサービスをリストアップする。
それぞれのSPFインクルード値を収集する。
認可された送信元すべてを統合した、1つのSPFレコードを作る。
まず~allから始め、すべて問題なく動作することを確認したら-allへ昇格する。
TXTレコードをDNSに公開する。
Nova Uptime メール配信ヘルスチェッカーで検証する。
四半期ごとにレビューと更新を行う。

メールのレピュテーションは何ヶ月もかけて積み上げますが、わずか数日で台無しになることもあります。適切に設定されたSPFレコードは、その土台を守る基盤となります。

よくある質問

SPFレコードはどうやって確認しますか?#

無料のSPFチェッカーツールで、SPFレコードを取得・検証できます。ドメインを入力すると、TXTレコードへのDNSクエリ、構文の検証、DNSルックアップ数のカウント(最大10回まで許可)、ポリシー強度のチェックを行います。dig TXT yourdomain.comやnslookup -type=TXT yourdomain.comでも確認できます。

SPFチェックは何をしているのですか?#

SPFチェックは、あなたのドメインを名乗ってメールを送信しているサーバーが、SPF DNSレコードで認可されているかを検証します。受信側のメールサーバーはこのチェックを自動的に行います。送信元IPがSPFレコードに記載されていない場合、メールはDMARCポリシーに応じてスパム扱いになったり、拒否されたりします。

SPFレコードはどのようにテストしますか?#

SPFレコードを公開した後、(1)無料のSPFチェックを実行する、(2)Gmailにテストメールを送信し「メッセージのソースを表示」のヘッダでspf=passを確認する、(3)nslookup -type=TXT yourdomain.comでレコードが正しく公開されているかを確認する、といった方法でテストできます。

SPFの10ルックアップ上限とは何ですか?#

SPFレコードはDNSルックアップが10回までに制限されています。include:、a:、mx:、ptr:、redirect=の各メカニズムが1回ずつカウントされます。上限を超えると恒久的なSPF失敗(permerror)となり、すべてのメールがSPFチェックに失敗してしまいます。SPFチェッカーで現在のルックアップ数を確認しましょう。

SPFレコードでは`-all`と`~all`のどちらを使うべきですか?

最大限の保護には-all(ハードフェイル)を使い、未認可の送信元からのメールを受信サーバーに拒否させます。初期セットアップや移行期間中は~all(ソフトフェイル)を使い、すべての正規送信元が含まれていることを確認したら-allに切り替えます。私たちのメール配信ヘルスチェッカーはSPFポリシーをチェックし、適切な設定を提案します。

SPFレコードのルックアップと検証ガイド — 高度なSPF設定とトラブルシューティング
SPF・DKIM・DMARC完全ガイド — 認証スタック全体におけるSPFの位置づけ
メール配信性能チェックリスト — SPF設定を含む15のステップ
DMARC設定: noneからrejectへ — SPF完了後のDMARC設定
無料SPFチェッカー — SPFレコードを瞬時に検証