v=spf1とは何ですか？その目的は何ですか？

これは、 v=spf1で始まるDNSレコードを見ています。これが重要であることは分かっていても、内容を十分に理解せずに変更すると、ドメイン全体のメール配信に支障をきたす可能性があります。

「include:」の記述が1つ抜けていたり、ルックアップが1つ多すぎたり、構文エラーが1つあるだけで、メールの認証に失敗したり、スパムフォルダに振り分けられたり、あるいは完全に拒否されたりする可能性があります

SPF（Sender Policy Framework）は、電子メール認証の基盤となる仕組みです。これは、受信サーバーに対して、どの送信元があなたの名義で電子メールを送信することを許可されているかを通知するものです。 v=spf1 タグがそのポリシーを有効にするものですが、その後に続くすべての情報が、あなたのメールが信頼されるかブロックされるかを決定します。

課題は、SPFが表面的には単純に見えるものの、送信元やマーケティングツール、インフラストラクチャが増えると複雑化してしまう点にあります。ルックアップの制限、ネストされたインクルード、および整合性の問題は、配信率が低下するまで必ずしも目に見えない障害要因となります。

このガイドでは、 v=spf1 が何を意味するのか、SPFレコードの構造、評価の仕組み、そして実環境下で失敗しないレコードを構築・維持する方法を詳しく解説します。

SPF評価の仕組み

SPF評価は、メールを受信するたびに実行される段階的な検証プロセスです。これにより、送信サーバーがReturn-Pathに使用されているドメインに代わって送信する権限を持っているかどうかが判定されます。

実際の仕組みは以下の通りです：

• あなたのドメインから送信されたと称するメールが届きました： このメッセージは、表示されるヘッダー（From）と非表示のルーティング情報（Return-Path）の両方を伴って、受信者のメールサーバーに届きます。
• 受信サーバーは、Return-Pathドメインを抽出します： これが、SPFが実際にチェックするドメインです。これは、メール送信時に使用された送信者を表しています。
• サーバーは、SPFレコードについてDNSに問い合わせを行います（v=spf1）を照会します： そのドメインに公開されているTXTレコードを検索します。SPFレコードが存在しない場合、結果は None （認証なし）となります。
• 送信サーバーのIPアドレスは、SPFレコードに基づいて検証されます： サーバーはSPFレコードを左から右へと処理します：
  • 各メカニズム（ip4、 include, a, など）
  • 必要なDNS検索をすべて実行します
  • 最初の一致するルールで停止する
• 一致結果に基づいて結果が生成されます： 考えられる結果としては、次のようなものがあります：
  • パス → 送信者は認証済み
  • 失敗 / ソフト失敗 → 送信者が認証されていません（厳格な処理と寛容な処理）
  • 中立 / なし → 明確なポリシーがない、またはSPFレコードがない
  • PermError / TempError → エラーのため、SPFを評価できませんでした
• この結果は、DKIMおよびDMARCと組み合わされます： SPFだけでは配信の可否は決まりません。受信サーバーは、SPFに加えて以下の要素も考慮します：
  • DKIM（メッセージの完全性）
  • DMARC（整合性＋ポリシー）
    メッセージを受け入れるか、フィルタリングするか、拒否するかを決定するため

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

SPFレコードとは、ドメインからメールを送信することを許可されたすべてのサーバーおよびサービスを定義するDNS TXTレコードのことです。メールを受信すると、受信サーバーはこのレコードを確認し、送信元が許可されているかどうかを検証します。

v=spf1 とはどういう意味ですか？

The v=spf1 タグは、受信メールサーバーに対して、このDNS TXTレコードがSPFポリシーであることを示す識別子です。これは、RFC 7208で定義されたSPFルールを使用して、レコードを解析および評価すべきであることを示しています。

このタグがない場合、そのレコードはSPFとして一切扱われず、検証も行われないため、そのドメインは事実上SPFによる保護を受けられません。

受信サーバーがあなたのドメインを検索するとき：

• TXTレコードの中から、 v=spf1
• SPFの評価では、そのレコードのみが対象となります
• 以下に続くすべての内容は、認可ルール（メカニズム、修飾子、修飾条件）として解釈される

SPFが正しく機能するためには、 v=spf1 は、以下の厳格な要件を満たす必要があります：

