DNS SPFレコード：仕組みと設定方法

組織から送信されるすべてのメールには、そのドメインの評判が反映されます。SPFレコードの設定に誤りがあったり、そもそも設定されていなかったりすると、受信サーバーは、そのメールが実際に貴社から送信されたものであることを確実に確認する手段を失ってしまいます。その結果、正当なメールがスパムフォルダに振り分けられたり、マーケティングキャンペーンが配信失敗に終わったりするほか、攻撃者が貴社のドメインから送信されたように見せかけたメッセージを送信する恐れもあります。

SPF（Sender Policy Framework）は、3つの主要な 電子メール認証 プロトコルの1つであり、DKIMや DMARCと並び、受信メールサーバーに対して、どのIPアドレスがあなたのドメインを代表してメールを送信する権限を持っているかを伝えるものです。これはDNSのTXTレコードとして公開されます。一見すると単純に見えますが、実際には、SPFこそがほとんどのメール認証の問題の始まりとなる場所なのです。 

このガイドでは、SPFレコードとは何か、SPF検証の仕組みを段階的に解説するほか、SPFレコードの作成方法や、成長中の組織においてメール配信を静かに妨げてしまう「DNSルックアップ10回制限」を含む、最も一般的なSPFエラーの修正方法について詳しく説明します。

DNSのSPFレコードとは何ですか？

DNS SPF（Sender Policy Framework）レコードは、特定のドメインからメールを送信する権限を持つメールサーバーを指定する、DNS TXTレコードの一種です。これにより、受信側のメールサーバーは、受信したメッセージが正当な送信元から送られてきたものであるかを確認でき、なりすましやフィッシングのリスクを低減できます。メールを受信すると、サーバーは送信元ドメインのSPFレコードを確認し、送信元のIPアドレスが許可されているかどうかを検証します。 

そのIPアドレスがリストにない場合、そのメッセージはフラグが立てられたり、拒否されたり、スパムフォルダに振り分けられたりする可能性があります。SPFレコードを適切に設定することで、メールの配信率が向上し、ドメイン認証が強化されます。

無料のSPF検索ツールを使えば、ドメインのSPFレコードを即座に確認できます 無料のSPF検索ツール。所要時間はわずか5秒で、DNSに公開されている内容を正確に確認できます。

SPF認証はどのように機能するのでしょうか？

SPF認証では、メールを受信するたびに、構造化されたDNS検索および検証プロセスが行われます：

• お客様のドメインでは、SPFレコードがDNSのTXTエントリとして公開されています。このレコードは、次のような仕組みを用いて、すべての承認された送信元を定義しています。 ip4、 ip6、 include、および a、およびデフォルトのポリシー（-all、 ~all、または ?all）。
• 電子メールが送信される際、送信サーバーは、配信を担当するドメインを表す「Return-Path」（エンベロープ送信者）アドレスを含めます。
• 受信メールサーバーは、Return-Pathアドレスからドメインを抽出します。
• そのドメインに関連付けられたSPFレコードを取得するために、DNSクエリを実行します。
• その後、送信サーバーのIPアドレスがSPFレコード内の各メカニズムに対して照合され、一致するかポリシー決定が下されるまで順に処理されます。
• SPFでは、過度な再帰を防ぐため、この評価中にDNSルックアップを10回までに制限しています。この制限を超えると、PermErrorが発生します。
• 結果に基づき、SPFは「Pass」、「Fail」、「SoftFail」、「Neutral」、「None」、「PermError」、または「TempError」といった結果を返します。
• 受信サーバーは、この結果とDKIM認証およびDMARCポリシーの適合状況を基に、そのメッセージをどのように処理すべきか（配信、隔離、または拒否）を判断します。

重要な注意点：SPFは、表示される「From」ヘッダーではなく、「Return-Path」（エンベロープ送信者）ドメインを検証します。サードパーティの送信プラットフォームでよくあるように、これらのドメインが異なる場合、SPF検証は通過するかもしれませんが、 DMARCのアラインメント が失敗する可能性があり、これは受信トレイへの配信に直接影響します。

各SPF結果コードには、それぞれ具体的な意味があります：

DMARC集計レポート により、すべての送信元において、どのメールがSPF検証に合格し、どのメールが不合格になったかを正確に把握できます。DMARCレポートがない場合、SPF検証の失敗は黙って発生し、誰かから苦情が来るまで気づくことができません。

SPFレコードの構文と形式について

