SPFは-allにすべき理由 ― ~allとの違いとDMARC運用での注意点

~allと-allの意味の違いと、DMARC運用で-allを使うための前提 ― RFC 7208・RFC 9989の規定から

2026年10月29日作成
著者: 竹洞 陽一郎

結論 ― SPFレコードの末尾は-allにしてください

メールを送信するドメインも、送信しないドメインも、SPFレコードの末尾は-allにすべきです。
-allは「SPFレコードに書いた送信元以外は認可していない」という明示的な表明で、受信側が否定的な判定を確定的にできるのは-allの場合だけです。
（RFC 7208 Section 2.1）
ただし、-allに切り替える前に、DMARCの集計レポートで、自ドメインをMAIL FROM（エンベロープ送信者）に使っている正規の送信元をすべて洗い出し、SPFレコードに登録してください。
この状態であれば、正規のメールはSPFでpassするため、-allによってDMARCの評価前に拒否される対象になりません。
~allにしておくメリットは、送信元の洗い出しが終わるまでの移行期間に限られ、実質的にはほとんどありません。
MAIL FROMを書き換えずに転送されるメールの扱いは、5. ~allと-allの使い分けで説明します。

SPFレコードの末尾を~allにするか-allにするかは、SPFの設定で迷いやすい点です。
-allには、DMARCと組み合わせたときに注意すべき点があります。
この記事では、SPFの仕様であるRFC 7208と、2026年5月に発行されたDMARCの仕様であるRFC 9989に基づいて、両者の違いと、-allを使うための前提を解説します。

早見表 ― allに付ける4つの記号と評価結果

SPFレコードの末尾のallに付ける記号（限定子）と、その評価結果は次のとおりです。
このうち、実際に使い分けが問題になるのは~allと-allです。

「使いどころ」の列は、後述するMailDataの推奨に基づく整理です。

1. SPFレコードの「all」と限定子の仕組み

要点: SPFレコードは左から順に評価され、最初に一致した機構の限定子が評価結果になります。allはすべての送信元に一致するため、末尾のallの限定子が、レコードに書かれていない送信元の評価結果を決めます。

SPFレコードは、ドメインのメールを送信してよいサーバーのIPアドレスなどを、DNSのTXTレコードとして公開するものです。
次は、SPFレコードの例です。

example.jp.  IN  TXT  "v=spf1 ip4:192.0.2.0/24 include:_spf.example.net ~all"

受信側は、エンベロープ送信者（MAIL FROM）のドメインのSPFレコードを取得し、接続してきたサーバーのIPアドレスを、レコード内の機構（ip4、includeなど）と左から順に照合します。
最初に一致した機構で評価が終わり、その機構に付けられた限定子（qualifier）が評価結果になります。
（RFC 7208 Section 4.6.2）

限定子は次の4種類で、省略すると「+」として扱われます。

+

pass

-

fail

~

softfail

?

neutral

allは、どの送信元にも必ず一致する機構で、レコードの右端に置いて既定の結果を明示するために使います。
（RFC 7208 Section 5.1）
そのため、ip4やincludeのどれにも一致しなかった送信元は、末尾のallに一致し、allに付けた限定子の結果になります。
上の例では、192.0.2.0/24と_spf.example.netで認可された送信元以外は、softfailになります。

レコードにallもredirect修飾子もない場合は、末尾に?allがあるものとして扱われ、結果はneutralになります。
（RFC 7208 Section 4.7）

2. RFC 7208での~allと-allの違い

要点: failは「認可されていない」という明示的な表明、softfailは弱い表明です。softfailだけを理由に拒否すべきではありません（SHOULD NOT）。failの扱いは受信側のローカルポリシーに委ねられており、SMTPの段階で拒否することも想定されています。

評価結果の定義

RFC 7208は、failとsoftfailを次のように定義しています。

fail（Section 2.6.4）

「fail」という結果は、そのクライアントが、指定された識別子でそのドメインを使うことを認可されていないという明示的な表明です。

softfail（Section 2.6.5）

「softfail」という結果は、SPFレコードを公開している管理ドメイン（ADMD）による、そのホストはおそらく認可されていないという弱い表明です。
この管理ドメインは、「fail」となるような、より強く明確なポリシーを公開していません。

なお、Section 2.6は、プロトコルとしては特定の評価結果の扱いについて規範的な要件を定めていないとしたうえで、扱いの選択肢をSection 8で説明しています。

受信側での扱い

softfailの扱いについて、RFC 7208 Section 8.5は次のように記述しています。

