SPFレコードの構文
by
最終更新日: 5 読了時間：5分
主なポイント
- SPFレコードでは、メカニズム、修飾子、およびモディファイアを使用して、どの送信元があなたのドメインのメールを送信できるかを定義します。
- a、mx、ptr、exists などのメカニズムは DNS ルックアップをトリガーする可能性がありますが、ip4、ip6、all は制限の対象にはなりません。
- SPFの修飾子は、受信サーバーが一致した送信者をどのように扱うかを決定します。-all は「Fail」、~all は「SoftFail」を示します。
- SPFレコードが10回のDNSルックアップ制限を超えると、PermErrorが発生する可能性があり、その結果、正当なメールがSPF認証に失敗する恐れがあります。
- ドメインにはSPFレコードを1つだけ設定する必要があります。また、「v=spf1」の記載漏れ、書式の不備、非推奨となった「ptr」の使用などの構文エラーがあると、認証の問題が発生する可能性があります。
SPFレコードとは、DNSのTXTレコードとして公開される単一の文字列のことです。これは、どのIPアドレスがドメインを代表してメールを送信することを許可されるかを正確に定義する一連のルールとして機能します。正しくフォーマットされたレコードは、常にバージョンタグで始まり、その後に1つ以上のメカニズムが続き、最後に適用ルールで終わります。
以下に、標準的なSPFレコードを構成要素ごとに分解して示します。
v=spf1 ip4:192.0.2.0/24 include:_spf.google.com ~all
- v=spf1: このレコードを定義するバージョンタグ。
- ip4:192.0.2.0/24: 特定のIPv4アドレス範囲を許可する仕組み。
- include:_spf.google.com: ドメインを基に、サードパーティの送信者の承認済みIPリストを指し示す仕組み。
- ~all: 未承認の送信者に対するフォールバックポリシーを規定する修飾子（~）およびメカニズム（all）。
ドメインの新しいエントリを作成する必要がある場合は、 SPFレコード生成ツール を使用して、正確な文字列を自動的に生成してください。
SPFの仕組み
メカニズムは、SPFレコードを構成する基本要素です。これらは、受信メールサーバーに対し、許可された送信元を識別する方法を指示します。
| メカニズム | どのようなものに合うか | 例 | 10件の検索制限にカウントされます |
|---|---|---|---|
| 何れも | 常に一致します。レコードの最後で使用され、それ以前のルールで一致しなかったすべてのIPアドレスを対象とする包括的なルールとして機能します。 | ～すべて | いいえ |
| インクルード | 送信元のIPアドレスが、指定されたドメインのSPFポリシーによって許可されている場合に一致します。 | include:_spf.google.com | はい。 |
| a | 送信元のIPアドレスが、そのドメインのAレコードまたはAAAAレコードから解決されるIPアドレスと一致する場合に一致します。 | a:example.com | はい。 |
| エムオーエス | 送信元のIPアドレスが、そのドメインのMXレコードに記載されているIPアドレスのいずれかと一致する場合に一致します。 | mx:example.com | はい。 |
| アイピーフォー | 送信元のIPアドレスが、定義されたIPv4ネットワークまたはサブネットの範囲に完全に含まれる場合に一致します。 | IPv4: 192.0.2.0/24 | いいえ |
| アイピーシックス | 送信元のIPアドレスが、定義されたIPv6ネットワークまたはサブネットの範囲に完全に含まれる場合に一致します。 | ip6:2001:db8::/32 | いいえ |
| 伝令者 | そのIPアドレスの逆DNS解決結果が指定されたドメインに一致する場合に一致します（パフォーマンスへの負荷が高いため、非推奨であり、使用は極力避けるべきです）。 | ptr:example.com | はい。 |
| ある | 指定されたドメイン名に対して、DNSのAレコードの解決が正常に行われた場合に一致します。 | exists:example.com | はい。 |
インクルードの仕組み
インクルード機能は、現代のメール認証において最も頻繁に利用されるコンポーネントの一つです。この機能により、受信サーバーは、Google Workspace、Microsoft 365、マーケティングプラットフォームなどのサードパーティサービスのSPFルールを参照・評価するよう指示されます。サードパーティベンダーが自社のサーバーIPアドレスを更新した場合でも、手動での更新を必要とせずに、レコードの有効性が維持されます。
「オール・メカニズム」
常に文字列の最後に配置される「all」メカニズムは、究極のデフォルトルールとして機能します。これは、レコード内の先行するメカニズムのいずれにも一致しなかった送信元IPアドレスをすべて捕捉します。このメカニズムを有効にするには、受信サーバーに対して、許可されていないメールを拒否するか受け入れるかを指示する修飾子（「–」や「~」など）と組み合わせて使用する必要があります。
「a」の仕組み
この仕組みは、ドメインのAレコードまたはAAAAレコードに関連付けられたIPアドレスを認証するものです。これは、メインのウェブサイトをホストしているWebサーバーが、ウェブサイトの問い合わせフォームからの通知やシステムアラートなど、送信メールの配信にも利用されている場合に特に役立ちます。
mxメカニズム
受信メールの受信先として指定されたサーバー（MXレコードに記載されているもの）が、送信メールの処理も行う場合は、「mx」メカニズムが適切な選択となります。これにより、それらの特定の受信メールサーバーのIPアドレスに対し、そのドメインに代わって送信メールを送信する権限が付与されます。
SPF修飾子
修飾子は、メカニズム（最も一般的なのは「all」メカニズム）に付加される接頭辞として機能します。これらは、送信者のIPアドレスがメカニズムに一致した場合、受信サーバーがそのメールをどのように扱うべきかを正確に指定します。
| 予選 | 結果 | 意味 | 例 |
|---|---|---|---|
| + | パス | このIPアドレスには、メールを送信する完全な権限が与えられています。「+」記号は任意ですが、デフォルトでは含まれているものとみなされます。 | +すべて |
| - | 失敗 | このIPアドレスは一切許可されていません。このメールは完全に拒否されるべきです。 | -すべて |
| ~ | ソフトフェイル | そのIPアドレスは許可されていませんが、メールは受信され、通常はスパムとしてマークされるか、隔離されます。 | ～すべて |
| ? | ニュートラル | 明確なポリシーは明記されていません。このメールは、SPFルールがまったく適用されていないかのように扱われます。 | すべて |
SPF改質剤
修飾子は、SPFレコードに追加の指示や文脈に関する詳細情報を提供します。これらは任意であり、1回のみ記述され、通常は文字列の最後に配置されます。
| 修飾子 | その機能 | 例 | 備考 |
|---|---|---|---|
| リダイレクト | 受信サーバーに対し、現在のルールを無視し、代わりに別のドメインのSPFレコードを使用するよう指示します。 | v=spf1 redirect=example.com | レコードに「all」メカニズムも含まれている場合、リダイレクトは完全に無視されます。 |
| exp | SPFチェックに失敗した際に説明を提供するTXTレコードが登録されているカスタムドメインを指定します。 | exp=explain.example.com | 現代の電子メール認証設定ではほとんど利用されておらず、主要な受信サーバーからもしばしば無視されています。 |
SPF評価結果
受信メールサーバーが、SPFレコードに基づいて受信メッセージを処理する際、その構文に基づいて、7つの標準化された評価結果のうちの1つを返します。
| 結果 | その意味 | 受信機が通常行うこと |
|---|---|---|
| パス | 送信者のIPアドレスが、貴社のレコードに登録されている認証メカニズムと正常に一致しました。 | このメールを受信します。ただし、DMARC、DKIM、および一般的なスパムチェックの結果が判明するまでは保留となります。 |
| 失敗 | 送信者のIPアドレスが、- 修飾子を含むメカニズムと一致しました。 | 受信トレイに届く前に、サーバー側でそのメールを破棄または拒否します。 |
| ソフトフェイル | 送信者のIPアドレスが、「~」修飾子を含むメカニズムと一致しました。 | そのメールは受信されるものの、不審なメールとしてマークされ、多くの場合スパムフォルダに振り分けられてしまいます。 |
| ニュートラル | 送信者のIPアドレスが「？」という修飾子と一致したか、あるいはそのレコードから明確な結論が得られなかった。 | サーバー独自のスパムフィルタ基準に厳密に従って、メールを処理します。 |
| なし | 当該ドメインについて、有効なSPFレコードは見つかりませんでした。 | そのメールを認証されていないものとして扱い、配信率に深刻な悪影響を及ぼします。 |
| PermError | このレコードには恒久的な構文エラーが含まれているか、10件の検索制限を超えています。 | SPFチェックに即座に失敗し、そのメールを未認証とみなして、おそらく拒否することになります。 |
| 一時的なエラー | 一時的なDNSタイムアウトまたはネットワーク障害により、確認が完了できませんでした。 | メールの配信を一時的に保留し、後で再度確認を試みます。 |
DNS 検索の制限数（10件）
悪意のある攻撃者がSPFを利用してDNSサーバーに対してサービス拒否攻撃を仕掛けるのを防ぐため、SPF仕様では厳格な制限が設けられています。受信サーバーは、1つのSPFレコードを評価するために、最大10回のDNSルックアップを実行します。
バックエンドのDNSクエリを必要とするメカニズムには、include、a、mx、ptr、exists、およびredirect修飾子があります。重要な点として、ip4、ip6、allなどのメカニズムは、DNSルックアップを必要とせずに即座に動作するため、制限枠にはカウントされません。
設定でルックアップが10件を超えると、受信サーバーは直ちにSPF PermErrorを返します。これにより、ポリシーは完全に無効となり、正当なメールでも認証に失敗することになります。複数のサードパーティ製メールベンダー（CRM、サポートデスク、マーケティングオートメーションプラットフォームなど）を利用している組織では、この閾値に非常に簡単に達してしまう可能性があります。
この制限を解消するには、PowerDMARCの Hosted SPF ソリューションを導入することができます。これにより、サードパーティのドメイン処理が単純なIPアドレスに集約され、ルックアップ回数が即座に削減されます。また、ドメインを SPFレコードチェッカー でドメインを検証し、現在のルックアップ総数を把握するとともに、配信率に影響が出る前に脆弱性を特定しておくことをお勧めします。
SPF構文でよくある間違い
SPFレコードを規格に準拠した形で作成するには、書式規則を厳密に遵守する必要があります。たった1文字の誤りでも、認証に失敗する可能性があります。以下に、最も頻繁に見られる構文上の誤りを挙げます：
- 1つのドメインに複数のSPFレコードが存在する場合: ドメインには、v=spf1 で始まる TXT レコードを正確に 1 つだけ公開する必要があります。複数のレコードを公開すると、直ちに PermError が発生します。
- v=spf1 が欠落しています: 文字列がこの正確なバージョンタグで始まっていない場合、受信サーバーは単にそのTXTレコードを無視します。
- 「+all」の使用： この組み合わせは、文字通りインターネット上のすべてのIPアドレスが、あなたに代わってメールを送信する権限を持っていることを宣言することになり、事実上、そのレコードは無意味なものとなってしまいます。
- トレーリング ptr: ptr メカニズムは、受信サーバーに多大な負荷をかけます。これは公式に非推奨となっており、組み込むとパフォーマンス上の問題を引き起こします。
- 10回を超える検索: `include` ステートメントを過度にネストすると、DNS 検索の制限を超過し、レコードが自動的に無効になります。
- メカニズム内のスペースやコロンが欠落している場合: 正しい「include:_spf.google.com」の代わりに「include _spf.google.com」と入力してしまうような書式設定の誤りは、構文の解析を妨げます。
[変更なし：既存のCTAブロック]
よくあるご質問
SPFレコードの正しい構文はどのようなものですか？
SPFレコードは、DNSのTXTレコードとして公開する必要があります。その内容は、v=spf1というバージョンタグで始まり、その後にスペースで区切られた認証対象のIPアドレスまたは認証メカニズムを列挙し、最後に~allや-allなどの厳格なフォールバックメカニズムで締めくくる必要があります。
SPFレコードにおける「~all」とはどういう意味ですか？
「~all」メカニズムは、SoftFail フォールバックポリシーを示します。これは、レコードに明示的に記載されていない送信元 IP アドレスはすべて不正であると受信サーバーに通知しますが、そのメールは受け入れて、受信者のスパムフォルダに転送されるべきであることを示します。
「include」と「redirect」の違いは何ですか？
「include」メカニズムは、自身のSPFルールに加えて別のドメインのSPFルールも評価するため、複数の送信元を組み合わせることができます。「redirect」修飾子は、受信サーバーに対し、自身のレコードを完全に無視し、代わりに指定されたドメインのSPFレコードを使用するよう指示します。
SPFレコードの構文を確認するにはどうすればよいですか？
無料のSPFレコードチェッカーにドメインを入力することで、フォーマットを確認したり、アクティブなルックアップ数を計算したりできます。これにより、構文エラー、非推奨の仕組み、制限違反などが即座に指摘されます。
SPFレコードを2つ設定することはできますか？
いいえ、1つのドメインに対して複数のSPFレコードを公開することは、プロトコルの基本規定に違反します。受信サーバーが「v=spf1」で始まるレコードを2つ以上検出した場合、直ちにPermErrorを返し、認証に失敗します。
ドメインおよびメールセキュリティの専門家（所属： PowerDMARC
ユネスはPowerDMARCのオペレーションチームリーダーで、メール認証とセキュリティの専門知識を持つ。マイクロソフト認定のAzureアドミニストレーターアソシエイトであり、CompTIA A+やその他多くの資格を持っています。
最新記事 by Yunes Tarada(全て見る)
- SPFレコードの構文 - 2026年9月14日
- Oracle メール配信の DKIM、DMARC、および SPF 設定ガイド - 2026年9月14日
- DKIM=none：「メッセージが署名されていません」の意味と対処法 - 2026年9月13日