SPFの構文を理解するには、まずレコード全体を読み、各部分がどのように評価されるかを把握することから始めます。以下に典型的な例を示します：

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ip4:203.0.113.0/24 -all (ここで /24 は、クラスレス・ドメイン間ルーティング（CIDR）表記による256個のIPアドレスの範囲を表します）

この一行の記述により、受信サーバーは、どの送信元があなたのドメインのメール送信を許可されているか、またリストにない送信元があった場合にどう対応すべきかを正確に把握できます。

SPFバージョンタグ (v=spf1)

すべてのSPFレコードは、 v=spf1で始まる必要があります。これにより、そのTXTレコードがSPFポリシーであることが識別されます。これ以外の有効なバージョンはありません。このタグが欠落しているか、不正確な場合、そのレコードは完全に無視されます。

SPFの仕組み（承認済み送信者） 

メカニズムは、誰がメールを送信できるかを定義します。これらは左から右へと評価され、最初に一致したものが結果を決定します。

これには には以下が含まれます： メカニズムは最も一般的に使用されており、最も多くの問題を引き起こすものです。すべての include: は再帰的なDNSルックアップをトリガーします。GoogleのSPFレコードに他の3つのドメインが含まれている場合、それらはすべて10ルックアップという制限にカウントされます。

よく混同される点： SPFの SPFの仕組みは、ドメインのDNS Aレコードを参照するものです。「SPF専用のAレコード」を別途作成するわけではありません。 a をSPFレコードに追加すると、ドメインのAレコードが解決するIPアドレスすべてを承認することになります。

修飾子 (redirect=)

修飾子は、送信者を定義するのではなく、SPF評価の動作を制御します。

• redirect=
  SPF評価全体を別のドメインに移行します。 include:とは異なり、 別のポリシーを 別のポリシーをレコードに追加するのとは異なり、 redirect= は 評価を完全に置き換えます。
  あるドメインが別のドメインのSPF設定を完全に継承する必要がある場合にのみ、これを使用してください。

DNS 検索の制限（重大な制約）

SPFでは、1回の評価につき最大10回のDNS検索が許可されています。以下のような仕組みには には以下が含まれます：、 a, mx, 存在します:、および redirect= はすべて、この制限の対象となります。

制限を超えた場合、SPFはPermErrorを返し、送信者が正当なものであっても認証は失敗します。そのため、大規模で複雑なレコードでは、多くの場合、最適化（未使用のインクルードの削減やフラット化など）が必要となります。

SPF 修飾子（「all」メカニズム）

「 SPFレコードの末尾にある メカニズムに関する記述は、SPFポリシーを定義するものです。つまり、明示的にリストされていないサーバーからのメールに対してどのような処理が行われるかを定めています：

SPFは論理的なルールセットとして機能します。受信サーバーはレコードを左から右へと読み込み、各メカニズムをチェックし、最初の一致が見つかった時点で処理を停止します。一致が見つからない場合は、 all ルールが適用されます。

適切に構成されたSPFレコードとは、以下の通りです：

• 完全版（すべての正当な送信元を含む）
• 効率的（検索範囲内において）
• 厳密（ -all 検証後に使用）

これにより、正確な認証が保証され、メール送信におけるドメインの不正利用が防止されます。

SPFレコードの作成と公開方法

SPFレコードの設定には、正当な送信元をすべて特定し、DNS上で明確に定義し、その設定が期待どおりに機能することを確認する必要があります。以下の5つの手順を順を追って実行してください。

ステップ1：すべての送信元を特定する

ご自身のドメインを名乗ってメールを送信するすべてのサービスをリストアップしてください。これには通常、主要なメールプロバイダー（Google Workspace や Microsoft 365 など）、マーケティングプラットフォーム（Mailchimp や HubSpot など）、顧客関係管理（CRM）システム（Salesforce）、サポートツール（Zendesk）、およびトランザクションメールサービス（SendGrid、Amazon SES）が含まれます。 これらのサービスはそれぞれ異なるインフラからメールを送信するため、すべてを明示的に承認する必要があります。ほとんどのプロバイダーは、ドキュメントにSPFのインクルード値を公開しており、これにより受信サーバーは送信元のIPアドレスを信頼するよう指示されます。

ステップ2：SPFレコードを作成する

SPFレコードは、v=spf1 で始まる1行のTXTエントリです。その後、以下の仕組みを使用して、許可された送信者を定義します：

• include: サードパーティのサービス用（例：include:_spf.google.com）
• ip4: または ip6: 管理対象の特定のIPアドレスまたはIPアドレス範囲
  メカニズムは左から右の順に評価されます。最後に、ポリシーを定義します：
• ~all（ソフトフェイル）は、許可されていない送信者を不審な送信者としてマークします
• -all（ハードフェイル）はそれらを明示的に拒否する

例

v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:198.51.100.0/24 ~all

このレコードは、受信サーバーに対して、どの送信元が許可されているか、およびそれ以外のものをどのように扱うべきかを明確に示します。

ステップ3：DNSにレコードを登録する

ご利用のDNSプロバイダー（Cloudflare、Route 53、GoDaddyなど）にログインします。ルートドメイン用の新しいTXTレコードを作成します：

• ホスト／名前: @ (プロバイダによっては空欄のままでも可)
• 値：完全なSPFレコード
  保存されると、そのレコードはDNSを通じて一般に公開されます。変更内容が反映されるまで時間がかかる場合があります。

ステップ4：レコードの検証

公開後、以下の点を確認してください：

• SPFレコードの形式は正しく、構文エラーはありません
• すべてが正常に解決されました
• DNS 検索の合計数が 10 件を超えないこと（上限を超えた場合、SPF は PermError を返して失敗します）

検証を行うことで、受信サーバーがエラーなく確実にレコードを処理できるようになります。

ステップ5：SPFの結果を確認する

SPFの設定は一度行えば終わりというものではありません。送信元を追加または削除するたびに、SPFレコードを更新する必要があります。パフォーマンスを監視するには：

• 有効にする DMARC を有効にして、SPFの合格率・不合格率を示す集計レポートを受信する
• どのソースが認証に合格し、どのソースが不合格になっているかを確認する
• 使用されていないサービスを削除し、不適切な送信元や不正な送信元を修正する

重要： ドメインごとにSPFレコードは1つしか設定できません。 v=spf1 で始まるTXTレコードが複数存在する場合、SPF評価はPermErrorで完全に失敗します。送信元は常に1つの完全なレコードに統合してください。

SPF 10のDNSルックアップ制限（そしてそれがメール配信を妨げる理由）

SPFの評価には制限があります。RFC 7208に基づき、受信サーバーはSPFレコードの処理中に最大10回のDNSルックアップしか実行できません。この制限を超えた場合、SPFはPermError（恒久的なエラー）を返し、チェックは完全に失敗します。

これは部分的な失敗ではありません。「PermError」とは、SPFがまったく評価できないことを意味します。その結果、送信者が正当なものであっても、そのドメインから送信されるすべてのメールがSPF認証に失敗することになります。

10回の検索制限には何が含まれますか？

以下のメカニズムがDNS検索をトリガーします：

• （最も一般的で、最も影響力の大きいもの）
• a
• エムオーエス
• ptr（非推奨ですが、使用された場合はカウントされます）
• 存在します：
• リダイレクト=

ip4: および ip6: メカニズムは、DNS 解決を必要とせず IP アドレスを直接参照するため、検索制限の対象には含まれません

なぜこの制限を超えやすいのか

主な問題は、ネストされた（再帰的な）検索に起因しています。

「include:」を追加すると、単に1つのルックアップを追加するだけでなく、そのプロバイダーのSPFレコードに含まれるすべての情報を継承することになります。

例えば、以下のように。

• Google を追加すると → Google の SPF に他の複数のドメインが含まれる場合があります
• Microsoft 365 を含める → さらにいくつかのルックアップが追加されます
• マーケティングツールやトランザクションツールを導入すると、それぞれが独自のチェーンを追加します

これらはあっという間に積み重なります。レコードが短く見えても、評価時に実際の検索回数が10回を超えることがあります。

「void 型へのルックアップ」の制限（見落とされがちな点）

SPFでは、無効なルックアップが2回までという制限も設けられています。

DNSクエリの結果が何も返されない場合（存在しないドメイン（NXDOMAIN）または空の応答）、空のルックアップが発生します。

一般的な原因

• 不正確または古い情報には、ドメイン名などが含まれます
• SPFメカニズムにおける誤記
• 存在しなくなったドメインへの参照

無効なルックアップが3回以上発生した場合、SPFは再びPermErrorを返します。

A PermError は、「一部の送信者では失敗する」という意味ではありません。その意味は：

• SPFは無効と見なされます
• 受信サーバーは、あなたのSPFポリシーを信頼できません
• SPFは実質的に保護や認証の機能を提供しない

SPFはDMARCで使用されるシグナルの一つであるため、これにより次のような事態も引き起こされる可能性があります：

• DMARCの失敗（DKIMが整合しない場合）
• スパム掲載の増加
• より厳格な受信者によるメッセージの拒否

メール環境が拡大するにつれ、SPFレコードは当然ながら複雑になっていきます。適切な管理を行わないと：

• ルックアップ回数が気づかないうちに増加する
• 使用されていないサービスがレコードに残っている
• エラーは時間の経過とともに蓄積される

SPFにはこうした脆弱性があります。SPFが確実に機能するのは、記録が規定の範囲内に収まり、正確であり、かつ継続的に管理されている場合に限られます。

制限に達するまでの速さ（実例）

中堅企業向けのSaaSスタックにおけるDNSルックアップの一般的な構成は、以下の通りです：

ZendeskやSendGrid、ヘルプデスク、給与計算サービスなどはまだ追加していないはずです。もし貴社でGoogle Workspaceに加え、メール送信機能を持つSaaSツールを4～5つ利用しているなら、すでに上限に達しているか、それを超えている可能性が高いでしょう。

SPFルックアップの制限に関する問題を解決する方法

SPFレコードが10回のDNSルックアップ制限を超えている場合、正当な送信元を阻害することなく、その複雑さを軽減する必要があります。以下に、影響の大きい順に3つの実用的なアプローチを示します：

不要な仕組みを削除する

まずはSPFレコードの徹底的な監査から始めましょう。

• すべての 以下を含める： および現在リストされているすべての仕組み
• 各サービスが、引き続きお客様のドメイン宛てにメールを正常に送信しているかどうかを確認してください
• 使わなくなったものはすべて処分してください

よくある問題：

• 記録に残された古いマーケティング手法
• サブドメイン間で重複するインクルード
• テスト用または一時的なサービスが削除されていない

未使用の include: を削除すれば、1つ以上のDNSルックアップを即座に解放できます。これは制限値内に収めるための最も簡単でリスクの低い方法です。

置き換える include: を ip4:/ip6: 可能な場合は

送信者が決まった少数のIPアドレスセットを使用している場合、その include: を直接のIPエントリに置き換えることができます。

• 例： include:vendor.com を ip4:x.x.x.x
• これにより、その送信者に対するDNS検索が完全に無効化されます

これがうまくいくのは、次のような場合です：

• 内部インフラ
• プロバイダーが提供する専用IPアドレス
• IPアドレス範囲が明確に文書化され、安定しているベンダー

考慮すべきトレードオフ：

• メンテナンスの責任を負う
• プロバイダーがIPアドレスを更新またはローテーションした場合、SPFレコードは古くなってしまいます
• 修正されるまで、SPFの検出されないエラーが発生する可能性があります

IPアドレスの安定性が予測できる場合にのみ、これを使用してください。

使用方法 SPFフラット化 またはSPFマクロ

複数のサードパーティ製サービスを利用している場合、手動でのクリーンアップだけでは通常不十分です。カバレッジを損なうことなく、ルックアップの回数を減らす方法が必要です。

SPFフラット化

• すべてを解決します 以下を含む： メカニズムを、それらに対応するIPアドレスに変換する
• それらを以下のフラットなリストに置き換えます ip4: / ip6: エントリ
• ほとんどのDNS検索を不要にします

制限事項：

• フラット化されたレコードは静的である
• プロバイダー（GoogleやMicrosoftなど）が送信元IPアドレスを更新しても、レコードは自動的に更新されません
• これにより、正当なメールが事前の警告なしにSPF検証に失敗する可能性がある

SPFマクロ（動的代替案）

• 検索の深さを制御しつつ、SPF評価を動的に維持する
• 長いインクルードチェーンへの依存を減らす
• 送信者インフラが頻繁に変更される環境に適しています

 

SPFレコードで何回ルックアップが行われているか分からない？当社の無料SPFチェッカーでルックアップ回数を確認しましょう

手動でのDNS管理を行わずに、10件のルックアップ制限内に収める必要がある組織向けに、PowerDMARCの PowerSPF は、従来の フラット化 と最新のSPFマクロの両方を提供しており、お客様の環境に適した手法を選択できます。サードパーティプロバイダーが許可されたIP範囲を変更した場合、レコードは自動的に更新されます。

なぜSPFだけでは不十分なのか

SPFは基本的な認証方式ですが、現代のなりすましや悪用から完全に防御するようには設計されていません。SPFには3つの根本的な制限があり、それだけでは不十分です。

制限事項 1：SPF は「From」ヘッダーではなく、エンベロープの送信者を確認します

SPFは、メール送信時に使用されるドメインであるReturn-Path（エンベロープ送信者）を検証します。しかし、ユーザーにはFromヘッダーが表示され、その内容は異なる場合があります。

これにより、攻撃者が悪用できる隙が生まれます：

• 攻撃者は、自身のドメイン（SPFを通過する）からメールを送信する
• 「差出人」の表示名を、あなたのドメインまたは信頼できる個人のものになるように設定します
• 送信ドメインが正当なものであるため、SPFチェックに合格します
• 受信者には依然として偽装された送信元が表示される

SPFには、送信ドメインが表示されている送信者と一致しているかどうかを確認する組み込みの仕組みがありません。DMARCは、 SPF（またはDKIM）とFromヘッダーのドメインとの整合性を を強制することで、この問題を解決します。

制限事項 2：SPFはメール転送時に機能しなくなる

SPFは送信サーバーのIPアドレスに基づいて機能します。メールが転送された場合：

• 転送サーバーが新しい送信元となります
• そのIPアドレスは、元のドメインのSPFレコードと照合されます。転送サーバーは承認された送信者としてリストされていないため、SPF検証に失敗します。
• リストにないため、SPFは失敗します

これは、メールが完全に正当なものであっても発生します。これは設定ミスではなく、SPFの仕組み上の制限によるものです。

影響：

• 正当な転送メールでも、SPFの検証に失敗することがよくあります
• 受信システムは、メッセージの有効性を確認するために、他の信号（DKIMなど）に依存する必要があります

制限事項 3：SPF自体には報告機能がない

SPFには、組み込みのレポート機能は備わっていません。

追加のレイヤーがない場合：

• どの送信元がSPFを通過し、どの送信元が失敗しているのかは分かりません
• ご自身のドメインを使用して、不正な送信者を特定することはできません
• 配信率に影響を与える認証に関する問題について、状況を把握できていません

DMARCにはレポート機能が追加され、すべての受信サーバーにおけるSPFおよびDKIMの結果に関する集計データが提供されます。

転送機能、メーリングリスト、サードパーティの送信者、高度ななりすまし攻撃などを備えた現代のメールインフラは、SPFだけでは対応しきれないほど複雑化しています。 DKIM は、転送後も有効な暗号署名を追加することで、SPFの最大の弱点を解決します。 DMARC は、SPF と DKIM を From ヘッダーに結びつけるポリシー層です。

これらのプロトコルがどのように連携して機能するかについての詳細な比較については、当社のガイド「 SPF vs DKIM vs DMARCをご覧ください。

SPFレコードによくある間違い（とその修正方法）

SPFの失敗の多くは、いくつかの繰り返し発生する問題に起因しています。その原因は、主にメンテナンスや検証の不備にあります。ここでは、具体的な対策を通じて、それらの問題を特定し、解決する方法をご紹介します。

間違いその1：同じドメインに複数のSPFレコードが存在する。

SPFでは、単一の権威あるポリシーが必要です。複数のTXTレコードが v=spf1で始まるTXTレコードが複数存在する場合、受信サーバーはどのレコードを評価すべきかを判断できません。その結果、PermErrorが発生し、すべてのメッセージに対してSPF検証が完全に失敗することになります。

その理由：

• 各チーム（マーケティング、IT、サポートツールなど）が独自にレコードを追加します
• 新しいベンダーは、既存の設定を確認せずに「このレコードを追加する」という手順を提供している

どうすればいいのか：

• ドメインのすべてのTXTレコードを監査する
• SPFに関連するすべてのエントリを特定する
• すべてのメカニズムを1つの完全な記録に統合する

注目すべき点：

• 移住後に残された断片的な記録
• ルートドメインの代わりにサブドメインが誤って使用されている 

間違いその2：10-DNS-lookupの制限を超える

SPFの評価においてDNSルックアップが10回を超えると、直ちに処理が中止され、PermErrorが返されます。これにより、正当な送信者であっても、すべての送信者に対するSPFが無効となります。

その理由：

• の使いすぎ には以下が含まれます： 複数のSaaSツールに対して
• プロバイダーからのネストされたインクルード（あるプロバイダーをインクルードすると、そこからさらに別のプロバイダーがインクルードされる）
• 累積検索回数の把握ができない

どうすればいいのか：

• あらゆるメカニズムとその検索への影響を洗い出す
• まず、使用されていない、または重複しているインクルードを削除してください
• すべてのツールが、本当に自社のドメインから送信する必要があるかどうかを再検討してください

注目すべき点：

• サードパーティ製インクルードファイル内の「隠れた」参照
• 新しいツールが追加されるにつれて、徐々に機能が充実していく

間違いその3： +all (すべて渡す)

これにより、受信サーバーに対して送信元をすべて信頼するよう明示的に指示することになり、事実上、SPFをセキュリティ対策として無効化することになります。

その理由：

• SPF構文の誤解釈
• 一時的なテスト構成が元に戻らなかった

どうすればいいのか：

• 以下に置き換えてください ~すべて 設定の検証中に
• 移動先 -すべて すべての正当な送信者が確認され次第

注目すべき点：

• 信頼性の低い情報源から転記された古い記録
• 「認証済み」と表示されるものの、実際には保護機能がないドメイン

間違い4：非推奨の ptr メカニズムの使用

次のような仕組み ptr のようなメカニズムは、検索処理を遅くし、信頼性を低下させるため、最新の受信側によって無視される可能性があり、その結果、SPFの結果に一貫性がなくなる恐れがあります。

その理由：

• 長年にわたり引き継がれてきた従来の構成
• 古いドキュメントやテンプレート

どうすればいいのか：

• 次のような非推奨の仕組みを削除する ptr
• 明示的な記述に置き換える include: または ip4: / ip6: エントリ

注目すべき点：

• エッジケースに対応しようとして過剰に設計されたレコード
• 明確な利点がないにもかかわらず、複雑さを増す仕組み

間違いその5：正当な送信元が記載されていない

正当なプラットフォームからのメールがSPF検証に失敗すると、次のような問題が生じる可能性があります：

• スパムフォルダに振り分けられるメッセージ
• 配送の遅延または受取拒否
• アラインメントされたフォールバックが存在しない場合のDMARCエラー

その理由：

• SPFを更新せずに新しいツールを追加
• 電子メールシステムを管理するチーム間の連携不足

どうすればいいのか：

• 承認済みの送信元をすべて一元的に管理する
• オンボーディングプロセスの一環としてSPFレコードを追加する――問題が発生してからではなく
• すべてのアクティブな送信者が対象となっていることを定期的に確認してください

注目すべき点：

• トランザクションシステム（請求、アラート）は、見過ごされがちである
• 地域別またはチーム別のツールが個別に送信される

間違い 6：1つのDNS文字列におけるSPFレコードが255文字を超えている

DNSの制限を超えている、または形式が不適切なSPFレコードは、切り捨てられたり誤って解釈されたりすることがあり、その結果、目に見えない障害が発生する可能性があります。

その理由：

• 1つのレコードにインクルードやメカニズムが多すぎる
• 長いTXT値を扱うDNSプロバイダーの対応はそれぞれ異なる

どうすればいいのか：

• 記録はできるだけ簡潔にまとめてください
• 必要に応じて、1つのTXTレコード内に複数の引用符で囲まれた文字列を使用してください
• 保存後、公開されたレコードを再度確認してください（入力内容だけでなく）

注目すべき点：

• DNS管理画面では正しく表示されているが、実際には正しく解決されないレコード
• 手動編集の際に生じた書式の問題

無料のSPFヘルスチェックを実行して、レコードに以下のエラーがないか確認してください

2026年のSPFベストプラクティス

適切なSPFレコードとは、単に構文が正しいということだけではありません。メールインフラの進化に合わせて、常に正確な状態を維持するためのポリシーを確立することが重要です。これらのベストプラクティスを実践することで、SPFの設定が信頼性と効率性を保ち、現代の送信者要件に適合した状態を維持できるようになります。

1. ドメインごとに1つのSPFレコードを維持する

SPFでは、 v=spf1で始まるTXTレコードを1つだけ許可します。複数のレコードがあるとPermErrorが発生し、認証が完全に失敗します。新しいエントリは常に既存のレコードに統合してください。

2. 正当な送信元はすべて含める

SPFレコードには、貴社に代わってメールを送信するすべてのシステムを記載する必要があります。送信元が1つでも漏れるとSPF検証に失敗し、配信率やDMARCのコンプライアンスに直接的な影響を及ぼします。

3. DNS検索の制限数（10回）を超えないようにする

各 には以下を含める：, a、 mx, 存在します:、および redirect= は制限にカウントされます。10件を超えるとPermErrorが発生し、すべてのメールのSPFが無効になります。定期的にレコードを監査し、最適化してください。

4. 使用されていない、または古くなったインクルードファイルを除去する

古いツール、テスト環境、および廃止予定のサービスは、送信が停止した後も、SPFレコードに残ったままになることがよくあります。これらは不要な複雑さを生み出し、ルックアップの割り当てを消費してしまいます。

5. 優先する IPv4: および ip6: 管理対象インフラには

専用IPアドレスや安定した送信範囲を管理している場合は、 include:を使用しないでください。これにより、DNS ルックアップが削減され、パフォーマンスが向上します。

6. 以下の使用は避けてください +all は、いかなる状況でも使用しないでください

以下の +all 修飾子を使用すると、どのサーバーでもあなたのドメインを名乗ってメールを送信できるようになり、事実上、SPFによるセキュリティ対策が無効化されてしまいます。本番環境では絶対に使用しないでください。

7. 使用 セットアップ中に を使用し、その後 -all

まずは 設定の検証中は (softfail) から設定の検証を開始してください。正当な送信者がすべて確認され、DMARCに準拠していることが確認できたら、 -all (ハードフェイル)に切り替えて厳格に適用してください。

8. 以下のような非推奨またはリスクの高い仕組みは避ける ptr

The ptr メカニズムは非推奨であり、信頼性が低いです。不要なDNSルックアップを引き起こす可能性があり、最新の受信側では無視される場合があります。代わりに明示的なメカニズムを使用してください。

9. DMARCレポートを用いてSPFの有効性を監視する

SPFだけでは可視化はできません。DMARCレポート機能を有効にすることで、すべての受信サーバーにおいてどの送信元がSPFの検証に合格・不合格となっているかを追跡し、不正な活動を特定することができます。

10. SPFを継続的に管理されるシステムとして扱う

SPFの設定は一度行えば終わりというものではありません。メールを送信する新しいツール、プラットフォーム、またはベンダーが追加されるたびに、その情報をSPFレコードに反映させる必要があります。問題が起きる前に、定期的に確認・更新を行いましょう。

SPFがDKIMおよびDMARCとどのように連携するか

SPF、DKIM、およびDMARCは、連携したシステムとして機能するように設計されています。それぞれが、送信者の正当性、メッセージの完全性、および身元の整合性など、電子メールの信頼性に関する問題の異なる側面に対処しており、これらを組み合わせて初めて、確実な保護と適用が可能となります。

メールを受信すると、認証は段階的に行われます：

• SPFは、送信サーバーのIPアドレスがReturn-Path（エンベロープ送信者）に記載されたドメインに対して認証されているかどうかを確認します
• DKIMは、メッセージに添付された暗号署名を検証し、メッセージが改ざんされていないこと、および署名ドメインが有効であることを確認します
• DMARCはSPFおよびDKIMの結果を評価し、いずれかが表示されている「From」アドレスと一致しているかどうかを確認します

SPFとDKIMは認証結果を生成しますが、DMARCは、受信者が実際に目にする状況において、それらの結果が意味を持つかどうかを判断します。

SPFとDKIMの両方が必要なのは、それぞれが相手の弱点を補い合うからです。SPFは転送時に機能しなくなりますが、DKIMは転送後も有効です。DKIMは一部の中継サーバーによって削除される可能性がありますが、SPFはメッセージの内容に依存しません。これらを組み合わせることで、冗長性が確保されます。

DMARCはポリシー層を追加します。SPFとDKIMの両方の整合性が取れない場合、受信側はどのように対応すべきでしょうか？選択肢は以下の3つです。 なし （監視のみ）、 隔離 （スパムフォルダへ振り分け）、および reject （完全にブロック）。DMARCにはレポート機能も追加されています。これがないと、認証がいつ失敗したのかを知ることはできません。

結論

SPFはメール認証の基盤ですが、その有効性は設定の適切さに左右され、また、SPFが組み込まれるDMARCフレームワークの有用性にも依存します。SPFレコードの設定に誤りがあると、メールの配信が妨げられ、ドメインがなりすましの危険にさらされ、組織が現在の送信者要件を満たせなくなる恐れがあります。

SPFを初めて設定する場合でも、レコードの不具合をトラブルシューティングする場合でも、次の手順は同じです。現在の設定を確認してください。

当社の無料「ドメインアナライザー」で、ドメインのメール認証設定を確認しましょう 。SPF、DKIM、DMARCなどを数秒で評価します。継続的な監視、SPFの自動管理、DMARCレポート機能が必要ですか？ 

15日間の無料トライアルを開始する

よくあるご質問

1つのドメインに複数のSPFレコードを設定することはできますか？

いいえ。RFC 7208 では、ドメインごとに SPF レコードを 1 つだけ設定することが求められています。もし、 v=spf1 で始まるTXTレコードが2つ存在する場合、両方がPermErrorを返し、SPF検証は完全に失敗します。すべての承認済みソースを1つのレコードに統合してください。

ドメインのDNSルックアップ数が多すぎるとはどういうことですか？

SPFレコードが、RFC 7208で定められたDNSルックアップの制限数（10件）を超えています。これによりSPF PermErrorが発生し、オーバーフローしたメールだけでなく、すべてのメールのSPF認証が失敗します。インクルードを削減するか、以下に置き換えてください ip4:/ip6:に置き換えるか、SPFフラット化やマクロを使用して制限内に収めてください。

SPFのsoftfail（~all）とhardfail（-all）の違いは何ですか？

ソフトフェイル (~all)は、受信者にメールを受け入れるよう指示しますが、不審なメールとしてマークするように指示します。ハードフェイル (-all)は、受信者にメールを完全に拒否するよう指示します。初期設定やテスト中はsoftfailを使用し、正当な送信者がすべて確認され、DMARCが適切に機能していることが確認できたら、hardfailに切り替えてください。

SPFはメールのなりすましを防ぐことができますか？

それだけでは不十分です。SPFは、受信者が目にする「From」ヘッダーではなく、エンベロープの送信者（Return-Path）を確認します。攻撃者は、表示される「From」アドレスを偽装しながらも、SPFの検証を通過させることが可能です。表示名の偽装を防ぐには、SPFやDKIMの結果と「From」ヘッダーとの整合性を確認するDMARCが必要です。

SPFが失敗した場合はどうなりますか？

これは、SPFの修飾子やDMARCが設定されているかどうかによって異なります。 -all およびDMARCの拒否ポリシーが設定されている場合、メールはブロックされます。 ~all でDMARCが設定されていない場合、メールは配信される可能性がありますが、不審なメールとしてフラグが立てられます。SPFが全く設定されていない場合、受信側は評価すべきSPFシグナルを持ちません。

SPFレコードを確認するにはどうすればよいですか？

無料の SPF検索ツールをご利用ください。ドメインを入力すると、ツールがDNSからSPFレコードを取得し、構文の検証、DNSルックアップ回数のカウントを行い、PermErrorやvoidルックアップ違反を含むエラーを検出します。

すでにDKIMとDMARCを導入している場合、SPFは必要ですか？

はい。DMARCでは、SPFまたはDKIMの少なくとも一方が「合格」かつ「整合」している必要があります。DKIMのみでもDMARCの要件を満たすことは可能ですが、SPFとDKIMの両方を導入することで冗長性が確保されます。一方が失敗した場合（例えば、転送時にSPFが機能しなくなった場合など）、もう一方がDMARCの整合性を維持することができます。

SPFアライメントとは？

SPFの一致とは、Return-Path（エンベロープ送信者）のドメインがFromヘッダーのドメインと一致していることを指します。DMARCはこの一致を確認します。一致していない場合、SPFは通過してもDMARCは失敗します。これは、Return-Pathに貴社のドメインを使用するように設定されていない限り、多くのサードパーティ送信者で発生する現象です。

SPFレコードはどのくらいの頻度で更新すべきですか？

送信サービスを追加または削除する際は、その都度SPFレコードを確認し、少なくとも四半期に1回は監査を行ってください。ベンダーがIP範囲を変更したり、組織の送信スタックが進化したりするにつれて、SPFレコードは古くなってしまいます。6か月前には有効だったSPFレコードも、現在では無効になっているか、不完全になっている可能性があります。

SPFフラットニングとは何ですか？

SPFのフラット化により、すべての include: メカニズムを生のIPアドレスに変換し、DNSルックアップ回数を削減します。これにより、10ルックアップという制限内に収めることができますが、ベンダーがIPアドレスを変更するたびに更新が必要な静的なレコードが生成されます。SPFマクロのような最新の代替手段では、制限内に収めつつレコードを動的に維持することができます。