「softfail」という結果は、「fail」と「neutral」または「none」の中間のものとして扱われます。
管理ドメインは、そのホストが認可されていないと考えていますが、強いポリシーの表明をするつもりはありません。
受信側のソフトウェアは、この結果だけを理由にメッセージを拒否すべきではありません（SHOULD NOT）が、通常より厳しく精査してもかまいません（MAY）。

一方、failについてRFC 7208 Section 8.4は、failとなったメッセージの扱いはローカルポリシーの問題であるとしています。
SMTPのトランザクション中に拒否する場合は、SMTPの応答コード550と、サポートしていれば拡張ステータスコード5.7.1を使うべきです（SHOULD）。
拒否しない場合は、Received-SPFまたはAuthentication-Resultsのヘッダーフィールドを付加して、後段の処理に結果を伝えるべきです（SHOULD）。

さらに、RFC 7208 Appendix G.2は、failをSMTPのトランザクション中の拒否に使えることを示したうえで、MAIL FROMの結果に基づく拒否には、正規のメールを拒否するリスクがあるとしています。
代わりに、failを他の評価と組み合わせて判定する際の入力の1つとして使う方法も示されています。

また、RFC 7208 Section 2.1は、受信側が「認可されていない」という否定的な判定をできるようにするには、-allで終わるレコード（またはそうしたレコードへのredirect）を公開する必要があり、そうでなければ認可について確定的な判定はできないとしています。
SPFだけを見れば、-allは送信ドメインの意思を最も明確に伝える記述です。
ただし、DMARCと組み合わせる場合は、次の章で説明する点を考慮する必要があります。

3. DMARCと組み合わせたときの違い

要点: DMARCの判定では、softfailとfailに差はありません。差が出るのは、受信側がSPFのfailをDMARCより前の段階で拒否に使った場合で、DKIMでDMARCに合格するはずのメールが拒否され、その受信側に送られたメールは集計レポートにも現れません。

DMARCの判定ではsoftfailとfailは同じ

RFC 9989 Section 4.4.2は、MAIL FROMのドメインの使用がSPFで検証された場合に、そのドメインがSPFの認証済み識別子（SPF-Authenticated Identifier）になるとしています。
softfailもfailもpassではないため、どちらの場合もSPFの認証済み識別子は得られません。
つまり、DMARCの判定に限れば、~allと-allで結果は変わりません。
DMARCに合格するかどうかは、SPFとDKIMのアライメントで決まります。
アライメントの判定については、DMARCアライメントとは？SPF・DKIMの一致判定とメールが届かない原因【2026年版】で解説しています。

-allがDMARCより前の拒否を引き起こす場合

差が出るのは、受信側がDMARCを評価する前に、SPFの結果だけでメールを拒否する場合です。
RFC 9989 Section 7.1は、この点を次のように説明しています。

SPFは、SMTPのトランザクションの早い段階で実装されることを意図していました。
そのため、メッセージの内容が送信される前にSPFの検証に失敗することがあり、受信側の構成によっては、DMARCの処理より前にSPFを実装している場合があります。
つまり、「-all」のように、送信者のSPFの機構にハードフェイル（「-」）の接頭辞が付いていると、メッセージがSPFの認証チェックに失敗した場合、DMARCの処理が行われる前に、SMTPのトランザクションの早い段階でメッセージが拒否される可能性があります。
SPFレコードの末尾に「-all」を使うことを選ぶドメイン所有者は、このことを認識し、DKIMの認証済み識別子のアライメントによってDMARCに合格するはずのメッセージが、SPFのfailだけを理由に拒否され得ることを理解しておくべきです。
さらに、SMTPのトランザクションの早い段階で拒否されたメッセージは、DMARCの集計レポートに決して現れません。
トランザクションがDATAの段階に進まないため、RFC5322.Fromのドメインが明らかにならず、そのDMARCポリシーも参照されないからです。

引用中の「認識し」「理解しておくべきです」は、原文では小文字のshouldです。
RFC 8174により、小文字で書かれたshouldは規範用語ではなく、通常の英語の意味で読みます。

