Defaults.Exposed

Defaults.Exposed › レポート

SPF ~all と -all：ソフトフェイルかハードフェイルか — 139 百万件のレコードが選んだもの（2026年）

公開日 2026-07-03

数値は 2026-06-29 時点 · 手法 v7。 261 百万件の採点済みドメインにわたる集計センサスデータです。すべての数値は集計値であり、個別の事業者のレコードを公開することは一切ありません。採点方法はこちらをご覧ください。

すべての SPF レコードは「all」メカニズムで終わります — これは、あなたのリストに載っていないどこからのメールに対する判定です — そしてインターネットは圧倒的にソフトな方を選んでいます。SPF を公開している 139 百万ドメインのうち 55.8% が ~all（ソフトフェイル）で終わり、対して 39.3% が -all（ハードフェイル）で終わっています。 「偽装を拒否する」と「おそらく偽装だが — とにかく配送する」を分けているのは、たった 1 文字です。どちらが自分に適しているかは、ほとんどの所有者が決して設定しない 2 つ目の設定次第で決まります。

~all と -all は受信側に実際に何を伝えるのか？

では ~all は間違いなのか？ 単独である場合に限り — そしてほぼ常に単独です

ソフトフェイルには擁護できる現代的な根拠があります。Google の送信者ガイドライン、そしてそれに沿った大半の到達性の実務は、実効性のある DMARC ポリシー（p=reject）と組み合わせた ~all に収束しています。この組み合わせは、DMARC を評価するあらゆる受信側 — 現在では主要なメールボックスプロバイダーすべてを含みます — で -all と同等に保護し、しかも -all の典型的な犠牲者である正当な転送メールをハードバウンスさせることはありません。この構成では、肩をすくめる態度に実効性が備わります。SPF が下さなかった判定を DMARC が補うのです。

しかし、この組み合わせこそが要点であり、ここにセットアップガイドが伝えられないものをセンサスが加えます。インターネット上の 77,484,057 件のソフトフェイルレコードのうち、その背後に実効性のある DMARC ポリシーを備えているのはわずか 7.1 百万件 — およそ 11 件に 1 件 — です。 残りの 70.4 百万ドメインにとって、~all はまさに文字どおりの意味です。そのレコードは偽装を見分けたうえで、そのまま通してしまうのです。

2024年の義務化でこれは解決したのではないか？

いいえ — そしてこの区別は、大半の報道が示唆するよりも重要です。Google と Yahoo は 2024 年 2 月に一括送信者に対する認証の要求を開始し、Microsoft も 2025 年 5 月に続きました。要件は、合格しアライメントのとれた SPF または DKIM に加えて、最低でも p=none の DMARC レコードです。これらの義務化は 実効性(enforcement) の要求までは踏み込んでいません — ~all、p=none レコード、そしてアライメントのとれた DKIM を備えたドメインは完全に準拠しており、しかも完全に偽装可能なままです。義務化が標準化したのは書類仕事であって、保護ではありません。 その実効性のない中間層 — 準拠済み、公開済み、しかし偽装可能 — こそが、まさにこのセンサスが測定するギャップであり、メールセキュリティにおいて最大の母集団です。

では、あなたのレコードは何で終わるべきか？

  1. メールを送信し、転送が重要な場合（ニュースレター、メーリングリスト、エイリアス）：その背後に DMARC p=reject を備えた ~all — 上で推奨した組み合わせです。
  2. 厳密に管理された構成からメールを送信する場合： -all が機能し、レコード自体にポリシーを明示します。まず送信元をマッピングしてください — マッピングされていないレコードに厳格な末尾を付けると本物のメールが壊れる、あるいはもっと悪いことになります。
  3. そのドメインが一切送信しない場合： 今すぐ -all に加えて p=reject を。守るべき正当なものが存在しないので、壊れるものもありません。

どの末尾を選ぶにせよ、センサスの一行の教訓は変わりません。修飾子(qualifier)は、それを実効化するものと同じ程度にしか意味を持たない。 そのはしごのどこに自分が立っているかは測定可能です。

よくある質問

SPF は ~all と -all のどちらが良いですか？ どちらも普遍的に良いわけではありません。~all に実効性のある DMARC ポリシーを組み合わせるのは、Google のガイドラインが推奨するパターンです — DMARC を評価する受信側で同等の保護を得ながら、転送メールを壊しません。-all は厳密に管理された送信者に適しています。~all 単独 — ソフトフェイルドメインの 11 件に 1 件を除くすべての状態 — は、弱い選択肢です。

SPF ソフトフェイルとは何を意味しますか？ ~all は受信側に対し、リストに載っていないサーバーからのメールはおそらく正当ではないが、それでも（通常は疑いを持って）受け取るべきだと伝えます。DMARC ポリシーがその失敗に対して作用して初めて、本物の保護になります。DMARC のない SPF をご覧ください。

ハードフェイル -all は転送メールを壊しますか？ 壊す可能性があります。転送はあなたのメールを転送側のサーバーから再送信しますが、そのサーバーはあなたの SPF に載っていないため、DKIM や DMARC が判断を下す前にハードフェイルが拒否を招きます。そのリスクこそが、~all + p=reject の組み合わせが存在する理由です。

Google と Microsoft は今 -all を要求していますか？ いいえ。一括送信者への義務化が要求するのは、アライメントのとれた合格認証と、最低でも p=none の DMARC レコードであり — 実効化も、特定の修飾子も求めていません。Google による非準拠の一括メールの拒否は稼働中です。Microsoft は失敗したメールを迷惑メール扱いにしており、完全な拒否へと移行しつつあります。準拠は保護ではありません。

あなたのレコードが何で終わっているか — そしてその背後に何があるかを確認する

2 回のルックアップで両方が、無料で、30 秒でわかります。もしあなたが 70.4 百万件の実効性のない「肩すくめ」の 1 つなら、修正は DNS レコードであって、購入ではありません。

あなたのドメインを確認する → · SPF を修正する → · DMARC を修正する → · SPF 成熟度モデル → · +all マップ → · 集計データのみ。データは EU で保管・処理されます。