• レコードの冒頭に必ず記載すること
• 必ず以下のとおりに記述してください v=spf1 （タイプミスや余分なスペースがないこと）
• ドメインごとにSPFレコードは1つだけ存在する必要があります

バージョンタグに何らかの誤りがある場合、レコード全体が失敗となります：

• 完全に欠落 → SPFが返される なし (レコードが見つかりません)
• スペルミス（v=spf 1, v=spf2, v=SPF1) → 構文エラー → PermError
• 別の値の後に配置された場合 → レコードは形式不備として無視されます

受信サーバーがSPFポリシーを解釈できず、すべてのメールの認証に失敗します。

SPFレコードの構造：構文の完全解説

すべてのSPFレコードは一貫した構造を持っており、一連のルールが順番に実行されます。各部分がその評価にどのように寄与しているかを理解することが、設定ミスを防ぐ鍵となります。

SPFレコードは常にバージョンタグ（v=spf1）で始まり、その後に許可された送信者を定義する一連のメカニズムが続きます。これらのメカニズムは、一致の処理方法を制御する修飾子や、レコードの評価方法を調整する修飾子と組み合わせることができます。これらはすべて1行のテキストに収まっていますが、各要素は受信サーバーがドメインのメールをどのように解釈するかに直接影響を与えます。

レコードの例

v=spf1 ip4:192.0.2.0/24 include:_spf.google.com include:spf.protection.outlook.com -all 

ip4:192.0.2.0/24 （ここで /24 は、クラスレス・ドメイン間ルーティング（CIDR）表記による256個のIPアドレスの範囲を表します）

各部の役割

• v=spf1 このレコードをSPFポリシーとして識別し、評価を有効にします
• ip4:192.0.2.0/24 既知のIP範囲（通常は自社インフラ）を明示的に許可します
• include:_spf.google.com SPFレコードを参照することで、Google Workspaceを認証します
• include:spf.protection.outlook.com Microsoft 365についても同様です
• -all はデフォルトのポリシーを定義します：これ以前に一致しなかった送信者はすべて許可されません

この組み合わせにより、完全な承認モデルが構築されます。特定のソースのみが許可され、それ以外はすべて拒否されます。

評価は実際にはどのように行われるのか

SPFは、厳格かつ予測可能な方法で処理されます：

• 受信サーバーはレコードを左から右へ読み取ります
• 各メカニズムは、送信元のサーバーのIPアドレスに対して順次評価される
• 一致が見つかり次第、評価は直ちに停止する
• その仕組みに付随する条件によって、結果が決まります

一致するメカニズムがない場合：

• その すべての メカニズムはフォールバックの決定として機能する

つまり、SPFは「すべてをチェックしてから決定する」システムではありません。これは「最初に一致したものが優先される」システムです。

SPFの仕組みについて

メカニズムはSPFレコードの中核をなすものです。これらは、どの送信元が許可されるかを定義し、受信サーバーが送信元のIPアドレスに対して評価を行うロジックを構成します。各メカニズムが1つのルールを追加し、それらが組み合わさってドメインの許可リストが形成されます。

実際には、個々のメカニズムが何を行うかだけでなく、評価時の挙動や、それが限界や信頼性にどのような影響を与えるかが重要である。

メカニズムは順番に評価され、送信元IPと一致した最初のメカニズムが結果を決定します。つまり、追加するメカニズムごとに、認証の適用範囲と評価の複雑さの両方に影響が及ぶことになります。

IPアドレスを直接照合する仕組みもあれば、追加のデータを取得するためにDNS検索を必要とする仕組みもあります。 

さまざまなメカニズムの挙動

これには には以下が含まれます： メカニズムは最も一般的に使用されており、ネストされたDNSクエリが原因でルックアップ制限の問題を引き起こす可能性が最も高い。

SPFでは、1回の評価につき最大10回のDNS検索が許可されています。この制限の対象となる処理は以下の通りです：

• を含む：
• a
• エムオーエス
• 存在します：
• リダイレクト=
• 伝令者

以下の条件を満たさないメカニズム：

• IPv4:
• ip6:

これにより、現実的なトレードオフが生じます：

• 利便性（以下を含む）→ 検索コストの増加
• 制御 (IPv4/IPv6) → 検索コストは低くなるが、メンテナンスの手間が増える

SPF修飾子の解説

