SPF softfail（~all）とhard fail（-all）の違いと使い分け

softfailとhard failで受信側の扱いはどう違う？

SPFが出すのはシグナルで、結果を決めるのは受信サーバーです。RFC 7208は結果を次のように定めています。

• Fail（-all）は、クライアントにそのアイデンティティを使う権限がないという明確な宣言です。受信側はSMTPのやり取りの中で、メッセージをそのまま拒否できます。
• Softfail（~all）はneutralとfailの中間です。ドメイン側は、メールはおそらく許可されていないと考えているものの、確信はありません。RFCは、受信ソフトウェアがsoftfailだけを理由に拒否すべきではない（SHOULD NOT）としつつ、通常より厳しく確認してもよい（MAY）としています。実際には迷惑メールフォルダに入ることが多くなります。

SPFが何を評価するかにも注意が必要です。SPFがチェックするのはSMTPのアイデンティティで、通常はエンベロープ送信者です。メールソフトで人が目にするアドレスではありません。このアイデンティティの決まり方はSPFの概要で解説しています。表示上のFromドメインを守るのはDMARCのアライメントで、通常はDKIMがもう一つの認証経路になります。

?allと+allの扱い

?allと+allは、SPFが定める残り2つの末尾の限定子です。どちらも本番の送信ドメインには向きません。

• ?all（neutral）は何も主張しません。記載のない送信者は許可も否定もされないため、受信側はSPFポリシーがない場合とほぼ同じように扱います。正当な用途は、送信元を棚卸しする間の短期間のテストだけです。
• +all（pass）は、インターネット上のすべてのサーバーに自社ドメインとしての送信を許可すると宣言します。なりすましを積極的に助けるうえ、多くのフィルターはこれ自体を迷惑メールのシグナルとして扱います。公開する理由はありません。

転送でSPFのhard failが壊れる理由

転送サーバーは自身のIPアドレスからメッセージを中継し、そのIPはSPFレコードに記載されていないため、SPFのhard failが壊れます。SPFはこの中継となりすましを区別できないので、正規に送信したメールでもfailになります。流れは次のとおりです。

1. 受信者が、たとえば勤務先のアドレスからGmailへメールを自動転送すると、転送サーバーが新たな送信サーバーになります。
2. その転送サーバーはSPFレコードにないため、SPFはfailになります。
3. -allの場合、受信側はSPFの結果だけで転送メッセージを拒否することがあります。正規のメールが失われます。
4. ~allの場合、メッセージは疑わしいものとして受け入れられ、DKIMとDMARCで正しく認証される機会が残ります。

DMARC導入済みなら~allは-allより弱い？

いいえ。DMARCでポリシーを強制していれば、softfailとhard failのなりすまし対策の効果は同じです。RFC 7489を廃止した現行のDMARC仕様であるRFC 9989は、SPFをPassかPass以外か、そして表示上のFromドメインとのアライメントで評価します。softfailとhard failは区別しません。

• SPFかDKIMがPassかつアライメント一致なら、DMARCにPassします。
• どちらでもなければ、DMARCポリシー（p=quarantineまたはp=reject）が適用されます。

業界の推奨

メールを送信するドメインに対する業界の推奨は~allです。DMARCや到達率の分野はこの考え方に傾いており、公にもそう述べています。

• Google Workspaceははっきりsoftfailを推奨しています。そのSPFのドキュメントは、Workspaceだけで送信するドメインのレコードとしてv=spf1 include:_spf.google.com ~allを示し、hard failの限定子では「SPFチェックに失敗したメッセージは受信サーバーで拒否されやすくなり、そのメッセージをSPFレコードのトラブルシューティングに使えなくなる」と注意しています。
• Spam ResourceのAl Iverson氏は、この質問に直接答えています。基本の答えは-allでしたが、DMARCを運用する人向けに追記しています。ポリシーがp=quarantineかp=rejectになったら「~all（チルダall）のほうがおそらく良い」というものです。DMARCより先に評価されたSPFのfailが、DMARCレポートにまったく現れない拒否を招くことがあるためです。
• RFC 7208は、softfailだけを理由に拒否しないよう受信側に求めています。そもそも2つの結果の動作が異なるのはこのためです。

