SPFでは、メッセージに対して複数ある結果のいずれかが返され、そのうち2つは強度の異なる失敗です。どちらになるかは、問題の深刻度ではなく、SPFレコードの末尾の記述によって決まります。
Received-SPF: softfail (google.com: domain of transitioning bounce@example.com
does not designate 203.0.113.5 as permitted sender) client-ip=203.0.113.5;「Transitioning」は、ドメインがsoftfailを指定したことを示すGmailの表現です。残りの部分が重要です。203.0.113.5のサーバーがexample.comをエンベロープ送信者としてメールを送信しましたが、example.comのSPFレコードにはこのサーバーが記載されていません。
Softfailとhardfail
レコード末尾のallは、「それ以外の送信元はどうするか」という問いに答えます。
-allはfailで、一般にhardfailと呼ばれます。記載されていないサーバーには、そのドメインとして送信する権限がありません。~allはsoftfailです。記載されていないサーバーは正規の送信元ではない可能性がありますが、それだけを理由にメールを拒否しません。?allはneutralです。レコードは記載されていないサーバーについて何も示さないため、保護にはなりません。
DMARCレコードが設定されている場合、この違いは以前ほど重要ではありません。DMARCは、表示される送信者と整合するドメインでSPFがpassしたかを確認します。softfailとfailは、どちらも「passしなかった」として扱われます。その後の受信側の処理はDMARCポリシーに従います。DMARCがない場合、受信側は独自に判断し、hardfailで拒否することがあります。Gmailの550 5.7.26には、ドメインが"has an SPF record with a hard fail policy (-all)"と示すものがあります。
どちらを使うかについては、そのドメインとして送信するすべてのサービスをまだ確認している段階では~allを使用し、DMARCレポートで正規のメールが失敗していないことを確認できたら-allを使用します。DMARCがp=quarantineまたはp=rejectであれば、どちらでも問題ありません。
サーバーをpassさせる
softfailは、レコードが記述どおりに機能していることを示します。ヘッダー内のサーバーを許可すべき場合は、次のように修正します。
- IPの所有者を特定します。通常は、逆引きまたはプロバイダーのドキュメントで、どのサービスかを確認できます。
- 使用しているサービスであれば、そのincludeまたはアドレスをレコードに追加します。その際は、10回のルックアップ制限に注意してください。SPFチェッカーで回数を確認できます。
- メッセージを中継している転送サービス、メーリングリスト、またはセキュリティゲートウェイの場合、仕様上、そこでSPFをpassさせることはできません。自分のドメインによるDKIM署名は、メッセージを変更しない転送サービスを経由しても維持され、DMARCもpassし続けます。
- まったく心当たりがない場合、第三者が自分のドメインを使用して送信している可能性があります。softfailは正しく機能しています。そのメールを阻止するには、DMARCを
p=quarantineまたはp=rejectに設定します。
その他に表示される可能性がある結果
spf=none は、ドメインにSPFレコードがないことを意味します。spf=permerror は、レコードは存在するものの評価できないことを意味します。原因として、1つの名前に2つのレコードがある、DNSルックアップが10回を超えている、構文エラーがある、のいずれかが考えられます。複数のSPFレコードとDNSルックアップが多すぎる場合を参照してください。spf=temperror はDNS障害を意味し、自然に解消する場合があります。
テスト結果での表示
SPFチェックでは、softfailは失敗ではなく警告として扱われます。これは、~allがその動作を指定しているためです。その横には、確認対象のエンベロープドメイン、送信元IP、受信サーバー独自のコメントが表示されます。"domain of transitioning"の行も含まれるため、確認すべきアドレスがその場で分かります。