修飾子は、メカニズムが一致した際にどのようなアクションを実行するかを定義します。メカニズムが「誰が許可されるか」を決定するのに対し、修飾子は「次に何が起こるべきか」を決定します。これらを組み合わせることで、SPFポリシーの適用厳格度が決定されます。

すべてのメカニズムには、修飾子を前置することができます。修飾子が指定されていない場合、デフォルトは pass です（+）。この修飾子は、受信サーバーが一致をどのように解釈するか、またメッセージをどの程度信頼するか、あるいは拒否するかに直接影響します。

評価時の修飾子の振る舞い

メカニズムが一致した場合：

• それに付随する修飾子が、結果を即座に決定する
• SPFの評価はその時点で終了します
• その結果は、DKIMやDMARCと併せて、メッセージの処理方法を決定するために使用されます

つまり、予選通過チームは SPFプロセスにおける最終的な決定信号 となります。

各修飾子の実際の動作（文脈内での）

ほとんどのSPFレコードでは、修飾子が すべての メカニズムの末尾に修飾子が適用され、デフォルトのポリシーが定義されます。

SPFレコードにおける修飾子の一般的な使用方法

ほとんどのSPFレコードは、ある1か所の修飾子に依存しています。それは all メカニズムです。

• ~すべて → デフォルトでソフトな適用（監視フェーズ）
• -all → 厳格な適用をデフォルトとする（本番環境対応ポリシー）

この最後の条件式は、それ以前に明示的に一致しなかった送信者をどのように扱うかを定義します。

実践的な指針

• まずは セットアップ中に 設定時に次のように設定します: これにより、見落としていた正当な送信者をブロックすることなく、SPFの結果を確認できます。
• 移動先 -すべて レコードが完成したら: 有効なソースがすべて含まれていることを確認した後、完全な適用を行うためにhardfailに切り替えてください。
• 避けてください ?all :受信サーバーに対して有意義な保護や指針を提供しません。
• 絶対に使用しないでください +all:  これを使用すると、どの送信者でもSPFを通過できるようになり、事実上、ドメインの認証が無効になります。

SPF修飾子の解説（解説）

修飾子は、SPF構文の小さな要素ですが、重要な役割を果たします。メカニズムとは異なり、修飾子は送信を許可される主体を定義するものではありません。その代わりに、レコードが処理される際に、SPFの評価処理の方法を変更する役割を担います。

これらはオプションであり、標準的なメカニズムに基づくルールでは不十分な特定の状況で使用されます。

評価時の修飾子の振る舞い

修飾子はメカニズムの処理後に評価され、全体的な結果の決定や表示方法に影響を与えます。

• 送信元IPアドレスが一致しません
• 彼らは送信者を直接承認したり拒否したりすることはありません
• 彼らは 流量 または 結果 を調整する

このため、修飾子は通常、基本的なSPFレコードではなく、高度な設定や構造化された設定でのみ使用されます。

redirect= – SPF評価の完全な委任

The redirect= 修飾子は、SPFの評価を別のドメインに移します。

• これは受信サーバーに対して、「このレコードの残りの部分は無視し、別のドメインで定義されたポリシーを使用してSPFを評価してください」と伝えます。
• とは異なり を含む：:
  • 以下を含める： 評価に別のポリシーを追加します
  • redirect= 評価を完全に置き換えます

例

v=spf1 redirect=_spf.example.com

この場合：

• そのドメインには独自のSPFルールが定義されていません
• すべての評価は _spf.example.com

いつ使うか：

• 複数のドメインを 一元化されたSPFポリシー
• レコードを重複させることなく、ドメイン間で一貫性を確保する

exp= – 失敗時のカスタム説明

The exp= 修飾子は、SPFが失敗した際に人間が理解しやすい説明を提供します。

• テキストメッセージを含むDNSレコードを指しています
• そのメッセージは、障害発生時に送信元サーバーへ返送されることがあります

例

v=spf1 -all exp=explain._spf.example.com

これにより、次のような独自の説明を定義できます：

• メッセージが送信に失敗した理由
• 差出人が次にすべきこと

SPFレコードの作成方法

SPFレコードの作成 SPFレコードの作成 は、管理された段階的なプロセスです。その目的は、レコードの有効性、効率性、および強制力を維持しつつ、正当な送信元をすべて正確に列挙することです。

SPFは記述された通りに厳密に評価されるため、各ステップが重要です。送信者の記載漏れや誤ったロジックの追加は、配信に直接影響を及ぼす可能性があります。

