SPF -all 対 ~all: 構文、違い、およびメール認証

SPFの「-all」と「~all」の仕組みを理解することは、メール認証において極めて重要です。これらのSPFレコードの末尾がメール配信に与える影響と、ドメインのセキュリティにどちらを選択すべきかを学びましょう。

～すべてそして -all どちらも許可されていない送信者に対するSPFの失敗を示しますが、 -all はより厳格な適用意図を示します。
受信サーバーは -all より積極的に扱う場合があります。 ~allよりも厳しく扱う場合があります。
始めに ~all すべての送信元を確認している間は、正当なメールを拒否するリスクを減らすために、監視中に
使用 -all SPFソースが完全に設定され、DMARCレポートで認証のギャップがないことが確認された後にのみ使用してください。
DMARCは、認証失敗の処理方法（監視、隔離、または拒否）を定義します。
適切なSPFの最適化は、メールインフラが拡大するにつれて発生する10回のDNSルックアップ制限を回避するのに役立ちます。

SPFの理解 -all vs ~all はメール認証の重要な要素です。これらのメカニズムは、受信メールサーバーが許可されていない送信元からのメールをどのように扱うべきかを示すためです。両メカニズムともSPF失敗を示しますが、異なるレベルの強制意図を伝達し、受信者ポリシーに応じてメールのフィルタリングや拒否方法に影響を与える可能性があります。

The すべてのメカニズムはSPFレコードの末尾に現れ、その前には – (ハードフェイル) や ~ (softfail)などの修飾子が付きます。どちらを選択するかは、SPFレコードの完成度と、DMARCを使用して認証結果を積極的に監視しているかどうかに依存します。

この記事では、SPF -all および ~all の動作原理、現在のメールボックスプロバイダーによる解釈方法、そして正当なメール配信を危険にさらさずに各設定を安全に使用するタイミングについて解説します。

簡潔な回答： 使用 ~all で送信者検証とDMARC監視を実行してください。 -all に切り替えるのは、SPFが完全に実装され、DMARCレポートに正当な失敗が一切見られない場合のみです。

SPFレコードの構文と仕組みの解説

SPF -all と ~all の違いについて掘り下げる前に、完全なSPF レコードの構文と利用可能なすべてのメカニズムを理解することが不可欠です。

SPFレコードは特定の形式に従い、受信メールサーバーに対して、どのIPアドレスとドメインがあなたのドメインに代わってメールを送信する権限を持つかを通知します。

基本的なSPFレコードの構文は次の通りです：v=spf1 [メカニズム] [修飾子] [all]

SPF 全メカニズムオプション

SPFレコード末尾の「all」メカニズムは、メールが許可された送信者と一致しない場合に発生する処理を決定します。以下の4つのオプションがあります：

メカニズム	名前	結果	アクション
#NAME?	パス	PASS	すべてのメールを受信する（推奨されません）
すべて	ニュートラル	ニュートラル	ポリシーは指定されていません
～すべて	ソフトフェイル	ソフトフェイル	不審なメールとしてマークするが配信する
-すべて	ハードフェイル	失敗	不正な電子メールを拒否する

SPFレコードの例

以下は、異なるメカニズムを使用したSPFレコードの実用的な例です：

基本SPFとソフトフェイル: v=spf1 include:_spf.google.com ~all
複数のインクルードとハードフェイル: v=spf1 include:spf.protection.outlook.com include:_spf.salesforce.com -all
ソフトフェイル付きIPアドレス: v=spf1 ip4:192.168.1.0/24 ip6:2001:db8::/32 ~all
混合メカニズム: v=spf1 a mx include:_spf.google.com ip4:203.0.113.0/24 -all

SPF -all vs ~all

SPF -all および SPF ~all の両メカニズムは、SPF 認証において「NOT PASS」を意味します。近年、メールプロバイダーはSPF結果を複数の判断材料の一つとして利用しており、DMARCポリシーとレピュテーションシグナルが最終的な配信決定に大きく影響しています。

しかし、数年前まではそうではなかった。

v=spf1 -all とはどういう意味ですか？

