ソフトバウンス（Soft Bounce）
概要
ソフトバウンス（Soft Bounce） は、一時的な原因によってメールが受信サーバーに配信できなかった状態を指します。SMTP プロトコルでは 4xx 系の応答コードで表現され、送信側の MTA（Mail Transfer Agent）が一定期間にわたり自動で再送を試みます。RFC 5321（2008年）はこの再送処理の仕様を定めており、再送の間隔と期間は MTA の実装に委ねられています。
ソフトバウンスが発生する代表的な原因は、受信者のメールボックス容量超過、受信サーバーの一時的な過負荷、ネットワーク接続の不安定さ、グレイリスティングによる意図的な一時拒否です。いずれも時間が経てば解消する可能性があるため、MTA は即座に配信を諦めず再送キューに入れます。
ハードバウンス（Hard Bounce）が SMTP 5xx 系の永続的なエラーで「宛先が存在しない」「ドメインが無効」といった回復不能な原因を示すのに対し、ソフトバウンスは一時的な状態異常です。ただし再送がすべて失敗すると、最終的に配信断念（permanent failure）として送信者に NDR（Non-Delivery Report）が返されます。
仕組み
ソフトバウンスは SMTP の 4xx 応答コードで表現され、MTA の再送キューと拡張ステータスコードによって処理されます。
SMTP 4xx 応答と再送キュー
SMTP の通信では、受信サーバーがメールを受け取れない場合に 3 桁の応答コードを返します。RFC 5321 は応答コードの先頭桁で意味を分類しており、4xx は「一時的な障害（Transient Negative Completion）」を示します。
代表的な 4xx コードと原因を以下に示します。
| 応答コード | 意味 |
|---|---|
| 421 | サービスが一時的に利用不可。サーバーが過負荷またはメンテナンス中 |
| 450 | メールボックスが利用不可。ロック中またはポリシーによる一時拒否 |
| 451 | ローカルエラーにより処理を中断。サーバー内部の一時障害 |
| 452 | ストレージ不足。受信者のメールボックスまたはサーバーの容量超過 |
送信側 MTA はこれらの応答を受け取ると、メールを再送キューに入れます。RFC 5321 は再送間隔を 最低 30 分空けることを推奨しており、再送を試みる期間の上限として 4〜5 日が一般的です。Postfix のデフォルト設定では再送期間が 5 日、Sendmail では同様に 5 日間再送を試みます。
グレイリスティングとソフトバウンス
グレイリスティング（Greylisting）は、スパム対策として初回の接続を意図的に 4xx で拒否し、正規の MTA が再送してきた場合にのみ受け入れる手法です。スパム送信ツールの多くは再送処理を実装していないため、この仕組みでスパムを排除します。
グレイリスティングによるソフトバウンスは、送信者側から見ると通常の一時障害と区別できません。MTA が再送を試みれば数分〜数十分後に正常に配信されます。ただし初回配信に遅延が生じるため、即時性が求められるトランザクションメール（パスワードリセットや二要素認証コード）では問題になることがあります。
拡張ステータスコード（Enhanced Status Codes）
RFC 3463（2003年）は、3 桁の応答コードに加えて詳細な原因を示す拡張ステータスコードを定義しています。形式は class.subject.detail の 3 つの数字で構成されます。
| 拡張ステータスコード | 意味 |
|---|---|
| 4.2.2 | メールボックス容量超過 |
| 4.4.1 | 受信サーバーへの接続タイムアウト |
| 4.4.2 | 接続が切断された |
| 4.7.1 | ポリシーによる一時的な拒否（グレイリスティング含む） |
メール配信サービス（SendGrid、Amazon SES、Mailgun 等）はこの拡張ステータスコードをバウンス分類に利用しています。管理画面で「Soft Bounce」と表示される際の内訳として、これらのコードが参照されます。
具体例
NDR（Non-Delivery Report）と MTA ログに記録されるソフトバウンスの実例を示します。
バウンスメール（NDR）の例
再送がすべて失敗した場合、送信者に返される NDR には以下のような情報が含まれます。
From: MAILER-DAEMON@mail.example.com
Subject: Undelivered Mail Returned to Sender
This is the mail system at host mail.example.com.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients.
<user@recipient.example.com>: host mx.recipient.example.com[198.51.100.25]
said: 452 4.2.2 Mailbox full (in reply to RCPT TO command)
The mail system will continue to try to deliver the message for 5 days.この例では応答コード 452 と拡張ステータスコード 4.2.2 がメールボックス容量超過を示しています。MTA はまだ再送を試みている段階であり、5 日間以内に受信者がメールボックスの容量を確保すれば配信が成功します。
SMTP セッションログの例
MTA のログで見えるソフトバウンスの典型的な記録です。
May 10 14:23:01 mail postfix/smtp[12345]: to=<user@recipient.example.com>,
relay=mx.recipient.example.com[198.51.100.25]:25, delay=0.52,
status=deferred (host mx.recipient.example.com said: 451 4.7.1
Please try again later (in reply to MAIL FROM command))status=deferred はソフトバウンスにより再送キューに入ったことを示します。delay はこの送信試行にかかった時間です。
確認方法
メールサーバーのログからソフトバウンスの発生状況を確認するには、MTA のログファイルを調べます。Postfix の場合は次のコマンドで deferred（再送待ち）のメールを確認できます。
postqueue -p再送キューに入っているメールの一覧が表示されます。特定の宛先への配信状況を詳しく調べる場合は、ログファイルを直接検索します。
grep "status=deferred" /var/log/mail.logSPF・DKIM・DMARC の認証失敗がソフトバウンスの原因となっている場合は、メール認証レコードの設定を確認します。
dig TXT example.comdig TXT _dmarc.example.com外部の視点からも確認したい場合は、Labee Dev Toolbox の Mail Auth API を使うと、外部の視点から見た結果を取得できます。
curl "https://labee.dev/api/mail-auth?domain=example.com"レスポンスは次の形式で返ります。
{
"success": true,
"data": {
"spf": {
"record": "v=spf1 include:_spf.google.com ~all",
"exists": true
},
"dkim": {
"record": null,
"exists": false,
"selector": "default"
},
"dmarc": {
"record": "v=DMARC1; p=reject; rua=mailto:dmarc@example.com",
"exists": true
},
"bimi": {
"record": null,
"exists": false
}
},
"error": null,
"meta": { "responseTime": 120 }
}data.spf.exists、data.dkim.exists、data.dmarc.exists がそれぞれ true であれば、各認証レコードが外部から正しく参照できる状態です。認証設定の不備がソフトバウンスの原因となっていないかを切り分ける際に利用します。
よくある問題
ソフトバウンスが配信の問題に発展するのは、同一宛先への反復発生、認証設定の不備、レート超過のケースです。
ソフトバウンスが繰り返し発生する
同一の宛先で継続的にソフトバウンスが発生する場合、根本原因が一時的でない可能性があります。受信者のメールボックスが放置されていたり、受信サーバーの設定に永続的な問題があるケースです。メール配信サービスでは、ソフトバウンスが一定回数（SendGrid は 3 回、Amazon SES はサービス側で判断）を超えると、そのアドレスを自動的にサプレッションリストに追加し、以降の送信を停止します。
配信リストの衛生管理として、繰り返しソフトバウンスするアドレスは定期的にリストから除外する運用が必要です。放置すると送信者レピュテーションが低下し、正常な宛先への配信にも悪影響を及ぼします。
メール認証失敗によるソフトバウンス
受信サーバーのポリシーによっては、SPF や DKIM の認証に失敗したメールを 4xx で一時拒否する場合があります。DMARC ポリシーが p=quarantine で運用されている受信ドメインでは、認証失敗メールを即座にリジェクトせず一時的に拒否し、再送時に再評価するサーバーもあります。
この場合、再送しても認証設定を修正しない限り同じ結果になります。dig や Labee の Mail Auth API で SPF・DKIM・DMARC の設定を確認し、送信ドメインの認証レコードを正しく設定してください。
送信レートの超過
大量のメールを短時間で送信すると、受信サーバーがレート制限を適用して 4xx で応答します。Gmail は送信者ごとにレート制限を設けており、制限を超えると 421-4.7.28 Our system has detected an unusual rate of unsolicited mail を返します。
レート制限によるソフトバウンスは、送信速度を落とすことで解消します。メール配信サービスのスロットリング機能を使うか、IP ウォームアップを行って送信レピュテーションを段階的に構築します。
ソフトバウンスとハードバウンスの誤分類
メール配信サービスによって、バウンスの分類基準が異なる場合があります。あるサービスでソフトバウンスと判定されたものが、別のサービスではハードバウンスとして扱われることがあります。特に 450（メールボックス利用不可）は、原因によってソフトバウンスにもハードバウンスにも分類されうるコードです。
バウンスレポートを確認する際は、SMTP 応答コードと拡張ステータスコードの両方を見て、配信サービスの分類に頼りすぎないことが実務上の対策です。