• まず v=spf1: これでドメインのSPFが有効になります。これがない場合、レコードは無視され、認証は行われません。
• 独自の送信インフラを追加する (ip4: / ip6:): トランザクションメールサーバーや内部システムなど、直接管理しているサーバーをすべて含めてください。これらは外部のDNS解決に依存しないため、最も信頼性の高いエントリとなります。
• 主なメールプロバイダーを追加してください（以下を含める:）： Google Workspace や Microsoft 365 などのプラットフォームをご利用の場合は、それらの SPF レコードを含める必要があります。これにより、送信インフラ全体があなたに代わって認証されるようになります。

各 には以下が含まれます： 少なくとも1回のDNSルックアップが発生し、プロバイダのSPF構造によっては、さらにネストされたルックアップが生じる可能性があります。

• すべてのサードパーティ送信者を追加してください： これには、マーケティングツール、CRM、サポートプラットフォーム、およびお客様のドメインを使用してメールを送信するあらゆるサービスが含まれます。SPFは外部サービスを自動的に信頼しないため、それぞれを明示的に承認する必要があります。
• 最後に、貴社のポリシーを記載してください（～すべて または -すべて): これは、上記に挙げられていない送信者をどのように扱うかを定義するものです：
  • ~すべて → 許可するが、疑わしいものとして扱う（セットアップ中に使用）
  • -すべて → 許可されていない送信者を拒否する（完全に検証された後に使用）
• 単一のDNS TXTレコードとして公開する: SPFでは、ドメインごとに1つのレコードのみが許可されます。すべてのメカニズムをその単一のエントリに統合する必要があります。
• 公開前と公開後の確認： 構文エラー、ルックアップの制限、およびソースの欠落がないか確認してください。また、入力内容だけでなく、実際のDNSレコードも確認してください。

送信元が増えるにつれ、SPFの手動管理は困難になります。追加されるごとに照会処理が複雑化し、プロバイダーは予告なしにIPアドレスを変更する場合があります。

次のようなツール PowerDMARCのPowerSPF（Hosted SPF） は、以下の方法でこのプロセスを自動化します：

• 検索回数が10回以内に収まるようにする
• プロバイダからのIP変更を自動的に更新する
• 人為的ミスとメンテナンスの削減

これにより、SPFレコードの有効性が維持され、長期的に配信率への影響を防ぐことができます。

レコードの例

v=spf1 ip4:203.0.113.5 include:_spf.google.com include:servers.mcsv.net -all

このレコードが実際に行うこと

• 専用サーバー（ip4:203.0.113.5)を承認します
• Google Workspace（include:_spf.google.com) を承認します
• Mailchimp（include:servers.mcsv.net)を承認します
• 明示的にリストされていない送信者はすべて拒否します（-all)

これにより、厳格かつ強制力のあるポリシーが確立され、既知の送信元からのみ送信が可能となり、それ以外はすべてブロックされます。

10件の検索制限

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

• を含む：
• a
• エムオーエス
• 存在します：
• リダイレクト=
• ptr (非推奨ですが、使用された場合はカウントされます)

これらの仕組みでは、受信サーバーは評価を続行する前に、追加データを解決するためにDNSにクエリを送信する必要があります。

対象外となるもの

これらは直接評価され、DNSクエリは発生しません：

• IPv4:
• ip6:
• 何れも
• v=spf1

課題は、SPFに関する問題が必ずしも表面化しない点にあります。ネストされたインクルード、非アクティブな送信元、および隠されたIP範囲などが、目立った兆候なしにレコードを制限値を超えてしまう原因となる可能性があります。

ルックアップカウントの増加メカニズム

SPFレコードが小さくても、ネストされたインクルードによって制限を超えることがあります。実際にルックアップ回数がどのように増加するかを以下に示します：

4つしか には以下が含まれます： メカニズムは4つしか見えませんが、ネストされたレコードが評価されると、総ルックアップ回数が10ルックアップの制限を超える可能性があります。

空のルックアップ制限（見落とされがちな点）

SPFでは、DNSルックアップの制限が10回に設定されているだけでなく、無効なルックアップも2回までと制限されています。

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

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

一般的な原因

• 不正確または古い には以下が含まれます: ドメイン
• SPFメカニズムにおける誤植
• 存在しなくなったドメインへの参照

SPFの評価中に3回以上の無効なルックアップが発生した場合：

