ハードバウンス（Hard Bounce）

概要

ハードバウンス（Hard Bounce） は、宛先メールアドレスの不存在やドメインの消滅など、永続的な原因によってメールが配信できず、受信サーバーから SMTP 5xx エラーで拒否される現象です。仕様上の根拠は RFC 5321（2008年）のセクション 4.2.1 にあり、応答コードの先頭が「5」であれば「永続的な否定応答（Permanent Negative Completion reply）」と定義されています。

ハードバウンスが発生したアドレスに再送しても結果は変わりません。送信側が取るべき対応は、該当アドレスを配信リストから即座に除外することです。除外せずに送り続けると、受信プロバイダー側で送信元の IP アドレスやドメインの評価（レピュテーション）が低下し、正常なアドレス宛のメールまで迷惑メール扱いされる原因になります。

一時的な原因（メールボックス容量超過、受信サーバーの一時停止など）で返される 4xx エラーは「ソフトバウンス」と呼ばれ、ハードバウンスとは区別されます。ソフトバウンスは時間をおいて再送すれば届く可能性がありますが、ハードバウンスにその見込みはありません。

仕組み

SMTP の応答コード体系、ハードバウンスを引き起こす主な原因を説明します。

SMTP 応答コードとバウンスの判定

メール送信時、送信サーバー（MTA）は受信サーバーと SMTP で通信します。受信サーバーは各コマンドに対して 3 桁の応答コードを返し、先頭の数字がそのメッセージの処理結果を示します。

先頭の数字	意味	例
2xx	成功	250 OK
4xx	一時的失敗（ソフトバウンス）	452 メールボックス容量超過
5xx	永続的失敗（ハードバウンス）	550 ユーザー不明

ハードバウンスを引き起こす代表的な応答コードは次の通りです。

• 550 — メールボックスが存在しない、またはアクセスできない
• 551 — ユーザーがローカルに存在しない（転送先も不明）
• 553 — メールボックス名の構文が不正
• 556 — そのドメインはメールを受け付けない（RFC 7504 で定義）

拡張ステータスコード

RFC 3463（2003年）は、3 桁の応答コードだけでは原因を特定しにくい問題を解決するため、ドット区切りの拡張ステータスコードを定義しました。先頭が「5」のコードが永続的失敗を示します。

拡張ステータスコード	意味
5.1.1	宛先メールボックスが存在しない
5.1.2	宛先ドメインが存在しない
5.1.3	宛先アドレスの構文が不正
5.2.1	メールボックスが無効化されている
5.7.1	セキュリティポリシーにより拒否された

実際のバウンスメール（DSN: Delivery Status Notification）には、3 桁のコードと拡張ステータスコードの両方が含まれます。RFC 3461（2003年）が DSN の仕様を定めており、送信者はこの通知から失敗の原因を機械的に判定できます。

ハードバウンスが発生する主な原因

原因は大きく 3 つに分類できます。

アドレスの問題として、メールアドレスのタイプミス（user@exmple.com のように ‘a’ が抜けている）、退職・異動によるアカウント削除、存在しないエイリアスへの送信があります。

ドメインの問題として、ドメインの有効期限切れ、MX レコードの未設定、ドメインがメール受信を拒否する設定（RFC 7504 の Null MX: MX レコードに . を設定）があります。

ポリシーによる拒否として、送信元の SPF / DKIM / DMARC 認証が失敗し受信側が p=reject で拒否するケースや、送信元 IP が DNSBL（DNS ブロックリスト）に登録されているケースがあります。認証失敗による 5xx 拒否は、厳密には宛先の問題ではなく送信側の設定問題ですが、SMTP の応答としては同じ 5xx で返されます。

確認方法

ハードバウンスが発生しているかどうかは、送信サーバーのログで確認します。Postfix の場合、メールログに応答コードが記録されます。

grep "status=bounced" /var/log/mail.log | grep "550"

status=bounced かつ 5xx の応答コードが記録されている行がハードバウンスです。4xx は一時的失敗（ソフトバウンス）を意味するため区別してください。

バウンスの原因がメール認証の失敗にある場合、送信元ドメインの SPF・DKIM・DMARC 設定を dig で確認します。

dig TXT example.com

dig TXT _dmarc.example.com

SPF レコードが存在しない、または DMARC ポリシーが p=reject で認証に通過しない設定になっていると、受信側が 5xx で拒否する原因になります。

外部の視点からも確認したい場合は、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 であれば、各認証レコードが外部から確認できる状態です。いずれかが false の場合、受信側のポリシー次第でハードバウンスの原因になります。

よくある問題

ハードバウンスに関連する運用ミスとその対処法を整理します。

ハードバウンスを無視して送り続ける

ハードバウンスが発生したアドレスへ繰り返し送信すると、受信プロバイダーはその送信元を「リストクリーニングを行わない低品質な送信者」と判断します。Google の送信者ガイドラインでは、バウンスが繰り返されるアドレスを自動で配信停止にすることを求めています。対応しないと、送信元 IP のレピュテーションが低下し、有効なアドレス宛のメールもスパムフォルダに振り分けられます。

ソフトバウンスとの混同

メールボックス容量超過は、一般的には 4xx（ソフトバウンス）で返されますが、プロバイダーによっては 552（5xx）で返す実装もあります。3 桁コードだけで判断すると誤分類する場合があるため、拡張ステータスコード（5.2.2 など）を併せて確認してください。SendGrid や Amazon SES などの配信サービスは、拡張ステータスコードに基づいてハードバウンスとソフトバウンスを自動分類します。

メール認証の未設定がハードバウンスを引き起こす

2025年11月以降、Google は 5,000 通/日以上の送信者に対して SPF・DKIM・DMARC の設定を義務化し、非準拠のメールは一時的または永続的に拒否する運用に移行しています。認証未設定のまま大量送信すると、以前は迷惑メール扱いで済んでいたものが 5xx で拒否されるハードバウンスに変わります。

この問題を解消するには、送信ドメインに SPF レコードと DKIM 署名を設定し、DMARC ポリシーを p=none から段階的に p=quarantine、p=reject へ強化します。

DNSBL 登録によるハードバウンス

送信元 IP アドレスが DNSBL に登録されると、その IP からのメールを受信側が 5xx で拒否します。この場合、宛先アドレス自体は有効でも、送信元の問題でハードバウンスが発生します。DNSBL への登録原因は、スパム送信、ハードバウンス率の高さ、オープンリレーの設定ミスなどです。

解除するには、まず原因を特定・修正したうえで、各 DNSBL の解除申請手続きを行います。Spamhaus や Barracuda などの主要な DNSBL はオンラインで解除申請を受け付けています。

バウンス率の管理

送信者のレピュテーションを維持するには、バウンス率の監視と管理が必要です。

Google の送信者ガイドラインは、Postmaster Tools で報告されるスパム率を 0.3% 未満に維持することを求めています。ハードバウンス率についても業界の一般的な基準として 2% 以下が推奨されており、これを超えるとレピュテーションへの影響が顕著になります。

バウンス率を低く保つための運用として、以下の 3 点が基本です。

1. ハードバウンスが発生したアドレスは即座にサプレッションリスト（配信停止リスト）に追加する
2. メールアドレスの収集時にダブルオプトイン（確認メールの送信）を使い、無効アドレスの混入を防ぐ
3. 長期間アクティブでないアドレスを定期的にリストから除外する

SendGrid、Amazon SES、Mailgun などの配信サービスは、ハードバウンスを検出すると該当アドレスをサプレッションリストへ自動登録します。自前の MTA で運用している場合は、バウンス処理の自動化を別途実装する必要があります。