典型的なのは、MAIL FROMを書き換えずに転送されたメールです。
転送サーバーから送られたメールは、MAIL FROMのドメインのSPFレコードに転送サーバーのIPアドレスが含まれていないため、SPFはpassしません。
DKIMの署名が転送で壊れていなければ、DKIMのアライメントでDMARCには合格します。
しかし、SPFレコードが-allで、受信側がSPFのfailをSMTPの段階で拒否に使っていれば、このメールはDMARCが評価される前に拒否されます。
ただし、これは仕様上起こり得ることです。
MailDataが支援しているドメインの運用では、-allを理由に転送メールが早期拒否された事例は確認されていません。
（2026年10月時点）
この観測は、観測の範囲外の受信側で早期拒否が起きないことを示すものではありません。

受信側がDATAの段階まで受け取ってDMARCを評価する場合は、-allでSPFがfailになったメールも、集計レポートにSPFの結果「fail」として記録されます。
集計レポートに現れないのは、SPFのfailだけを理由にSMTPの段階で拒否する受信側に送られたメールです。
DMARCの運用では、集計レポートで正規の送信元を洗い出し、SPFやDKIMの設定漏れを見つけます。
このような受信側に送られたメールについては、設定漏れがあっても集計レポートでは気付けません。

M3AAWGの受信側への推奨

メッセージング分野の業界団体M3AAWGの「M3AAWG Email Authentication Recommended Best Practices」（2020年9月）は、受信側に対して、DMARCのpassはSPFのfailの判定より優先されるべきであり、SPFのfailによる拒否は、DMARCを評価して合格しないと分かるまで行うべきではないとしています。
例外は、SPFレコードがv=spf1 -all（どの送信元も認可しない）の場合で、このときは受信側がSPFのfailに基づいて先に対処してもよいとしています。
（同文書 Section 4、Section 5.3）

M3AAWGの文書はRFCではなく、業界団体のベストプラクティスです。
RFC 9989 Section 7.1は、SPFレコードの公開と、SPFのfailだけを理由にした拒否については、この文書と「M3AAWG Best Practices for Managing SPF Records」を参照できるとしています。

4. 受信側の実装による扱いの違い

要点: failやsoftfailをどう扱うかは受信側のローカルポリシーで、実装と設定によって異なります。仕様上の規定と、個々の受信サービスの挙動は分けて考える必要があります。

RFC 7208は、failの扱いを受信側のローカルポリシーに委ねています。
（RFC 7208 Section 8.4）
そのため、-allによるfailを、SMTPの段階で拒否するか、受け取って迷惑メールとして扱うか、DMARCの評価まで判断を保留するかは、受信側の実装と設定によって異なります。

M3AAWGの「M3AAWG Best Practices for Managing SPF Records」（2017年8月）は、多くの受信側は~allと-allを同様に扱うものの、-allの場合に認証されていないメールを拒否しやすい受信側もある、としています。
（同文書 Section 3）
これは2017年時点の業界団体の見解で、特定の受信サービスの現在の挙動を示すものではありません。
特定の受信サービスがSPFのfailやsoftfailをどう扱うかは、そのサービスの公式ドキュメントで確認してください。

5. ~allと-allの使い分け

要点: MailDataは、自ドメインをMAIL FROMに使う正規の送信元をすべてSPFレコードに登録したうえで-allにすることを推奨しています。-allによる早期拒否のリスクは、送信元の洗い出しとSPFへの登録を終えてから切り替えることで抑えます。SPFとDKIMのアライメントは、-allとは別に、DMARCのために必要な設定です。

~allと-allのメリットとデメリット

~allと-allのメリットとデメリットを、観点ごとに比較します。
-allのデメリットは、いずれもSPFのfailだけを理由にSMTPの段階で拒否する受信側で起きるものです。

~allのメリット

~allにしておくメリットは、あまりありません。
メリットはすべて、SPFのfailだけを理由にSMTPの段階で拒否する受信側で、早期拒否を避けられることから来ています。
DMARCを評価する受信側では、~allと-allでDMARCの判定は変わりません。

転送されたメールが早期拒否されない

MAIL FROMを書き換えずに転送され、DKIMはアラインしているメールが、早期拒否されずにDMARCの評価まで進みます。
ただし、MailDataが支援しているドメインの運用では、-allを理由に転送メールが早期拒否された事例は確認されていません。
（2026年10月時点）
この観測は、観測の範囲外の受信側で早期拒否が起きないことを示すものではありません。
そのため、これは仕様上のメリットにとどまります。

登録漏れの送信元が、DMARCの評価まで進む

SPFへの登録漏れがある送信元からのメールも、早期拒否されずにDMARCの評価まで進み、集計レポートに記録されます。
ただし、DATAまで受け取ってDMARCを評価する受信側では、-allでもfailとして集計レポートに記録されます。
差が出るのは、早期拒否する受信側の分だけです。
また、MailDataの観測（2026年10月時点）では、SPFのアライメントが一致しないと届かないケースがあり、~allで登録漏れのメールが届くとは限りません。