• SPFがPermErrorを返す
• SPFチェック全体が失敗しました
• 正当なメールでも認証に失敗する場合があります

ルックアップ回数の問題とは異なり、無効なルックアップは、目に見える複雑さによるものではなく、無効なDNS参照や古いDNS参照に起因するため、発見が難しい場合が多い。

SPFレコードでDNSルックアップが何回行われているか、おわかりですか？ 

次のようなソリューション PowerDMARCのSPF分析およびレポート機能 は、以下の機能を提供します：

• すべての送信元およびIPアドレス（ネストされたものも含む）の可視化
• ルックアップ制限の問題および設定ミスの検出
• 明確な診断と具体的な解決策

これにより、SPFレコードが実際にどのような役割を果たしているのか、またどこを最適化すべきかがより理解しやすくなります。

結論

SPFは、どの送信者があなたのドメインを使用してメールを送信できるかを定義する制御層です。 v=spf1 タグがそのプロセスを開始しますが、設定の信頼性は、レコードが適切に構築・維持され、制限内に収められているかどうかにかかっています。

SPFに関する問題の多くは、設定不足によるものではなく、設定のずれ、更新を行わずに追加された新しいツール、放置された未使用のインクルード、あるいは時間の経過に伴うルックアップ制限の超過に起因しています。こうした不具合は、配信に影響が出るまで気づかれないことがよくあります。

SPFが意図したとおりに機能し続けるためには：

• 記録は正確かつ簡潔に保つ
• 送信元を定期的に確認する
• 検索制限の範囲内にとどめる
• 公開前と公開後の変更内容を確認する

SPFは、単発の設定ではなく、継続的に運用する構成として扱うことで最大の効果を発揮します。適切に維持管理されれば、受信サーバーに対して信頼できる明確かつ一貫したシグナルを提供し、メールプログラム全体における配信率の向上や認証を直接的に支えることになります。

SPFエラーによってメール配信が妨げられるのを待ってはいけません。

SPFレコードを完全に把握し、ルックアップの問題を解決し、送信インフラの進化に合わせて設定を正確に維持しましょう。 

PowerDMARCを使って PowerDMARCを使ってSPFを簡単に監視・管理する方法をご覧ください。

よくあるご質問

1. SPFレコードがない、または設定されていない場合、どうなりますか？

SPFレコードが存在しない場合、受信サーバーは None という結果を返します。これは、ドメインにSPFベースの認証がないことを意味し、受信側はDKIMやスパムフィルターなどの他の指標に依存することになります。実際には、これによりなりすましのリスクが高まり、配信率に悪影響を及ぼす可能性があります。

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

いいえ。ドメインには、SPFレコードが1つだけ存在する必要があります。複数のTXTレコードが v=spf1で始まるTXTレコードが複数存在する場合、SPF評価は PermErrorを返し、すべてのメールの認証が失敗します。送信元は常に1つのレコードに統合してください。

3. SPFレコードが正しいかどうか、どうすれば確認できますか？

次の3つの点を確認する必要があります：

• 構文は正しい（誤字や書式の問題はない）
• すべての正当な送信元が含まれています
• DNS検索回数は10回という制限内に収まっています

SPFチェッカーツールを使用し、DMARCレポートを通じて実際の結果を確認して、すべてが想定通りに機能していることを確認してください。

4. SPFの「Pass」、「Fail」、「PermError」の違いは何ですか？

• パス → 送信サーバーは認証済みです
• 失敗 / ソフト失敗 → 送信者に権限がありません（厳格な処理と寛容な処理）
• PermError → 設定ミスによりSPFが機能していません（例：ルックアップが多すぎる、構文が不正など）

PermErrorは最も深刻なエラーです。これは、SPFがまったく評価できないことを意味するからです。

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

はい。SPFは、DMARCで使用される主要な認証シグナルの一つです。DKIMは単独でも通過可能ですが、SPFとDKIMの両方を組み合わせることで、信頼性と適用範囲が向上します。多くの受信側は、これら3つすべてが適切に設定されていることを求めています。

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

それだけでは不十分です。SPFはReturn-Pathドメインのみを確認し、表示されるFromアドレスは確認しません。攻撃者は依然としてFromヘッダーを偽装し、自身のドメインを使用してSPFを通過させることが可能です。これを防ぎ、整合性を確保するには、DMARCが必要です。