SPFレコード構文：構成要素、ルール、例

もしあなたが、正当なメールがスパムフォルダに入ってしまったり、完全にブロックされてしまったりするのを不思議に思ったことがあるなら、その問題はあなたのドメインのメール認証がどのように設定されているかに起因しているかもしれません。ここで重要なのがSPFレコードの構文で、認証されたサーバーから送信されたメールであることを確認する上で重要な役割を果たします。SPFは、あなたのメールが疑わしいと判断されるのを防ぐのに役立ちますが、その構文を理解するのは難しく、正しく設定するのはさらに困難です。この投稿では、SPFレコードの構文がどのように機能するのか、またドメインに設定する際に注意すべき点を説明します。

SPFレコード構文とは

SPFレコード構文とは、SPF（Sender Policy Framework）レコードがドメインのDNSにどのように記述されるかを定義する一連のルールです。簡単に言えば、ドメインが受信メールサーバーに、どの送信元が自分に代わってメールを送信することを許可されているかを伝えるために使用する「言語」です。

SPFレコード構文には、通常、メカニズム(のような ip4, ip6, または インクルード), 修飾子 (例えば +, -, ~,または?), そして 修飾子 といった 一緒に働く と を 修飾子は、受信メールがSPFチェックに合格するか不合格になるかを決定する。

この構文を理解することは極めて重要です。なぜなら、余分なスペース、誤った修飾子、欠落したメカニズムといった些細な誤りさえも、メールの認証失敗やスパムフォルダへの振り分け、あるいは送信拒否の原因となるからです。

PowerDMARCでSPFレコード構文を簡素化！

SPFレコード構文の構成要素

SPFレコードは、バージョンタグ、メカニズム、修飾子、およびモディファイアの4つの主要な部分で構成されています。各パーツはそれぞれ固有の役割を果たし、合わせて受信メールサーバーがあなたのドメインから来たと主張するメールをどのように処理するかを決定します。バージョンタグは、そのレコードがSPFであることを示します。メカニズム（Mechanisms）は、誰がメールの送信を許可されるかを定義します。修飾子（Qualifiers）は、一致した場合にどのような処理を行うかを決定します。修飾子は、ポリシーを拡張または洗練するオプションの指示を提供します。

バージョンタグ

バージョンタグはSPFレコードの開始点です。このタグは、そのレコードがSPF構文を使用していることを識別し、メールサーバーが次のテキストを正しく解釈することを保証します。これがないと、レコードは動作しません。バージョン・タグは1つだけ使用でき、レコードの一番最初に記述しなければなりません。

主な仕様

• • 常にレコードの最初になければならない。
  • バージョンタグは1つしか使用できない。
  • 現在有効なフォーマット v=spf1.
  • 間違ったバージョンを使用したり、省略したりすると、その記録は無効になる。

SPF修飾子

修飾子はメカニズムの前に置かれるシンボルである。これは、メカニズムがマッチした場合にどうするかを受信メールサーバーに指示します。その役割は、SPFの評価結果、つまりメールが受け入れられるか、拒否されるか、あるいは疑わしいとマークされるかを制御することである。修飾子が指定されない場合、デフォルトの動作は許可です。

主な仕様

• • メカニズムの接頭辞として機能する。
  • SPFチェックの結果をコントロールする。
  • 4種類だ：
    • +パス（許可）
    • - 失敗（ブロック）
    • ~ ソフト不合格（合格だがマーク）
    • ? 中立（決定せず）
      • デフォルトの動作は、修飾子を使用しない場合のPassである。

SPFメカニズム

メカニズムはSPFレコードの主要な規則である。どのサーバ、IPアドレス、またはドメインが、そのドメインに代わってメールを送信する権限を持つかを定義する。各メカニズムは順番にチェックされ、一致するものがあれば関連する修飾子が適用される。一致するメカニズムがなければ、レコードは最後まで続けられる。

主な仕様