SPFレコードの末尾に「-all」（ハードフェイル）を指定すると、受信メールサーバーはSPFレコードに記載された承認済み送信元以外からのメールをすべて拒否するよう指示されます。これは最も厳格なSPFポリシーであり、メールのなりすましに対する最強の保護を提供します。

SPFにおける「~all」とは何を意味しますか？

「~all」（ソフトフェイル）メカニズムは、受信サーバーに対し、許可されていない送信者からのメールを不審なものとマークしつつ、受信者の受信トレイ（多くの場合スパムフォルダ）へ配信するよう指示する。

DMARC導入前、SPFの全メカニズム（ソフトフェイル対フェイル）はどのように動作していたのか？

DMARCは、SPFが標準的な電子メール認証プロトコルとして市場に出回ってから長い年月を経て誕生しました。当時、SPF-all softfailの仕組みは以下のように動作していました：

あなたのSPFレコードがそうだったとしましょう。

v=spf1 include:spf.domain.com ~all (~all は SPF ソフトフェイルを意味します)

受信者のメールサーバーは、送信者のDNSに対してSPFレコードを照会するためDNSルックアップを実行します。メールのReturn-pathドメインが送信者のレコードに記載されていない場合、受信サーバーはSPF「NOT PASS」結果を返しますが、メールは受信者の受信トレイに配信されます。

ここで、あなたのSPFレコードがそうだったとします。

v=spf1 include:spf.domain.com -all (ここで -all は SPF 失敗を意味する)

受信者のメールサーバーは、送信者のDNSに対してSPFレコードを照会するためDNSルックアップを実行します。メールのReturn-pathドメインが送信者のレコードに記載されていない場合、受信サーバーはSPF「NOT PASS」結果を返しますが、このケースではメールは拒否され、受信者の受信トレイに配信されません。

Sender Policy Frameworkの Sender Policy Frameworkの歴史。

SPFレコード管理を簡素化する方法

組織が成長し、メール送信サービスを追加するにつれて、SPFレコードの管理は複雑になる可能性があります。 10件のDNSルックアップ制限は、超過するとSPF認証失敗を引き起こす一般的な課題です。 PowerDMARCの自動化されたSPF管理ソリューションは、高度な最適化技術を通じてこれらの課題を解決します。

PowerDMARCのSPFフラット化技術は、包括的なメール認証カバレッジを維持しながら、DNSルックアップ制限内に収まるようSPFレコードを自動的に最適化します。これにより、新しいメールサービスやマーケティングツールを追加しても、正当なメールが適切に認証され続けます。

パブロ・エレロスがPowerDMARCでDNS管理をいかに簡素化したか

管理対象のすべてのドメインにおいて、ドメインセキュリティスコア100%を達成しました

マルチドメインのSPF、DKIM、DMARC管理を簡素化

認証チェックの自動化によるクライアントのオンボーディングの迅速化

メールの配信率とドメインの評判の向上

G2での評価は4.9

世界中で3万人以上のユーザーにご利用いただいています

無料トライアルに登録する

現在、メールサービスプロバイダーはSPFの-allと~allの仕組みをどのように扱っているのか？

Gmail、Outlook、Yahooなどの現代的なメールサービスプロバイダーは、DMARC導入以前とは異なる方法でSPFメカニズムを扱っています。現在、主要プロバイダーの多くは配信判断において個々のSPF結果ではなく、DMARCポリシーを重視しています。