注目すべき反対意見はMicrosoftです。同社のMicrosoft 365のSPFガイダンスは-allを推奨し、その根拠を「メッセージにDKIM署名もない場合、SPFの~allの失敗に対してDMARCポリシーは事実上無視される」としています。この条件はよく読んでください。議論のすべてがここにあります。対象はDKIM署名がまったくないメッセージです。DMARC仕様自体はsoftfailとfailを区別しないため、これは標準ではなく1つの受信側の動作です。すべての送信サービスにDKIMで署名させれば（いずれにせよ必要です）、この反論は自社のメールには当てはまらなくなります。

~allと-allの使い分け

~allと-allのどちらを使うかは、どちらが厳しく聞こえるかではなく、ドメインの用途で決まります。用途ごとに判断します。

• メールを送信するドメイン（メインのドメイン）：~allを使い、すべての送信サービスでDKIMを有効にし、DMARCをp=quarantine、続いてp=rejectへ強化します。転送メールを犠牲にせずになりすましを防げます。
• メールを送信しないドメイン（パーキングドメイン、Web専用ドメイン）：v=spf1 -allだけのレコードとDMARCのp=rejectを公開します。失われる正規のメールはなく、なりすましを完全に防げます。
• 送信元をまだ棚卸し中の場合：~allを使います。送信ドメインはいずれにせよここに落ち着きます。棚卸しで変わるのはどの送信元を許可するかで、末尾の限定子ではありません。

~allから-allへ移行すべき業界の期限はなく、移行した先に到達率のボーナスがあるわけでもありません。メールを送信するドメインでは、~allは通過点ではなく最終形です。時間をかけて強化するのはDMARCポリシーで、SPFの限定子ではありません。何らかの理由でレコードを変更する場合は、元に戻せるよう以前の値とそのTTLを控えておいてください。

~allとDMARCを安全に設定する手順

~allとDMARCを安全に導入するには、まずsoftfailでSPFを公開し、すべての送信元にDKIMで署名させてから、DMARCポリシーを強化します。次の6つの手順を順番に進めてください。

1. softfailでSPFを公開する。正規の送信サービスをすべて記載します。

v=spf1 include:_spf.google.com include:sendgrid.net ~all

このレコードは例です。例の値ではなく、自社の送信元が文書で示すメカニズムを公開してください。

2. DKIM署名を有効にする。自社ドメインとして送信するすべてのサービスが対象です。これがsoftfailを安全にし、先ほどのMicrosoftの反論への答えにもなります。
3. DMARCレコードをp=noneで公開する。DMARCレコード生成ツールで正しく作成できます。
4. 集計レポートを監視する。正規の送信元がすべてアライメント付きでPassするまで続けます。集計レポートが届くまでには一日以上かかります。1つの送信経路をすぐ確認したい場合は、メール到達率テストが送信したメッセージ一通を評価し、SPFとDKIMのアライメントを示します。
5. DMARCをp=quarantine、続いてp=rejectに移行する。ここで本格的ななりすまし対策が効きます。
6. レコードを最新に保つ。新しいツールの追加ごとに更新し、SPFのDNS参照項目の上限10個を超えないようにします。

完成した設定は、SPFチェックツールでいつでも検証できます。SPFレコードが1つであること、構文が有効であること、allが最後にあること、評価が10項目の上限内に収まることを確認してください。

まず公開中のSPFポリシーをチェック

限定子を変える前に、PalisadeのSPFチェックツールでドメインを確認し、そのDNSの結果を、届いたメッセージで評価されたアイデンティティと接続元IPと比べてください。チェックツールが読むのは公開レコードで、受信側の非公開の処理までは再現できません。

送信元の変更が続いて棚卸しの維持が難しい場合は、PalisadeのDMARC Agentの修正ガイドで、レポートの検出結果が送信元ごとのSPF、DKIM、アライメントの作業になる流れを説明しています。残る課題がレポートに基づく送信元の継続的な監視なら、今すぐ始めましょう。