SPF all メカニズム（All Mechanism）
概要
SPF all メカニズム（All Mechanism） は、SPF レコードの末尾に記述し、それまでのメカニズム（ip4:、include: 等）に一致しなかった送信元 IP に対するデフォルトの処理を指定します。RFC 7208（2014年）の Section 5.1 で定義されており、SPF レコードの評価における最終判定を担います。
all の前に付く修飾子（qualifier）によって、4 種類の動作があります。
| 記述 | 修飾子 | 結果 | 意味 |
|---|---|---|---|
-all | -（fail） | fail | 許可リスト外の IP からの送信を拒否する |
~all | ~（softfail） | softfail | 許可リスト外をスパム疑いとしてマークする |
?all | ?（neutral） | neutral | SPF の判定を行わない（ポリシーなし） |
+all | +（pass） | pass | すべての IP からの送信を許可する |
実運用で使われるのは -all と ~all の 2 つです。?all は SPF を設定していないのと実質同じで、+all はインターネット上の全サーバーに送信を許可するため、設定してはいけません。
all メカニズムを省略した場合、RFC 7208 は結果を neutral として扱うと定めています。省略は ?all と同等であり、SPF レコードを公開していながら何も判定しないという矛盾した状態になります。SPF レコードには必ず all を明示してください。
仕組み
all メカニズムは SPF レコードの末尾に配置し、前のメカニズムに一致しなかった IP に対するデフォルト処理を決定します。
評価の流れ
受信サーバーが SPF レコードを評価する際、メカニズムは左から右へ順番に処理されます。送信元 IP がいずれかのメカニズムに一致した時点でそのメカニズムの修飾子が結果になり、残りのメカニズムは評価されません。
all はどんな IP にも一致するメカニズムです。レコードの末尾に置くことで、他のメカニズムに一致しなかった IP を漏れなく捕捉します。
v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~allこの例では、送信元 IP が 203.0.113.0/24 に含まれるか、Google のメールサーバー IP に含まれれば pass になります。どちらにも一致しなければ、~all により softfail が返ります。
-all と ~all の使い分け
-all（hardfail）と ~all（softfail）のどちらを選ぶかは、メール配信環境とDMARCポリシーに依存します。
-all は「許可リスト外からの送信は一切認めない」という厳格な宣言です。許可リストの管理が正確であれば、なりすましメールに対する防御力が最も高い設定になります。
~all は「許可リスト外はスパム疑いとしてマークするが、受信サーバーの裁量に任せる」という柔軟な宣言です。受信サーバーの多くは softfail をスパムフィルタのスコアリングに使い、直接拒否はしません。
ただし DMARC を p=reject で運用している場合、SPF が -all でも ~all でも実用上の差はほとんどありません。DMARC はSPFの結果（fail か softfail か）にかかわらず、アライメントの合否で最終判定を行います。SPF が softfail でもアライメントに失敗すれば DMARC は fail を返し、p=reject に従って受信サーバーがメールを拒否します。
現在の業界標準は ~all です。DMARC の普及により、SPF 単体の fail / softfail の区別よりも DMARC ポリシーが最終的な配信判定を左右するようになったためです。~all を選んでおけば、メール転送や中継サーバーを経由した場合に SPF が fail を返しても、DKIM の pass で DMARC を通過できる余地が残ります。
+all と ?all が危険な理由
+all は修飾子を省略した場合のデフォルト（RFC 7208 Section 4.6.2）でもあり、全 IP を許可します。SPF レコードに +all を書くと、任意のサーバーからそのドメインを名乗ったメールを送信でき、SPF はすべて pass を返します。なりすまし対策としてSPFを導入している意味がなくなります。
?all は neutral を返すため、SPF の検証結果が判定に影響しません。DMARC のアライメント検証では SPF の結果が neutral だとSPF側のアライメントが成立せず、DKIMだけで DMARC を通過させる必要があります。意図的に SPF の判定を無効にしたい特殊な事情がない限り、使う理由はありません。
all の位置とレコード構文
all は必ずレコードの末尾に書きます。all より後ろに書いたメカニズムは評価されません。
v=spf1 include:_spf.google.com ~all ip4:203.0.113.10上記の ip4:203.0.113.10 は ~all の後にあるため、到達しません。203.0.113.10 からのメールは softfail として処理されます。
RFC 7208 では、all の後にメカニズムがある場合の動作は明確に禁止されていないものの、実装によっては警告を出すかパース自体を止めるため、避けてください。
設定例
all の修飾子は送信環境と DMARC ポリシーに合わせて選択します。
メールを送信するドメイン
Google Workspace を利用している場合の標準的な SPF レコードです。
example.com. IN TXT "v=spf1 include:_spf.google.com ~all"include:_spf.google.com で Google のメールサーバー IP を許可し、~all で残りの IP を softfail にしています。
複数サービスの併用
Google Workspace と SendGrid を併用する場合も、1 つの TXT レコードにまとめます。
example.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ~all"メールを送信しないドメイン
メールを一切送信しないドメイン（パーキングドメイン、リダイレクト専用ドメイン等）には、-all のみを書きます。
park.example.com. IN TXT "v=spf1 -all"他のメカニズムを一切書かず -all だけを指定すると、「このドメインからは誰もメールを送信しない」という宣言になります。なりすましメールの踏み台にされることを防ぎます。
DMARC p=reject 環境での指定
DMARC を p=reject で運用している場合、SPF は ~all で十分です。
example.com. IN TXT "v=spf1 include:_spf.google.com ~all"_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"DMARC が p=reject であれば、SPF softfail + アライメント不一致のメールは DMARC により拒否されます。SPF 側を -all にする追加効果はほとんどありません。
確認方法
ドメインの SPF レコードを確認するには dig を使います。
dig TXT example.com +short出力から v=spf1 で始まる行を探し、末尾の all 修飾子を確認します。
"v=spf1 include:_spf.google.com ~all"~all であれば softfail、-all であれば hardfail です。末尾に all が書かれていない場合は neutral 扱いになるため、追記が必要です。
外部の視点からも確認したい場合は、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": "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...", "exists": true, "selector": "default" },
"dmarc": { "record": "v=DMARC1; p=reject; rua=mailto:dmarc@example.com", "exists": true },
"bimi": { "record": null, "exists": false }
},
"error": null,
"meta": { "responseTime": 123 }
}data.spf.record フィールドに SPF レコードの内容が返ります。data.spf.exists が true であれば、外部から SPF レコードが確認できる状態です。レコード末尾の all 修飾子が意図した設定かどうかを確認してください。
よくある問題
all メカニズムの設定ミスは、正規メールの拒否やなりすまし対策の無効化に直結します。
~all から -all に変えたらメールが届かなくなった
-all に変更したあと、許可リストに登録していない経路（社内の複合機、監視システム、CRM のメール送信機能等）からのメールが fail になり、受信サーバーに拒否されるケースがあります。
~all から -all への移行は段階的に進めてください。DMARC を p=none + rua で運用してレポートを収集し、すべての正規送信元が SPF に登録されていることを確認してから -all に変更します。
+all が設定されている
+all は全 IP からのメールを pass にするため、SPF による保護が無効になります。DNS の設定画面で SPF レコードを確認し、+all を ~all または -all に修正してください。
+all が入っていると、DMARC の SPF アライメントは常に pass を返すため、一見問題がないように見えます。しかし、なりすましメールも pass になるため、SPF を導入している意味がありません。
all を書き忘れている
SPF レコードの末尾に all が記述されていない場合、RFC 7208 により結果は neutral として扱われます。neutral は SPF を設定していないのと実質同じで、DMARC のSPFアライメントも成立しません。
v=spf1 include:_spf.google.com上記のレコードは all がないため、Google の IP に一致しない送信元に対して neutral を返します。末尾に ~all または -all を追記してください。
all の後にメカニズムを記述してしまった
all はすべての IP に一致するため、all より後ろのメカニズムは評価されません。
v=spf1 ~all include:_spf.google.com上記のレコードでは、すべての IP が ~all に一致して softfail を返し、include:_spf.google.com は無視されます。Google のメールサーバーからの送信も softfail になり、DMARC アライメントに失敗します。
all は必ずレコードの最後に配置してください。