Gmailのアプローチ: GmailはSPFソフトフェイル（~all）を認証シグナルとして弱く見なす一方、ハードフェイル（-all）は、許可された送信元と一致しないメッセージに対する疑念を高める可能性があります。最終的な配信決定は、DMARCポリシーやその他のフィルタリング信号によって行われます。
Microsoft Outlook の処理: Outlook.com および Microsoft 365 は、フィルタリングと認証評価の一環として SPF の結果を考慮します。ハードフェイル (-all）はソフトフェイル（~all）よりも厳しく扱われる場合がありますが、最終的な処理はDMARCポリシーと追加のシグナルに依存します。

現時点では、ほとんどのメールボックスプロバイダーにおいて、正当なメールの配信失敗を心配することなくSPF -allまたは~allを使用できます。ただし、-all属性が設定されている場合、サーバーがメールを拒否する状況が発生する可能性があります。安全策として、SPFレコード作成時にSPFハードフェイルの-allメカニズムの使用を避けることをお勧めします。その方法は以下の通りです：

PowerDMARCを開く SPFレコード生成ツールを無料でレコード作成を開始
送信者のIPアドレスとドメインを入力した後、最後のセクションまでスクロールして、メールサーバーがお客様のメールを検証する際の厳密さを指示します。
Generate SPF Record "ボタンを押す前に、"Soft-fail "オプションを選択します。

以下の場合、SPF ~all (softfail) を使用してください：

メール認証が初めてで、配信リスクを最小限に抑えたい
御社は頻繁に新しいメール送信サービスを追加しています
DMARCの監視はまだ実装していません
テスト段階にあり、認証結果を観察したい

以下の場合、SPF -all (hardfail) を使用してください:

DMARCが適切に設定され、監視されています
あなたのSPFレコードには、すべての正当な送信元が含まれています
メールのなりすましに対する最大限の保護を望んでいます
メールインフラは安定しており、十分に文書化されています

SPF -allメカニズムに関連するメール配信の問題は、ごく稀に発生する可能性があります。これは、頻繁に発生する問題ではありません。この問題に遭遇しないようにするには、次の手順を実行することができます。

設定 DMARC メール用に設定し、 DMARCレポートを有効化
DMARCポリシーを設定してください DMARCポリシーをモニタリングに設定し、SPF認証結果を詳細に検証してメール配信における不整合を特定してください
問題がなければ、SPFレコードに-allメカニズムを使用することができます。ハードフェール属性は、メールの信頼性に自信があることを証明し、ドメインの評判を高めることができるため、使用することをお勧めします。

現在、SPF -allの使用を迷っている方は、以下の手順で使用することができます。

SPFレコードを設定する ~allメカニズムを使用したレコードを設定する
DMARCを設定するメール用にDMARCを設定し、DMARCレポートを有効にする
DMARCポリシーを拒否するように設定する

一般的なSPFレコードエラーのトラブルシューティング方法

SPFエラーは通常、以下の4つのカテゴリーに分類されます：レコードの欠落、レコードの重複、レコードの無効、DNSルックアップの失敗。以下のエラーラベルを参照し、迅速に修正箇所を特定してください。

よくあるSPFエラーには以下が含まれます：

SPF PermError: SPFレコードが無効です。これは通常、構文エラーやレコードが10件のDNSルックアップ制限を超えていることが原因です（例：メカニズム）が原因で発生します。メカニズムの過剰使用など）。
SPF TempError: 一時的なDNS解決の問題（タイムアウト、一時的なDNS障害）。自然に解決する場合もありますが、TempErrorが繰り返し発生する場合は、通常、不安定なDNSまたはネームサーバーの問題を示しています。
SPF なし: 確認対象のドメインにSPFレコードが見つかりませんでした。これは通常、SPFが公開されていない、誤ったドメインに公開されている、またはDNSが反映されていないことを意味します。
複数のSPFレコード：同一ドメインに対して複数のSPF TXTレコードが存在するため、SPF評価が破綻し、認証失敗を引き起こすことが一般的です。

頻繁に「SPFレコードが見つかりません」というメッセージが表示される場合、受信サーバーがDNSでSPF TXTレコードを照会した際に空の結果を返したことを意味します。これはレコードの欠落、確認対象ドメインの誤り（Return-PathとFromの混同）、またはDNSの公開/伝播の問題が原因で発生します。（「SPFレコードが見つかりません」に関する記事へのリンクをここに挿入）

SPFと併せてDMARCを設定している場合、受信サーバーは認証に失敗したメッセージの処理方法を決定するため、DMARCポリシーも評価します。ポリシーに基づき、失敗したメッセージは配信、隔離、または拒否される可能性があります。DMARC拒否ポリシーは、認証されていないメールをブロックするよう受信者に指示することで、なりすましやフィッシングなどのなりすまし攻撃を大幅に削減できます。

PowerDMARCのSPF監視は、認証問題をフラグ付けし、根本原因を明らかにし、配信率に影響が出る前に修正手順を案内することで、これらのエラーを早期に発見するお手伝いをします。