SPFレコードの構文をわかりやすく解説
著者: Ahona Rudra
翻訳: 東條 百々朱
この記事はPowerDMARCのブログ記事 SPF Record Syntax: Components, Rules, and Examples の翻訳です。
Spelldataは、PowerDMARCの日本代理店です。
この記事は、PowerDMARCの許可を得て、翻訳しています。
主なポイント
- SPFは、特定のメールサーバだけに自社ドメインからのメール送信を許可することで、なりすましメールを防止します。
- SPFレコードでは、ディレクティブ、修飾子、メカニズムを使用して、許可する送信元と認証失敗時の処理を定義します。
- 受信メールサーバは、DNSに公開されたSPFレコードを参照し、送信元に送信権限があるかどうかを検証します。
- SPFの認証結果にはPass、Neutral、Failなどがあり、メールの信頼性を判断する材料として利用されます。
- 「exp」や「redirect」などのモディファイアを利用すると、SPFの動作をより柔軟に制御できます。
正当なメールであるにもかかわらず、迷惑メールフォルダへ振り分けられたり、受信拒否されたりした経験はありませんか。
その原因の一つとして、ドメインのメール認証設定に問題がある可能性があります。
その中でも重要な役割を果たすのがSPF（Sender Policy Framework）レコードです。
SPFは、メールが許可されたサーバから送信されたことを確認し、なりすましメールを防ぐための重要な仕組みです。
しかし、SPFレコードの構文は分かりづらく、正しく設定するのは決して簡単ではありません。
この記事では、SPFレコードの構文の基本から、各構成要素の役割、設定時の注意点まで分かりやすく解説します。
SPFレコードの構文とは
SPFレコードの構文とは、DNSへ登録するSPF（Sender Policy Framework）レコードの記述方法を定めたルールです。
簡単に言えば、「どのメールサーバが自社ドメインを代表してメールを送信できるのか」を受信メールサーバへ伝えるための記述方法です。
SPFレコードには、通常、ip4、ip6、includeなどのメカニズム、+、-、~、?などの修飾子、そしてモディファイアが含まれます。
これらを組み合わせることで、受信メールがSPF認証に合格するかどうかを判断します。
SPFレコードは、わずかな記述ミスでも正しく機能しません。
余分なスペースや修飾子の誤り、必要なメカニズムの記述漏れなどがあると、メール認証に失敗し、メールが迷惑メールとして扱われたり、受信拒否されたりする可能性があります。
SPFレコード構文の構成要素
SPFレコードは、次の4つの要素で構成されています。
- バージョンタグ
- メカニズム
- 修飾子
- モディファイア
それぞれに役割があり、これらを組み合わせることで、受信メールサーバは送信元メールの正当性を判断します。
- バージョンタグ
- SPFレコードであることを示します。
- メカニズム
- メール送信を許可する送信元を指定します。
- 修飾子
- 条件に一致した場合の判定結果を指定します。
- モディファイア
- SPFポリシを補足・拡張するための追加設定です。
バージョンタグ
バージョンタグは、SPFレコードの先頭に必ず記述する要素です。
このタグによって、DNSレコードがSPFであることを受信メールサーバへ伝えます。
バージョンタグが正しく記述されていなければ、そのSPFレコードは無効になります。
主なルールは以下のとおりです。
- 必ずレコードの先頭に記述する
- 使用できるバージョンタグは1つだけ
- 現在使用する形式は
v=spf1 - バージョンタグが誤っている、または省略されている場合は無効になる
SPF修飾子
修飾子は、各メカニズムの前に付ける記号です。
条件に一致した場合、受信メールサーバがどのように判定するかを指定します。
つまり、「許可する」「拒否する」「疑わしいものとして扱う」といった判定を制御する役割があります。
修飾子を省略した場合は、+（Pass）が指定されたものとして扱われます。
主な修飾子は次の4種類です。
| 修飾子 | 意味 |
|---|---|
+ |
Pass（許可） |
- |
Fail（拒否） |
~ |
SoftFail（受信はするが疑わしいメールとして扱う） |
? |
Neutral（判定を行わない） |
ポイントは以下のとおりです。
- メカニズムの先頭に付けて使用する
- SPF認証結果を制御する
- 指定しない場合はPass（
+）として扱われる
SPFメカニズム
メカニズムは、SPFレコードの中心となる要素です。
どのサーバやIPアドレス、ドメインにメール送信を許可するかを定義します。
受信メールサーバは、メカニズムを左から順番に評価し、一致した時点で対応する修飾子の判定を適用します。
一致するものがない場合は、レコードの最後まで評価が続きます。
主なポイントは以下のとおりです。
- メール送信を許可する送信元を定義する
- 左から順番に評価される
- 修飾子と組み合わせて認証結果を決定する
- 標準で利用できるメカニズムは8種類
各メカニズムの役割は以下のとおりです。
| メカニズム | 内容 |
|---|---|
all |
すべての送信元に一致する |
ip4 |
指定したIPv4アドレスからの送信を許可する |
ip6 |
指定したIPv6アドレスからの送信を許可する |
a |
ドメインのAレコードまたはAAAAレコードを送信元として許可する |
mx |
ドメインのMXレコードで指定されたメールサーバを許可する |
ptr |
逆引きDNSで送信元を確認する（現在は非推奨） |
exists |
指定したドメインが名前解決できるかを確認する |
include |
他のドメインのSPFレコードを参照する |
SPFモディファイア
モディファイアは、SPFレコードに追加情報を与えるための任意の設定です。
メールを直接許可・拒否するものではありませんが、SPFの動作を柔軟に制御できます。
高度な設定で利用されることが多く、通常のSPFレコードでは使用しないケースもあります。
主なポイントは以下のとおりです。
- SPFレコードへ追加情報を与える
- PassやFailを直接判定するものではない
- 一般的に使用されるモディファイアは2種類
| モディファイア | 内容 |
|---|---|
redirect |
他のドメインのSPFレコードへ処理を委任する |
exp |
SPF認証に失敗した際の説明メッセージを指定する |
通常、モディファイアはSPFレコードの末尾に記述します。
SPFレコード構文の例
実際のSPFレコードを見ることで、それぞれの構成要素がどのように組み合わされているのか理解しやすくなります。
ここでは、シンプルな例と、複数の送信サービスを利用する場合の例をご紹介します。
シンプルなSPFレコード
v=spf1 ip4:203.0.113.5 -all
レコードの内容
v=spf1- このレコードがSPFバージョン1であることを示します。
ip4:203.0.113.5- IPv4アドレス「203.0.113.5」からのメール送信を許可します。
-all- 上記で許可した送信元以外から送信されたメールは、SPF認証に失敗（Fail）として扱います。
このレコードが有効な理由
- 正しいバージョンタグから始まっている
ip4メカニズムが正しく記述されているallに対して-修飾子が正しく指定されている- 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- SPFレコードであることを示します。
ip4:203.0.113.0/24- 203.0.113.0～203.0.113.255までのIPアドレスからの送信を許可します。
include:_spf.google.com- Google Workspaceのメールサーバからの送信を許可します。
include:_spf.mailhost.com- 外部メールサービスのSPFレコードを参照し、その送信元を許可します。
~all- 一覧に含まれていない送信元からのメールは受信するものの、「疑わしいメール（SoftFail）」として扱います。
exp=explain._spf.example.com- SPF認証に失敗した際に表示する説明文を指定します。
このレコードが有効な理由
- バージョンタグが正しく記述されている
- 複数のメカニズムが正しい順序で記述されている
~allが適切に設定されているexpモディファイアが末尾に配置されている
このような構成は、Google Workspaceや外部メール配信サービスなど、複数のメールサービスを利用している企業でよく採用されています。
正しいSPF構文のルールと検証方法
SPFレコードは、決められた構文ルールに従って記述しなければ正しく機能しません。
わずかな入力ミスでも認証エラーの原因となり、メールが迷惑メールとして扱われたり、受信拒否されたりする可能性があります。
ここでは、SPFレコードを正しく運用するためのポイントをご紹介します。
SPF構文のベストプラクティス
SPFレコードを安全かつ効率的に運用するために、以下の点を意識しましょう。
- レコードは必ず
v=spf1から始める - DNSルックアップは10回以内に抑える
includeは必要最小限にする- レコードはできるだけシンプルに保つ
- メールサービスの追加・変更時にはSPFレコードも更新する
SPFレコードは長く複雑になるほど管理が難しくなり、設定ミスの原因にもなります。
不要な設定は避け、できるだけシンプルな構成を心掛けましょう。
よくある構文エラー
SPF認証が失敗する原因の多くは、単純な記述ミスです。
代表的な例は以下のとおりです。
- バージョンタグがない
- すべてのSPFレコードは
v=spf1から始める必要があります。
これがない場合、SPFレコードとして認識されません。 - 修飾子の誤った使い方
- 1つのメカニズムに複数の修飾子を付けることはできません。
例えば、以下のような記述は無効です。+-all
- メカニズムを増やしすぎる
- 不要な
includeや複数のメカニズムを追加すると、- DNSルックアップ回数の上限超過
- 管理性の低下
- 設定ミス
- スペースや入力ミス
- 余計なスペースやタイプミスだけでもSPFは正常に動作しません。
例えば、以下のような記述は無効になります。ip4 :203.0.113.5
- SPFレコードが複数存在する
- 1つのドメインに設定できるSPFレコードは1つだけです。
複数登録するとSPF認証は失敗します。 - 非推奨の
ptrを使用している ptrメカニズムは現在では非推奨です。
互換性や処理速度の観点からも、使用は避けることが推奨されています。
SPFレコードを検証する
SPFレコードは公開前に必ず検証しましょう。
検証ツールを使用することで、以下の項目などを事前に確認できます。
- 構文エラー
- DNSルックアップ回数
- サポートされていないメカニズム
- 設定ミス
PowerDMARCのSPFチェッカのようなツールを利用すれば、SPFレコードの問題点を簡単に確認できます。
また、新しいSPFレコードを本番環境へ適用する前に、テスト環境で動作確認を行うことも重要です。
設定後も定期的に検証することで、メールサービスの追加や変更による設定漏れを防ぎ、SPFレコードを常に最新の状態に保つことができます。
その結果、以下のようなリスクを大幅に軽減できます。
- メールの受信拒否
- 迷惑メール判定
- ドメインのなりすまし
まとめ
正しいSPFレコードの構文を理解し、適切に設定することは、安全なメール配信となりすまし対策の基本です。
SPFレコードは、バージョンタグ・メカニズム・修飾子・モディファイアで構成されており、それぞれが連携することで、受信メールサーバは送信元メールの正当性を判断します。
SPFを適切に運用するためには、構文ルールを守ることはもちろん、DNSルックアップ数の制限や不要なメカニズムの追加にも注意が必要です。
また、メールサービスの追加や変更に合わせてSPFレコードを定期的に見直し、公開前や変更後には検証ツールで動作を確認することも重要です。
適切に管理されたSPFレコードは、メール認証の信頼性を高めるだけでなく、メールの到達率向上や、なりすましメール対策にも大きく貢献します。
SPFの設定や運用をより効率的に行いたい場合は、PowerDMARCのような管理ツールを活用することで、設定ミスを防ぎながら継続的な運用を実現できます。
よくある質問
- SPFレコードはどのように記述しますか？
- SPFレコードは、
v=spf1から始め、メール送信を許可する送信元をメカニズムで指定します。
最後に-allや~allなどの修飾子を記述し、それ以外の送信元をどのように扱うかを定義します。
例えば、特定のメールサーバだけを許可する場合は、次のように記述します。
v=spf1 ip4:203.0.113.5 -all
- SPFレコードの構文が間違っているとどうなりますか？
- SPFレコードに構文エラーがあると、受信メールサーバが正しく認証できなくなります。
その結果、以下のような問題が発生する可能性があります。- メールが受信拒否される
- 迷惑メールフォルダへ振り分けられる
- なりすまし対策として機能しなくなる
- MXを使用したSPFレコードの例を教えてください。
- MXレコードに登録されているメールサーバだけにメール送信を許可する場合は、次のように記述します。
v=spf1 mx -all
この設定では、ドメインのMXレコードに登録されているメールサーバのみが、自社ドメインからメールを送信できます。