SPFレコードのall修飾子の違い｜~allと-allはどちらにすべきか

結論 — 3つは直す対象で、残る2つは選択です

SPFレコードは、末尾にallという機構を置きます。allに付ける修飾子によって、記載外の送信元をどう扱うかが受信側に伝わります。

とりうる状態は、5つです。+all・?all・「allもredirectも無い」の3つは、直す対象です。仕様の上では許容されていますが、なりすまし対策として、機能しません。残る~allと-allは、どちらも仕様上正しい設定で、どちらを選ぶかは運用の判断です。

allが無くてもredirectでほかのレコードに委譲している場合は、委譲先のレコードの判定がそのまま使われます。この場合に見るのは自分のレコードの末尾ではなく委譲先のallです。委譲先が+allや?allなら、やはり直す対象になります。ルートのレコードにallを足すと委譲そのものが無効になるので、直す場所は委譲先です。詳しくはただしredirectを使っている場合は別ですを確認してください。

本サイトの診断は、直す対象の3つすべてに対して~allへの変更を提案します。理由は後半で説明します。~allと-allのどちらにすべきか迷って検索から来た方は、先にどちらを選ぶかへ進んでください。

いまの自分の値を確かめる

自分のSPFレコードを次のコマンドで確認できます。

dig +short txt example.jp

example.jpの部分を自分のドメインに置き換えてください。表示された文字列の末尾を見ます。

• +allの場合は、直す対象です
• ?allの場合も、直す対象です
• 末尾にallが無く、redirectも書かれていない場合は、直す対象です
• 末尾にallが無いがredirect=が書かれている場合は、委譲先のレコードを引いてその末尾を見てください。委譲先が~allまたは-allなら直す対象ではありません。+all・?all・allが無い場合は、委譲先のほうを直します。ルートのレコードにallを足さないでください。足すとredirectが無視され、委譲先の設定が働かなくなります。詳しくはただしredirectを使っている場合は別ですを確認してください
• ~allまたは-allの場合は、どちらも仕様上正しい状態です。どちらにすべきか迷っている場合は、どちらを選ぶかへ進んでください

複数のTXTレコードが返る場合や、レコードの意味が読み取れない場合は、メール認証の診断にドメインを入力すると末尾の状態を含めて判定した結果が表示されます。

5つの状態と受信側が返す結果

allに付く修飾子は4種類あり、省略した場合は+が既定です（RFC 7208 セクション4.6.2）。

この表だけを見て「~allは迷惑メール扱いになる」「-allにすれば拒否される」と断定しないでください。セクション8.5は、softfailだけを理由に拒否してはならないとしています（SHOULD NOT）。ただし、より厳しく精査することは認めています（MAY）。セクション8.4も、failの処分を「受信側のローカルポリシーの問題（a matter of local policy）」としています。仕様が定めているのはSPFの判定結果までで、受信側がその結果をどう扱うかには規範的な要求を置いていません（セクション2.6、"the protocol establishes no normative requirements for handling any particular result"）。

実測の分布（2026-08-20）

Majestic Millionに掲載されている.jpドメイン19,535件を対象に、公開されているSPFレコードの末尾を測定しました。母集団は被リンクの多い順に並んだ一覧からの抽出で、.jpドメイン全体からの無作為抽出ではありません。DNS問い合わせ75,769回、出典は/data/に置いたjp-spf-policy-2026-08-20.json、再現スクリプトはscripts/measure-spf-policy.mjsです。

SPFレコードが見つかったのは15,492件（19,535件中79.3%）でした。このうち123件はSPFレコードが2本以上あったドメインです。この状態はそれだけでPermErrorになり（RFC 7208 セクション4.5）、適用されるallが存在しないため、以下の内訳からは外しています。分母はレコードが1本だけだった15,369件です。

数えているのはレコードの末尾に書かれている文字ではなく、受信側に実際に適用される修飾子です。redirectで委譲している場合は、委譲先の値を委譲先の行に数えています（RFC 7208 セクション6.1）。

+allは件数のまま示しています。15,369件中2件で、比率にすると0%と表示され、実在することが読み取れなくなるためです。

