SPFニュートラルメカニズム（?all）の解説 使用するタイミングと方法
著者: Yunes Tarada
翻訳: 古川 綾乃
この記事はPowerDMARCのブログ記事 SPF Neutral Mechanism (?all) Explained: When and How to Use Itの翻訳です。
Spelldataは、PowerDMARCの日本代理店です。
この記事は、PowerDMARCの許可を得て、翻訳しています。
SPFのニュートラルメカニズム「?all」は、Sender Policy Framework（SPF）レコードの仕組みの一つで、評価結果としてニュートラル（中立）を返します。
これは、受信側サーバに対して、SPFに基づく pass や fail などの明確な判定を行わないことを示します。
- ?all を含むSPFレコードの例
v=spf1 include:_spf.google.com ?all
この例では、ドメインは Google のSPF設定を含んでいますが、末尾に「?all」を付けています。
これにより、Google以外の送信者については中立として扱うよう受信側サーバに示します。
つまり、送信元を許可も拒否もせず、明確な判断を行わないことを意味します。
「?all」は評価を曖昧にし、DMARCポリシーの適用を妨げる可能性があり、不適切に使用すると配信上の問題を引き起こすことがあります。
主なポイント
- SPFのニュートラルメカニズムは、メールが正当かどうかを明確に示しません。
- ?all メカニズムは、テスト環境やレガシー構成など、一部の用途では現在でも有効な場合があります。
- しかし、本番環境で使用すると、メールサーバ側で評価が曖昧になる可能性があります。
- 本番環境でSPFのニュートラルメカニズムを使用することは推奨されません。
なりすましを助長し、メール認証や配信の失敗につながる可能性があるためです。 - ドメインのメールセキュリティを強化するには、「?all」メカニズムを softfail（~all）に置き換えることが推奨されます。
SPFニュートラルメカニズム（?all）と他のメカニズムの比較
「ドメイン所有者は、そのIPアドレスが認可されているかどうかを明確に断言できない、または断言したくないことを示します。
“Neutral” の結果は “None” の結果と同等に扱われる必要があります。
この区別は情報提供の目的のためだけに設けられています。
“Neutral” を “None” より厳しく扱うと、ドメイン所有者による SPF レコードのテスト利用を妨げてしまいます。」– RFC 4408
「?all」メカニズムは、他のSPF修飾子とは異なり、pass や fail といった結果を返しません。
そのため、DMARCの評価やメールサーバ側の判断に影響を与えることがあります。
「?all」メカニズムは、受信側のメールサーバにとって判断を難しくし、メールの信頼性を評価しにくくする可能性があります。
以下の表は、各メカニズムの効果と使用例を簡潔にまとめたものです。
| メカニズム | 効果 | 使用例 |
|---|---|---|
| ?all（ニュートラルメカニズム） | ニュートラル — pass や fail といった判定を行わない | 通常はほとんど使用されず、推奨もされていません。 移行期間中の設定として使用されることがあります。 |
| ~all（推奨される方法） | ソフトfail — 疑わしいメールとして扱われる | SPFの導入時に使用されます。 未承認の送信者にフラグを付けますが、メール自体はブロックしません。 そのため、DMARC がポリシーを適用でき、誤検知のリスクも抑えられます。 |
| -all | ハードfail — メールサーバによって拒否される可能性がある | 厳格な適用と強固なセキュリティのために使用されます。 |
SPFニュートラルメカニズムを使用するタイミング
SPFニュートラルメカニズムは、ほとんどの最新のメール構成では推奨されません。
ただし、注意を払い、事前により安全なメカニズムへ移行する計画を立てた上で、特定のケースでは使用されることがあります。
- レガシーシステム
- 一部の古いインフラストラクチャやシステムでは、明確な送信ポリシーや適切なSPF処理が整備されていない場合があります。
このような場合、機能を維持するために、SPFニュートラルメカニズムのような中立的な立場が必要になることがあります。 - テスト段階
- このメカニズムは、SPFの初期導入時にも使用できます。
これにより、ドメイン所有者は配信を維持したままメールトラフィックを監視できるため、開始段階で安全に利用できます。 - まれなケース
- 場合によっては、~allや-allなどの他のメカニズムが予期しない配信上の問題を引き起こすことがあります。
これらの問題を診断するために、一時的に?allメカニズムを使用することができます。
SPFメカニズムは上から順に評価されるため、?allを他のメカニズムより前に配置すると、SPF評価が早期に終了し、本来行われるべきチェックが実施されない可能性があります。
?allを使用するリスク
?all メカニズムは明確な認証結果を返さないため、メールセキュリティ（例：なりすまし対策）とメール配信の両方に悪影響を及ぼす可能性があります。
考えられるリスクには次のものがあります。
- メールのなりすまし
- ?all はニュートラルな結果を返すため、なりすましに対する防御効果はありません。
一方、~all や -all は明確な fail シグナルを返します。
これらのシグナルは、DMARCポリシー（quarantine や reject など）と組み合わせることで、受信側のサーバが未承認のメールを隔離または拒否できるようにします。 - DMARCの競合
- ?all によるニュートラルな SPF 結果は、ドメインが一致していれば技術的には DMARC と整合する場合があります。
しかし、DMARC が強制措置を取るために必要な pass または fail のシグナルを提供しません。 - 配信上の問題
- 一部のメールサーバは、SPF における ?all メカニズム（ニュートラル）を、弱い、または不明確なポリシーとして解釈します。
これは送信者識別の強制力が弱いことを示す可能性があり、信頼性の低下につながることがあります。
Gmail などのメールプロバイダは複数の評価要素を使用しており、弱い SPF ポリシーはその一要素に過ぎません。
?allを~allまたは-allに置き換える方法
ドメインのメールセキュリティを強化するためには、?allメカニズムをより明確なメカニズムに置き換える必要があります。
以下は、そのプロセスで従うべき主な手順です。
1. 現在のSPFレコードを監査する
PowerDMARCのSPFチェッカーを使用して、現在の設定を監査してください。
レコードが存在しない場合は、無料のSPFジェネレーターを使用して、送信元に合わせたレコードを作成できます。
2. ?allを~allに置き換える
ソフトfail（~all）メカニズムは、現実的で実用的な方法です。
SPFチェックが失敗した場合、~allは「fail」をトリガーするため、DMARCのp=rejectでもメールを拒否できます。
3. DMARCレポートを監視する
DMARC集計レポートを使用して、メールのアクティビティを定期的に追跡することも重要です。
PowerDMARCのDMARCレポートアナライザーは、使いやすいリアルタイムのDMARCレポートを提供し、状況の把握と安全性の維持に役立ちます。
SPFニュートラルメカニズムの一般的な設定ミス
?all メカニズムを誤って使用すると、意図しないセキュリティ上の弱点や配信トラブルが発生する可能性があります。
以下は、避けるべきよくあるミスです。
- ミス1：本番環境で ?all を使用する
- ニュートラルポリシーでは十分な保護が得られません。
そのため、なりすましメールが正当なもののように見えてしまいます。
その結果、送信元ドメインの評判と受信者の安全の両方に悪影響を及ぼす可能性があります。 - ミス2：厳格な DMARC ポリシーと ?all を組み合わせる
- p=reject のような DMARC ポリシーは、SPF（または DKIM）が明確な pass または fail を提供することに依存します。
ニュートラルな SPF では、DMARC が適切に処理できず、不要なDMARC失敗が発生する可能性があります。 - ミス3：?all を ~all と同等だと考える
- ~all は少なくとも未承認の送信者にフラグを付けます。
一方、?all メカニズムは一切判定を行いません。
多くの人がこの2つを混同し、その結果、メール認証や配信に問題が発生します。
よくある質問
- ?all は SPF レコードがない場合と同じですか？
- いいえ。
?all は中立的な立場を示します。
一方、SPF レコードが存在しない場合は、何の指針も示されません。
メールサーバはこれらを異なる形で扱います。 - ?all を DMARC と一緒に使用できますか？
- 技術的には可能ですが、推奨されません。
DMARC はポリシー適用のために、明確な SPF の pass または fail の結果に依存します。
?all を使用すると多くの場合ニュートラルな結果となり、DMARC の有効性が低下します。
まとめ
SPF レコードにおける ?all メカニズムは一見無害に見えるかもしれませんが、リスクを伴う可能性があります。
実運用では推奨されず、ドメインがなりすましの対象となったり、DMARCポリシーの効果を弱めたりする可能性があります。
現在 ?all を使用している場合は、より高いセキュリティと信頼性のあるメール認証を実現するため、~all（ソフトfail）への移行を計画してください。
長期的に信頼性の高い SPF 運用を実現するには、PowerDMARCのPowerSPF ソリューションを利用し、管理を簡素化するとともに DNS ルックアップ制限を回避することをおすすめします。
このソリューションは複雑なレコードにも対応し、自動的に最適化を行うことで、エラーのないドメイン認証を実現できるよう設計されています。