• • ドメインのメール送信者を定義します。
    左から順にチェックします。
  • 予選通過者と協力して結果を決める。
  • 8つの標準メカニズム：
    • すべて- はすべての送信者にマッチする。
    • ip4- はIPv4アドレスを許可する。
    • ip6- はIPv6アドレスを認可する。
    • a- はドメインのA/AAAレコードに基づいて認可する。AAAAレコード.
    • mx- はドメインのメールサーバーに基づいて認可する。
    • ptr- DNS 逆引きチェック (非推奨)。
    • 存在する- はドメインが解決されるかどうかをチェックする。
    • インクルード- 他のドメインのSPFレコードを参照する。

SPF調整剤

修飾子は、SPFレコードに追加の指示を加えるオプションの要素である。直接的にメールを許可したり拒否したりするものではありませんが、レコードの処理方法を柔軟に制御できるようになります。モディファイアはより高度な設定で使われることが多いが、常に必要というわけではない。

主な仕様

• オプションの追加指示を出す。
• 合否を直接決定しないこと。
• 一般的な修飾語：
  • redirect - 別のドメインのSPFレコードを指す。
  • exp - SPF失敗のカスタム説明を提供する。

• 通常はレコードの最後に表示される。

PowerDMARCでSPFを簡素化！

SPFレコード構文の例

実際のSPFレコードを見ると、各構成要素がどのように組み合わさるかを理解しやすくなります。以下に2つの例を示します：1つは単純な例、もう1つはより高度な例です。各例は正しい構文規則に従い、メカニズム、修飾子、修飾子が実際にどのように機能するかを示しています。

単純なSPFレコード

v=spf1 ip4:203.0.113.5 -all

内訳

• v=spf1→ SPF バージョン 1 であることを示すバージョンタグ。
• ip4:203.0.113.5→ IPv4アドレスを認可するメカニズム 203.0.113.5にメール送信を許可する仕組み。
• -すべて→ という修飾子とメカニズムを組み合わせると、リストにない他のすべてのサーバーがSPFチェックに失敗することになる。

なぜそれが有効なのか：

• レコードは正しいバージョンタグで始まる。
• メカニズム(ip4)は正しく書かれている。
• 修飾子 (-) は すべての.
• 構文は完全で、SPFルールに従っている。

 これは、1つのサーバーからメールを送信するだけの小規模ドメインでは一般的な設定です。

高度なSPFレコード

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:_spf.mailhost.com ~all exp=explain._spf.example.com

内訳:

• v=spf1→ 構文上必要な、先頭にあるバージョンタグ。
• ip4:203.0.113.0/24→ 範囲内のすべてのIPアドレスを認可するメカニズム 203.0.113.0 - 203.0.113.255.
• include:_spf.google.com→ Googleのメールサーバーがドメインに代わって送信できるようにする仕組み。
• include:_spf.mailhost.com→ 他のサードパーティプロバイダのサーバーを許可する仕組み。
• ~すべて→ 修飾子とメカニズムの組み合わせ。つまり、リストにないサーバーからのメッセージは受け入れられるが、疑わしいとマークされる。
• exp=explain._spf.example.com→ メッセージが SPF に失敗したときにカスタム説明文字列を提供するモディファイア。

なぜそれが有効なのか：

• 記録はバージョン・タグで始まる。
• 複数のメカニズムが含まれ、適切にフォーマットされている。
• 修飾子 ~は すべてに適用される。
• 修飾子 expが最後に正しく使われ、構文を崩すことなく機能を拡張している。

この設定は、複数の電子メール・プロバイダーを使用しながら、未承認のソースを制御している組織に典型的である。

正しいSPF構文のルールと検証

SPFレコードの作成は、仕組みと修飾子を正しい順序で並べ、レコードが実際に意図したとおりに動作することを確認することがすべてです。タグの欠落や余分なスペースなど、小さな構文の間違いでもレコードが失敗し、メールが拒否されたり、スパムとしてマークされたり、あなたのドメインがなりすましに遭いやすくなったりします。

このセクションでは、SPF構文を記述するためのベストプラクティス、避けるべき一般的な間違い、そして公開前にレコードを検証する方法の3つを取り上げます。

SPF構文のベストプラクティスに従う

SPFを正しく運用するには、記録を効果的かつ信頼性の高いものにするためのいくつかの黄金ルールに従うことから始まる：