このうち58件は、自分のレコードにallを書かず、redirectで委譲した先の値が適用されていたものです。内訳は~allが44件、?allが8件、-allが6件でした。委譲先を引けずに判定を保留したドメインは0件です。この扱いの根拠は、後述のただしredirectを使っている場合は別ですで説明します。

+allは、SPFを設定していない状態より弱くなります

+allが付いているとどのIPアドレスからの送信でもpassと判定されます（RFC 7208 セクション4.6.2）。攻撃者は、エンベロープの送信元を自分で自由に書き換えられるので、送信元をあなたのドメインに一致させればSPFのpassを得られます。

pass単体では、まだDMARCは通りません。ただしDMARCが必要とするのは「SPFまたはDKIMのpass判定に加えて、Author Domainと整合していること」で（RFC 9989 セクション1、"A DMARC result of 'pass' requires not only an SPF or DKIM pass verdict ... but also ... that the domain associated with the SPF or DKIM pass be 'aligned' with the Author Domain"）、エンベロープの送信元をFromと同じドメインに揃えるだけで攻撃者はこの整合も満たせます。結果として、p=rejectを設定していてもDMARCの認証を通過してしまいます。

これをSPFが未設定の状態と比べると危険さの向きが逆になります。SPFレコードが無い場合、判定結果はnoneです。noneはpassではないため、DMARCのSPF側はfailとなり、p=rejectはそのまま機能します。+allは、何も設定しない状態よりも保護が弱い設定です。RFC 7208 セクション8.3も、pass判定について「そのドメインは、送信の責任を負ったものとしてレピュテーションの対象になる（in the sense of reputation, be considered responsible for sending the message）」と述べており、+allはこの責任をあらゆる送信元に無条件で与えていることになります。

修飾子を省略したallも+allと同じ意味です。RFC 7208 セクション4.6.2が修飾子の省略時の既定を+と定めているためです。本サイトの診断は、この状態をspf.all-passとして報告します。

?allと「allを書いていない」は、同じ結果になります

allを書かずにレコードを終えた場合、どの機構にも一致しなかった送信元の判定結果は、暗黙のneutralになります。RFC 7208 セクション4.7は、これを「?allを最後に指定したのと同じ（just as if "?all" were specified as the last directive）」と定めています。

neutralの扱いは、noneと同じです。セクション8.2が「neutralの結果は、noneの結果と全く同じに扱わなければならない（A "neutral" result MUST be treated exactly like the "none" result）」とMUSTで定めているためです。つまり?allを明示的に書いてもallを省略しても受信側から見た扱いは変わりません。レコードは存在するのにSPFを設定していないのと同じ結果になります。

ただしredirectを使っている場合は別です

前の節の「暗黙のneutral」には、条件があります。RFC 7208 セクション4.7が定めているのは「どの機構にも一致せず、かつredirect修飾子が無い場合（If none of the mechanisms match and there is no "redirect" modifier）」です。redirectがあるときは、セクション6.1に従って参照先の判定結果がそのまま返ります。

同セクション6.1は、redirectだけを使う構成を正当な用法として例示しています。

la.example.com. TXT "v=spf1 redirect=_spf.example.com"
ny.example.com. TXT "v=spf1 redirect=_spf.example.com"
sf.example.com. TXT "v=spf1 redirect=_spf.example.com"
_spf.example.com. TXT "v=spf1 mx:example.com -all"

la.example.com・ny.example.com・sf.example.comは、いずれもallを持たないレコードですが、参照先の_spf.example.comが-allを持っているため、この3つのドメインもfail判定を返します。複数のドメインを一括で管理する、正当な構成です。

本サイトの診断は、2026-08-19までこの構成に誤って「all の指定がありません」を修正が必要な項目として出していました。この記事の執筆前に実装を確認していて見つけ、記事より先に実装を直しました。

ただし、redirectがあることは「安全である」という意味でもありません。セクション6.1が定めているのは委譲先の判定結果がそのまま返るということなので、委譲先が+allや?allを持っていれば、委譲元のドメインもその判定を受け取ります。同セクションは「委譲先のドメインがさらにredirectを指定していてもよい（Note that the newly queried domain can itself specify redirect processing）」とも書いています。

