SPF クオリファイア（Qualifier）

概要

SPF クオリファイア（Qualifier） は、SPF レコードのメカニズムの前に付ける 1 文字の記号（+、-、~、?）で、そのメカニズムに一致した場合の評価結果を指定します。RFC 7208（2014年）で定義されています。

クオリファイアを省略した場合のデフォルトは +（pass）です。実運用で最も使われるのは all メカニズムと組み合わせた -all（hardfail）と ~all（softfail）で、許可リスト外の送信元をどう扱うかを宣言します。

DMARC を p=reject で運用している環境では、SPF のクオリファイアが -all でも ~all でも DMARC の判定に差はありません。ただし、DMARC を導入していないドメインでは、クオリファイアの選択が受信側の処理に直接影響します。

仕組み

クオリファイアは +（pass）、-（fail）、~（softfail）、?（neutral）の 4 種類があり、主に all メカニズムとの組み合わせで使います。

4 種類のクオリファイア

クオリファイア	結果	意味
+	pass	送信を許可する（デフォルト。省略時と同じ）
-	fail（hardfail）	送信を明示的に拒否する
~	softfail	拒否はしないが不審として扱う
?	neutral	何も判断しない（SPF がない場合と同等）

クオリファイアの適用

クオリファイアはすべてのメカニズムに付けられます。

v=spf1 +ip4:203.0.113.0/24 ~include:_spf.google.com -all

この例では、203.0.113.0/24 に一致すれば pass、Google Workspace の IP に一致すれば softfail（~include は参照先がmatchした場合に ~ を返すため）、いずれにも一致しなければ fail です。ただしこれは意図と逆になるため、実際には include に ~ や - を付ける設定は使いません。クオリファイアを使い分けるのは all メカニズムがほとんどです。

all メカニズムとの組み合わせ

all はすべての送信元 IP に一致するメカニズムで、SPF レコードの末尾に置いて「それ以外」のデフォルト動作を定義します。

-all は許可リスト外の送信元を hardfail にします。受信サーバーはメールを拒否する根拠にできます。

~all は softfail にします。受信サーバーはメールを受け入れるがスパム疑いとしてマークする可能性があります。DMARC 導入前は -all と ~all の選択が配信に影響しましたが、DMARC p=reject の環境では実質的な差はありません。

?all は neutral です。SPF レコードの存在を宣言しつつも、許可リスト外について何も判断しません。テスト目的以外ではほぼ使いません。

+all はすべての IP を pass にします。なりすまし対策が無効化されるため、設定してはいけません。

受信側の処理

クオリファイアの結果をどう扱うかは受信プロバイダーの実装に依存します。Gmail は SPF hardfail 単体でメールを拒否するとは限りませんが、DMARC と組み合わせて最終判定します。Microsoft 365 も同様に DMARC ポリシーを優先します。SPF クオリファイアはあくまでドメイン所有者の「意思表示」であり、最終的な処理は受信側が決定します。

設定例

送信インフラの管理状況と DMARC ポリシーに応じて、-all または ~all を選択します。

推奨設定（-all）

example.com.  IN  TXT  "v=spf1 include:_spf.google.com -all"

許可リスト外の送信元を明示的に拒否します。DMARC を併用する場合の推奨設定です。

移行期の設定（~all）

example.com.  IN  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

送信インフラの移行中や、送信元の洗い出しが完了していない段階では ~all にしておくと、正規メールを誤って拒否するリスクを抑えられます。

メールを送信しないドメイン

parked.example.com.  IN  TXT  "v=spf1 -all"

メカニズムを一切含めず -all だけ記述すると、そのドメインからのメール送信をすべて拒否します。パーキングドメインやメール送信しないサブドメインで使います。

確認方法

SPF レコードのクオリファイアは dig で確認できます。

dig TXT example.com

;; ANSWER SECTION:
example.com.		3600	IN	TXT	"v=spf1 include:_spf.google.com -all"

レコード末尾の all メカニズムの前の記号を確認します。-all は hardfail、~all は softfail です。

外部の視点からも確認したい場合は、Labee Dev Toolbox の Mail Auth API を使うと、外部の視点から見た結果を取得できます。

curl "https://labee.dev/api/mail-auth?domain=example.com"

{
  "success": true,
  "data": {
    "spf": {
      "record": "v=spf1 include:_spf.google.com -all",
      "exists": true
    },
    "dkim": { "record": null, "exists": false, "selector": "default" },
    "dmarc": { "record": null, "exists": false },
    "bimi": { "record": null, "exists": false }
  },
  "error": null,
  "meta": { "responseTime": 123 }
}

data.spf.record の末尾でクオリファイアを確認できます。

よくある問題

クオリファイアの設定ミスは、なりすまし対策の無効化や include との誤った組み合わせとして現れます。

+all を設定している

+all はすべての IP からの送信を pass にする設定で、SPF の意味がなくなります。スパマーがそのドメインを自由になりすませる状態です。-all または ~all に修正します。

~all と -all の違いを過大評価する

DMARC p=reject を運用しているドメインでは、SPF が softfail でも hardfail でも DMARC の最終判定に影響しません。DMARC がない環境では -all の方が受信側に強い拒否シグナルを送れますが、DMARC と併用する前提であればどちらでも実用上の差はありません。

クオリファイアを include に付ける

-include:_spf.google.com のようにクオリファイアを include に付けることは構文上可能ですが、意図と逆の結果になります。この記述は「Google Workspace のサーバーから送信された場合に fail を返す」という意味になり、Google Workspace からの送信を許可したいという意図と真逆です。include には + 以外のクオリファイアを付けず、許可リスト外のデフォルト動作は all メカニズムで指定します。