SPFだけで判定する受信側では、~allだとなりすましメールも拒否されにくくなります。
これは、~allのデメリットです。
~allに意味があるのは、送信元の洗い出しとSPFへの登録が終わっていない移行期間に、早期拒否する受信側への保険として使う場合だけだと考えます。
登録が終わったら、~allにしておく実質的なメリットはほとんどないため、-allに切り替えます。
なお、M3AAWGが~allを推奨している理由も、DMARCの評価より前にSPFのfailで拒否されることを避けるという点です。
（M3AAWG Email Authentication Recommended Best Practices Section 5.3）

ドメインの状況別の選び方

MailDataが-allを推奨する理由

-allは、SPFレコードを公開するドメインが「ここに書いた送信元以外は認可していない」と明示的に表明する記述です。
受信側が否定的な判定を確定的にできるのは、-allの場合だけです。
（RFC 7208 Section 2.1）

-allで問題になるのは、SPFがpassしない正規のメールが、DMARCの評価より前に拒否されることです。
自ドメインをMAIL FROMに使う正規の送信元をすべてSPFに登録し、SPFでpassする状態にしておけば、正規のメールは早期拒否の対象になりません。
なお、第三者のサービスが、サービス側のドメインをMAIL FROMに使って送信するメールは、そのドメインのSPFレコードで評価されるため、自ドメインの-allは関係しません。
早期拒否の対象になるのは、SPFで認可していない送信元からのメールだけです。

また、MailDataの観測（2026年10月時点）では、添付ファイル付きのB2B宛てのメールとB2C宛てのメールは、DKIMがアラインしていても、SPFのアライメントが一致しなければ届きませんでした。
これは、DMARCの判定がpassでも、受信側の判断で届かないことがあるという観測で、仕様上の規定ではありません。
B2B宛ての受信側は、Google WorkspaceとMicrosoft 365です。
この観測の範囲では、~allにしても、SPFが通らない正規のメールが届くようにはなりません。
正規のメールを届けるには、~allか-allかにかかわらず、SPFをpassさせてアラインさせる必要があります。
観測の詳細は、DMARCアライメントとは？SPF・DKIMの一致判定とメールが届かない原因【2026年版】で解説しています。

なお、RFC 9989 Section 7.1は、MAIL FROMを書き換えずに転送されるメールが、-allの場合に早期拒否され得ることを指摘しています。
ただし、MailDataが支援しているドメインの運用では、-allを理由に転送メールが早期拒否された事例は確認されていません。
（2026年10月時点）
この観測は、観測の範囲外の受信側で早期拒否が起きないことを示すものではありません。
また、M3AAWGの2020年のベストプラクティスは、メールを送信するドメインのSPFレコードを~allで終えることを推奨しており、MailDataの推奨とは異なります。

転送メールの早期拒否を避ける方法として、転送サーバー側でSRS（Sender Rewriting Scheme）を使う方法があります。
SRSは、転送時にMAIL FROMを転送サーバー側のドメインに書き換えるため、SPFは転送サーバー側のドメインのSPFレコードで評価され、自ドメインの-allは関係しなくなります。
SRSはRFCとして標準化された仕様ではなく、転送サーバーが対応しているかどうかは実装によります。
一方、ARC（RFC 8617、Experimental）は、転送前の認証結果をメッセージのヘッダーに記録する仕組みです。
ヘッダーはDATAの段階まで受け取らないと読めないため、MAIL FROMの段階での早期拒否を避ける手段にはなりません。

RFC 9989 Section 8は、DMARCに完全に参加するドメイン所有者に対して、SPFとDKIMの両方でアライメントを満たすメールを送ること（MUST）と、ポリシーがp=rejectの場合にDMARCのpassをSPFだけに頼らないこと（MUST NOT rely solely on SPF）を求めています。
SPFとDKIMの両方のアラインは、-allとは別に、DMARCに完全に参加するために必要な設定です。
両方のアライメントが必要な理由は、GmailやOutlook.comが推奨するSPFとDKIM双方のDMARCアライメントで解説しています。

-allはDMARCの代わりにはならない