そのため本サイトの診断は、2026-08-20からredirectの連鎖を最後までたどり、たどり着いた先のallで判定するようにしました。委譲先が+allなら「+all が指定されています」、?allなら「?all (中立) が指定されています」と表示し、どのドメインのレコードを直せばよいかも添えます。委譲先を引けなかった場合は、判定を保留して何も出しません。引けなかったことは、設定が誤っている証明にならないためです。

実測では、redirectで委譲していた58件のうち8件が委譲先で?allになっていました。この8件は、2026-08-20より前は何の指摘も出ていませんでした。

なお、allとredirectを同じレコードに両方書いた場合は、redirectのほうが無視されます（セクション5.1）。この点はallより後ろに書いた機構は、無視されますで改めて扱います。

~allと-allで変わるのは受信側の扱いだけです

~allはsoftfail、-allはfailと呼ばれます。英語のsoft fail・hard failに由来する呼び方で、日本語の解説でもそのまま使われることがあります。

評価は左から右へ順に行われ、最初に一致した機構の時点で判定が確定します（RFC 7208 セクション4.6.2）。allが効くのはそれより前のどの機構にも一致しなかった送信元だけです。

• fail（-all）の処分は、受信側のローカルポリシーです。SMTPの途中で拒否する場合は、550応答と5.7.1のステータスコードを使うことがSHOULDとされています（セクション8.4）
• softfail（~all）は、この結果だけを理由に拒否すべきではない（SHOULD NOT）とされ、より厳しい精査の対象にしてよい（MAY）とされています（セクション8.5）

どちらも受信側の実装とポリシー次第で、仕様はどの結果の扱いにも規範的な要求を置いていません（セクション2.6）。「-allにすれば拒否される」「~allなら届く」と言い切ることはできません。

DMARCとの関係

仕様上、DMARCは~allと-allを区別しません

DMARCがSPFの評価から保持する結果は、pass・failの2値です。RFC 9989 セクション5.3.3が「SPFについて、保持する結果はpassまたはfailを含まなければならない（For SPF, the preserved results MUST include "pass" or "fail"）」と定めており、softfailという中間の区分は登場しません。DMARCの側から見ると~allによるsoftfailも-allによるfailも同じfailとして扱われます。

ただし、届く前に切られるかどうかは変わります

DMARCの評価結果は変わらなくてもその評価にたどり着けるかどうかは変わります。-allのfailを受信側がSMTPの途中で拒否すると（セクション8.4が想定する動作です）、メールはDMARCの評価が行われる前に消えます。DKIMの署名があれば救えたはずの、転送されたメールも同様に落ちます。~allは、セクション8.5のSHOULD NOTがあるぶん、拒否されずにDMARCの評価まで届きやすくなります。

これは「DMARCを設定しているのだから~allと-allのどちらでもよい」という意味ではありません。DMARCが同じ判定を返すとしてもそこまでメールが届くかどうかはallの修飾子で変わります。

Microsoftは-allを推奨しています

Microsoft Learnは、Microsoft 365ドメイン向けにSPFの設定を解説するページで、次のように述べています（2026-07-03更新、2026-08-19確認）。

For Microsoft 365 domains, we recommend -all (hard fail) because we also recommend DKIM and DMARC for the domain.

同じページには、~allと-allの関係について次の注記もあります。

DMARC treats -all (hard fail) and ~all (soft fail) as SPF failures. But the DMARC policy is effectively ignored for SPF ~all failures if the messages don't also contain DKIM signatures. We recommend -all so DMARC can act on messages that fail SPF if the messages also lack DKIM signatures.

「DKIM署名も無い場合は、~allによるSPFの失敗に対してDMARCのポリシーが実質的に無視される」という条件付きの主張です。この後半の記述に対応する規定は、RFC 9989には見当たりません。同RFCがDMARCの側で保持すると定めているSPFの結果はpassかfailの2値で（前述のセクション5.3.3）、softfailとfailを区別する規定を持っていません。このページにはai-usage: ai-assistedという注記もあり、この記述がExchange Onlineの実装の説明なのか記述の誤りなのかは外部から判別できません。

一方、Gmailの送信者向けガイドライン（support.google.com/a/answer/81126、2026-08-19確認）は、SPFの設定を求めていますが、allに付ける修飾子については何も指定していません。