• • 常に正しいバージョンタグで始めます： v=spf1.
  • 制限 DNSルックアップが 10ルックアップ制限レコードが壊れてしまいます。
  • を使用します。 インクルードループや循環参照を防ぐために、includeメカニズムを注意深く使うこと。
  • 記録はできるだけ簡潔に。複雑すぎる構成はメンテナンスが難しく、失敗する可能性が高くなる。
  • SPFレコードは定期的に見直しましょう。特に、メールインフラが変更になったり、プロバイダーの追加や削除を行った場合は要注意です。

よくある構文エラーを避ける

SPFの問題の多くは、単純だが有害な間違いから生じている。これらの落とし穴に気をつけよう：

• バージョンタグの欠落： すべてのレコードは v=spf1で始まる必要があります 。
• 修飾子の重複： 同じメカニズムに複数の修飾子を使用することは無効である。
• 過剰なメカニズム:長く、肥大化したレコードはエラーのリスクを高め、DNSの制限を超えます。
• 構文フォーマットの問題: 空白の入れ間違い、タイプミス、サポートされていない文字は、記録に失敗する原因になります。
• 複数のSPFレコード:複数のSPFレコードが存在する場合、検証は失敗します。
• 非推奨メカニズム: 避ける ptrを避ける。

たとえレコードの意図が正しくても、構文エラーはSPFを完全に失敗させる。

SPFレコードの構文を検証する

SPFレコードを公開する前に、検証を行うことが重要です。バリデータは、構文が正しいか、レコードがDNSルックアップの制限を超えていないか、サポートされていないメカニズムを含んでいないかをチェックします。

• SPFレコードチェックツールを使用する, PowerDMARCのSPFチェッカーのような SPFレコードチェックツールを使用して、問題を素早く特定することができます。
• 検証は、異なる受信メールサーバー間でレコードが一貫して機能することを保証するのに役立つ。
• 新しいレコードや更新されたレコードを本番に適用する前に、ステージング環境でテストすることをお勧めします。
• 変更後に定期的に検証を行うことで、SPFポリシーは常に最新で機能的な状態に保たれます。

バリデーションを行うことで、メールがバウンスしたり、スパムに送信されたり、ドメインがなりすましに遭いやすくなったりするリスクを減らすことができます。

SPFレコード構文の動作

正しいSPFレコードの構文は、安全なメール配信に不可欠です。 メール配信となりすましからの保護に不可欠です。バージョンタグ、メカニズム、修飾子、モディファイアなどの各部分は、メールサーバーがあなたのメッセージをどのように扱うかを導くために連動します。

ベストプラクティスに従い、エラーを避け、定期的に検証を行うことで、失敗のリスクを減らし、ドメインを安全に保つことができます。メール設定が進化するにつれ、継続的なアップデートは不可欠です。より簡単な管理と強固なセキュリティのために、PowerDMARCのご利用をご検討ください。

よくあるご質問

SPFレコードの書き方

で始める 'v=spf1', 追加 メカニズム を リスト 認可された を追加する、 そして 最後に で終わる。 a のような修飾子 '-all'のような修飾子をつけると、他のすべてをブロックすることができる。

SPFレコードの構文が間違っているとどうなりますか？

メールサーバーがあなたのメールを拒否したり、スパムとしてフラグを立てたりする可能性があり、あなたのドメインはなりすましに遭いやすくなります。

SPFレコードMXの例は？

MX (MXレコード)を使ったSPFレコードは次のようになります： v=spf1 mx -allのようになり、ドメインのメールサーバーだけがメールを送信できるようになります。

• について
• 最新記事

Ahona Rudra

ドメインとメールセキュリティのエキスパートPowerDMARC

AhonaはPowerDMARCのマーケティングマネージャーで、サイバーセキュリティのトピックについて5年以上の執筆経験があり、ドメインと電子メールのセキュリティを専門としている。ジャーナリズムとコミュニケーションの卒業後学位を取得し、2019年からセキュリティ分野でキャリアを固めている。

最新記事 by Ahona Rudra(全て見る)

• 人事部門のメールおよび給与計算のセキュリティ：グローバルチームのためのベストプラクティス - 2026年6月22日
• Microsoft Entra でリスクの高い AI エージェントをブロックする方法 - 2026年6月15日
• Office 365 フィッシング対策ポリシー：設定方法 - 2026年6月3日