受信側がDMARCを評価する場合、なりすましメールは、通常、SPFとDKIMのどちらのアライメントも満たさないため、~allでも-allでもDMARCで不合格になり、ドメイン所有者が公開したポリシー（p=rejectなど）に基づいて扱われます。
-allは、DMARCのポリシーをp=rejectまで進めることと組み合わせて使う設定です。
p=rejectへの進め方は、DMARCでp=rejectにするためのプロセスで解説しています。

6. よくある誤解

「-allだと、SPFへの登録漏れがあった場合に、メールが届かなくなる」

SPFへの登録漏れがある送信元からのメールは、~allでもSPFがpassしないため、SPFのアライメントは満たされません。
DKIMもアラインしていなければ、~allでも-allでもDMARCで不合格になり、公開したポリシーに基づいて扱われます。
DKIMがアラインしていればDMARCには合格しますが、MailDataの観測（2026年10月時点）では、添付ファイル付きのB2B宛てとB2C宛てのメールは、SPFのアライメントが一致しなければ届きませんでした。
つまり、登録漏れがあれば、~allでも届かないメールが出ます。
~allと-allで差が出るのは、SPFのfailだけを理由にSMTPの段階で拒否する受信側に送られたメールです。
登録漏れへの対策は、~allのままにしておくことではなく、集計レポートで送信元を洗い出し、SPFに登録することです。
洗い出しが終わるまでは、~allを一時的に使います（5. ~allと-allの使い分け）。

「-allにすれば、DMARCは不要」

DMARCを評価する受信側では、DMARCの判定でsoftfailとfailに差はありません。
なりすましメールの扱いを決めるのはDMARCのポリシーで、-allはその代わりにはなりません。

「~allでは、なりすましメールが届いてしまう」

DMARCを運用していれば、なりすましメールは、通常、DMARCで不合格になり、公開したポリシーに基づいて扱われます。
なりすましメールの扱いを決めるのは、~allか-allかではなく、DMARCのポリシーです。

「-allにすると、転送されたメールは必ず届かない」

SPFのfailをSMTPの段階で拒否するかどうかは、受信側のローカルポリシーです。
（RFC 7208 Section 8.4）
すべての受信側が早期拒否するわけではありませんが、早期拒否する受信側では、MAIL FROMを書き換えずに転送されたメールが拒否されることがあります。
ただし、MailDataが支援しているドメインの運用では、-allを理由に転送メールが早期拒否された事例は確認されていません。
（2026年10月時点）
この観測は、観測の範囲外の受信側で早期拒否が起きないことを示すものではありません。

「include先のSPFレコードが-allなら、自社のレコードも-allと同じ扱いになる」

includeは、参照先のレコードの評価結果がpassの場合だけ一致する機構です。
参照先が-allでfailになっても、include自体は「不一致」になって評価が続き、全体の結果は自社のレコードの末尾のallで決まります。
（RFC 7208 Section 5.2）

「allを書かなければ、認可していない送信元は拒否される」

allもredirect修飾子もない場合は、末尾に?allがあるものとして扱われ、結果はneutralです。
（RFC 7208 Section 4.7）
認可していない送信元をsoftfailやfailにするには、allを明示します。

7. まとめ ― 確認チェックリスト

• allの位置: メールを送信するドメインのSPFレコードが、~allまたは-allで終わっていて、allがレコードの途中にないか？
• アライメント: メールを送信するドメインで、すべての送信元のSPFとDKIMの両方のアライメントが一致しているか？
• DMARCのポリシー: DMARCのポリシーをp=rejectまで進めているか、進める計画があるか？
• -allへの切り替え: 集計レポートで、自ドメインをMAIL FROMに使う正規の送信元がすべてSPFでpassしていることを確認してから、-allに切り替えているか？
• 送信しないドメイン: メールを送信しないドメインに、v=spf1 -allとDMARCのポリシーを設定しているか？
• DNSの参照回数: SPFの評価で、DNSの参照を伴う機構と修飾子の合計が10回の上限を超えていないか？

メールを送信しないドメインの設定は、メールを送信しないドメインの防御設定で解説しています。
DNSの参照回数の上限（RFC 7208 Section 4.6.4）については、SPFマクロを実装した際のVoid Lookupに関する注意もあわせてご覧ください。
SPFレコードの設定状況は、無料のドメインメールセキュリティチェッカーで確認できます。

参考資料

• RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1（2014年4月。RFC 7372、RFC 8553、RFC 8616で更新）
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)（2026年5月。RFC 7489とRFC 9091を廃止）
• M3AAWG Email Authentication Recommended Best Practices（2020年9月）
• M3AAWG Best Practices for Managing SPF Records（2017年8月）