どちらが正しいかをこの記事では断定しません。そのかわり、判断の材料になる規定を示します。RFC 9989 セクション7.4は、p=rejectを公開するドメインに「SPFだけに頼ってはならず、有効なDKIM署名を適用しなければならない（domains that publish "p=reject" MUST NOT rely solely on SPF to secure a DMARC pass and MUST apply valid DKIM signatures to their messages）」と定めています。DKIMを正しく設定していれば、Microsoftが挙げている条件（DKIM署名も無い場合）にそもそも当てはまりません。選ぶべきなのは-allか~allかより先に、DKIMの設定です。

どちらを選ぶか

• このドメインからメールを送っている場合は、~allにしてください。本サイトの診断も~allを提案します。送信元の洗い出しに漏れがあったとき、正規のメールが即座に届かなくなるのを避けるためです
• -allに変更する前に、把握していない送信元が無いかを確認してください。転送設定、グループウェア、問い合わせフォームの自動返信、請求システム、採用管理システムなど、自分でメールソフトを操作していない送信元も対象です
• このドメインから一切メールを送らない場合は、v=spf1 -allを設定します
• 送信に加えて、このドメインでメールを受け取ってもいない場合は、MXレコードも合わせて閉じられます。Null MXとは？メールを受信しないドメインの設定値となりすまし対策を確認してください
• 問い合わせフォームの返信先など、受信だけは続ける場合は、MXレコードをそのまま残してください。Null MXを設定するとこのドメイン宛のメールがすべて配送できなくなります

v=spf1 -allとv=spf1 include:... -allは、意味が違います

-allが付いていることと「このドメインからメールを送らない」という宣言は、同じではありません。本サイトの診断は、all以外に送信を許可する機構が1つも無いレコードだけを送信しない宣言として扱います。

v=spf1 -allは、送信を許可する機構が無いため、送信しない宣言にあたります。一方v=spf1 include:{送信サービスのドメイン} -allは、includeで指定した送信元にはメールの送信を許可しているため、-allが付いていても送信しない宣言にはあたりません。修飾子の-allだけを見て判断するとこの2つを取り違えます。

この判定は、DMARCの生成値にも影響します。本サイトの診断は、送信しない宣言と判定したドメインに対してのみ、DMARCを最初からp=rejectで生成します。送信しているドメインには、p=noneから段階的に強化する手順を案内します。

allより後ろに書いた機構は、無視されます

allは、レコードの中で最も右に置き、それより前のどの機構にも一致しなかった送信元への既定値を与える機構です（RFC 7208 セクション5.1）。

機構とredirect修飾子とでは、無視される条件が違います。

• 機構は、allより後ろに書かれたものが無視されます（セクション5.1、"Mechanisms listed after 'all' MUST be ignored"）。v=spf1 -all include:_spf.example.comのようにincludeをallの後ろに置くとそのincludeは評価されません
• redirect修飾子は、書く位置に関係なく、レコードのどこかにallがあれば無視されます（同セクション5.1、"Any 'redirect' modifier MUST be ignored when there is an 'all' mechanism in the record, regardless of the relative ordering of the terms"）。allより前に書いても無視される点が機構とは異なります

レコードを見直すときは、この2つを分けて確認してください。

直し方

現在のレコードの値は、そのまま残してください。末尾のallに付いている修飾子だけを~allまたは-allに変更します。

v=spf1 {既存の項をそのまま} ~all

これは書式を示すための例で、そのままコピーする値ではありません。既存のレコードに何が書かれているかによって、{既存の項をそのまま}の部分は変わります。本サイトのメール認証の診断にドメインを入力すると現在のレコードをもとに末尾だけを変更した値が生成されるので、そちらを使ってください。診断が値を生成できない場合は、レコードの構文自体に別の問題があります。SPFのDNS参照回数が10回を超える原因と直し方や独自ドメインのメールが届かない原因は？もあわせて確認してください。

DMARCを設定している場合、allの修飾子を変更してもDMARCを設定していないリスクと最初に置く設定で説明している段階的な強化の手順自体は変わりません。

設定を変更したら、メール認証の診断で再診断してください。反映直後は、再帰リゾルバに古い値が残っていることがあります。