SPFレコードの構文:メカニズム、修飾子、モディファイア

要点まとめ

1. レコードの読み取り方 SPFレコードは、TXTレコードとして公開される1行のテキストです。
2. 修飾子 修飾子は、メカニズムの直前に置く1文字です。
3. DNSルックアップが不要なメカニズム ip4とip6のメカニズムは、リテラルのアドレスや、CIDR表記の範囲に一致します。
4. DNSルックアップを消費するメカニズム includeメカニズムは、受信側に別のドメインのSPFレコードを評価させ、そのレコードがパスすれば一致とします。
5. モディファイア:redirectとexp モディファイアは名前=値の形式で記述し、送信元アドレスを調べるテストではありません。
6. 長さと形式の制限 TXTレコード内の各文字列は、最大255文字です。

レコードの読み取り方

SPFレコードは、TXTレコードとして公開される1行のテキストです。バージョンタグのv=spf1で始まり、その後にスペースで区切られた項目が並びます。受信サーバーは、接続してきたIPアドレスに対して項目を左から右へ評価し、最初に一致した項目が結果を決めます。

v=spf1 ip4:203.0.113.10 include:_spf.example.net ~all

どの項目にも一致せず、redirectもない場合の結果はニュートラルです。そのため、ほとんどのレコードはallの項目で終わります。allはすべてに一致するので、リストにないサーバーをどう扱うかを最後に必ず示せるからです。

修飾子

修飾子は、メカニズムの直前に置く1文字です。そのメカニズムが一致したときの結果を決めます。修飾子を付けない場合はプラスとみなされるため、mxと+mxは同じ意味です。

-all   fail: not authorised
~all   softfail: probably not authorised
?all   neutral: no opinion
+all   pass: everyone is authorised (never use this)

結果は、パス(プラス)、失敗(マイナス)、ソフトフェイル(チルダ)、ニュートラル(疑問符)の4つです。受信側は通常、失敗とソフトフェイルを、拒否の指示ではなく否定的なシグナルとして扱い、失敗したメッセージをどうするかはDMARCが決めます。

DNSルックアップが不要なメカニズム

ip4とip6のメカニズムは、リテラルのアドレスや、CIDR表記の範囲に一致します。受信側が調べるものがないため、レコードの中で最も負担の少ない部分であり、プロバイダーが固定の送信アドレスを公開している場合には最も安全な選択です。

ip4:203.0.113.0/24
ip6:2001:db8::/32
all

allメカニズムは、すべてのアドレスに一致します。末尾に置いてください。その後ろに書いた項目には到達しません。

DNSルックアップを消費するメカニズム

includeメカニズムは、受信側に別のドメインのSPFレコードを評価させ、そのレコードがパスすれば一致とします。aメカニズムはドメインのアドレスレコードに、mxはメールサーバーのアドレスに一致します。どちらも、デフォルトでは確認対象のドメインが使われ、ドメインとCIDRの長さを指定できます。existsメカニズムは名前が解決できれば一致し、ptrは逆引きDNSで照合します。

include:_spf.example.net
a
a:mail.example.com/24
mx
exists:%{i}._spf.example.com

include、a、mx、ptr、existsのそれぞれと、redirectモディファイアは、10回というDNSルックアップの上限に数えられ、includeの中のincludeも数えられます。また、標準ではmxメカニズムが扱うメールサーバーは10台までと定められています。標準はptrの使用を推奨していません。遅くて信頼性が低いため、使わないようにしてください。

モディファイア:redirectとexp

モディファイアは名前=値の形式で記述し、送信元アドレスを調べるテストではありません。redirectモディファイアは、このレコードの残りを無視して、代わりに別のドメインのレコードを使うという意味です。どのメカニズムにも一致しなかった場合にだけ参照され、allの項目があるレコードでは到達しません。

v=spf1 redirect=_spf.example.net

expモディファイアは、SPFが失敗したときに受信側が表示できる説明文を保持するTXTレコードのドメインを指定します。ほとんどのドメインでは使われていません。同じ名前は、1つのレコードに最大1回しか記述できません。

長さと形式の制限

TXTレコード内の各文字列は、最大255文字です。それより長いレコードは複数の文字列として保存され、受信側がそれらを連結します。多くのDNS管理画面では、長い値を自動で分割してくれます。非常に長いレコードは通常のDNS応答のサイズを超えることもあるため、これもリストを短く保つべき理由の1つです。

項目は1つ以上のスペースで区切り、大文字と小文字は区別されません。レコードは1つのTXTレコードにまとめてください。SPFレコードが2つあるドメインは、恒久的なエラーになります。

レコードを壊す構文エラー

失敗の多くは、v=spf1の欠落、ドメインのないinclude、inlcludeのようなメカニズムのつづり間違い、ip4:203.0.113.300のようなアドレスの誤り、コピー&ペーストで紛れ込んだ余計な文字といった、ちょっとしたミスから起こります。どれか1つでもあると、レコード全体が無効になり、結果は恒久的なエラーになります。

公開する前にテストしてください。当社のSPFチェッカーは、貼り付けたレコードを読み取り、問題点を示し、DNSルックアップ数を数えるので、公開前にレコードを修正できます。

参考資料と出典

• RFC 7208: Sender Policy Framework (SPF)
• Google Workspace: Define your SPF record

MigoSMTPで実践:ヘルプセンターの記事

• SPFのpermerrorと10回のルックアップ上限を解消する
• MigoSMTPで送信ドメインを認証する:SPF、DKIM、DMARC
• 送信ドメインを検証する:DNSレコードと反映

関連ガイドとツール

• SPFレコードチェッカー:レコードを貼り付けるか、ドメインを確認します。
• SPFレコードジェネレーター:上限内に収まるレコードを作成します。
• SPFレコードの作り方:ステップごとのガイド。
• SPFレコードの例:Workspace、Microsoft 365など。