この記事では `452 4.2.2`（mailbox full）の意味、なぜ一時的なエラーなのか、送信側でできること、相手に伝えるべきことを整理します。

## エラーコード `452 4.2.2` の正体

SMTP（メールを送受信する通信手順、RFC 5321）の応答は 3 桁の数字で表されます。`452` は「Requested action not taken: insufficient system storage（要求された処理を実行できなかった: 保存領域不足）」を意味します。続く `4.2.2` は拡張ステータスコード（RFC 3463）で、`2.2` は「Mailbox full（受信箱が満杯）」を指します。

ここで最も重要なのは **先頭の数字** です。

- **`4xx`**: 一時拒否。送信側がリトライすれば配信される可能性がある
- **`5xx`**: 永続拒否。同じ条件でリトライしても結果は変わらない

`452 4.2.2` は `4xx` なので **一時的なエラー** です。「いまは相手の受信箱がいっぱいで受け取れないが、相手が容量を空ければ後で届く可能性がある」という応答です。きちんと実装された送信側のメールサーバ（Postfix / Exim / Microsoft 365 / Google Workspace 等）は、自動的に再送（典型的には数分後、数十分後、数時間後と間隔を空けて再試行）します。

コード全体の体系は[SMTP 応答コード早見表](/blog/smtp-reply-codes-reference)で、バウンスの分類は[メールバウンスの分類と対処](/blog/email-bounce-classification)で整理しています。本記事は「受信側の容量超過」という具体的なパターンに絞ります。

![452 4.2.2 のコード構造と 4xx/5xx の違い](/blog/bounce-452-mailbox-full/code-structure.svg)

## なぜ「相手都合」のエラーなのか

`452 4.2.2` は、送信側の設定ミスではなく **受信側（相手）の事情** で発生します。具体的には次のような状態です。

- 相手のメールボックスが契約上の保存容量上限に達している
- 古いメールや大きな添付ファイルが溜まり、空き容量がない
- 受信側サーバ全体のストレージが逼迫している（この場合は複数の宛先で同時に発生する）

つまり、あなたのドメインの SPF / DKIM / DMARC（メールが正規の送信元から送られたことを証明する仕組み）が正しく設定されていても、相手の受信箱が満杯なら `452 4.2.2` は返ります。認証の問題と切り分けることが、最初の一歩です。

ビジネスへの影響という観点では、見積書・請求書・契約関連の重要メールが「送ったつもりで届いていない」状態になり得ます。送信側のログを確認せず「送信済み」と思い込むと、商談や入金の遅延につながります。

## 一時拒否と永続拒否を取り違えない

似た見た目のコードでも、`4xx` と `5xx` では対処がまったく異なります。

| コード | 区分 | 意味 | 基本対処 |
| --- | --- | --- | --- |
| `452 4.2.2` | 一時（4xx） | 受信箱が満杯 | 再送に任せて待つ／相手に連絡 |
| `552 5.2.2` | 永続（5xx） | 容量超過で恒久拒否 | 相手の容量解放が必要 |
| `554 5.7.1` | 永続（5xx） | ポリシー拒否 | 送信側で原因を解消 |

`452`（4xx）は再送対象ですが、同じ「mailbox full」でも `552`（5xx）を返す受信側もあります。`552 5.2.2` まで進むと送信側のリトライは打ち切られるため、相手が容量を空けない限り届きません。バウンスメールに記載されたコードの先頭が `4` か `5` かを必ず確認してください。

恒久拒否の代表例である `554 5.7.1` については[554 5.7.1 でメールが拒否される原因と対処](/blog/bounce-554-571-rejected)で詳しく扱っています。

![452 受信から再送・解消までのタイムライン](/blog/bounce-452-mailbox-full/timeline.svg)

## 送信側でできること

`452 4.2.2` は相手都合のため、送信側で「完全に解決する」ことはできません。ただし、できることはあります。

### まず送信ログを確認する

送信側のメールサーバのログ（Postfix なら `/var/log/mail.log`、Microsoft 365 なら Exchange Admin Center のメッセージトレース）で、**再送が行われているか・最終的に配信されたか** を確認します。多くの場合、相手が受信箱を整理すれば数時間から数日のうちに自動で届きます。

### 再送に任せる

`4xx` は送信側のサーバが自動再送します。慌てて同じメールを手動で何度も送り直すと、相手のサーバから「短時間の大量送信」と見なされ、別のエラー（レート制限など）を誘発することがあります。基本は再送機構に任せます。

### 別経路で相手に連絡する

業務上急ぐ場合は、電話やチャットなど別の手段で「メールが受信箱満杯で届いていない可能性がある」と伝え、容量の整理を依頼します。これが最も確実です。

### 大量送信時は輻輳に注意する

メルマガや一斉通知のように多数の宛先へ送る場合、個々の受信者の受信箱満杯に加え、受信側サーバの輻輳（混雑）で `452` が増えることがあります。送信レートを抑え（例: 毎秒数通程度に制限）、配信時間帯を分散すると、一時エラーの発生を減らせます。

## 相手に伝えるべきこと

相手（受信者）側で対処してもらう場合、次の内容を平易に伝えると行き違いが減ります。

1. **受信箱の容量が上限に達している可能性がある** こと
2. 古いメールや大きな添付ファイルを削除、またはアーカイブして空き容量を作ってほしいこと
3. 容量が解放されれば、送信側からの再送で自動的に届く可能性があること
4. それでも届かない場合は、受信側のメール管理者（契約しているメールサービスのサポート）に容量プランの確認を依頼してほしいこと

「あなたのメールが拒否された」のではなく「相手の箱がいっぱいだった」という事実を、責めるニュアンスなく共有することが、円滑な解決につながります。

## まとめ

- `452 4.2.2` は受信箱満杯による **一時拒否（4xx）**。送信側の設定ミスではなく相手都合
- `4xx` は再送対象。送信側サーバが自動再送し、相手が容量を空ければ届く可能性がある
- 同じ「mailbox full」でも `552 5.2.2`（5xx）は永続拒否。コードの先頭が `4` か `5` かを必ず確認
- 送信側はログ確認・再送任せ・別経路連絡が基本。手動の連投は逆効果になり得る
- 大量送信時は送信レート抑制と時間分散で輻輳を緩和できる

## よくある質問

### 452 4.2.2 は自然に解決しますか

相手が受信箱の容量を空ければ、送信側サーバの自動再送によって届く可能性があります。ただし容量が解放されないまま送信側のリトライ上限に達したり、受信側が `552 5.2.2`（永続拒否）に切り替えたりすると配信失敗で確定します。急ぐ場合は別経路で相手に連絡してください。

### 何度も手動で送り直してもいいですか

おすすめしません。`4xx` は送信側サーバが自動で再送します。手動で連投すると、短時間の大量送信と見なされてレート制限などの別エラーを招くことがあります。再送機構に任せるのが基本です。

### SPF や DKIM の設定が原因のこともありますか

`452 4.2.2`（mailbox full）は受信側の容量超過を示すコードで、認証の不備とは別の事象です。ただし複数の宛先で配信トラブルが起きている場合は、容量超過とは別に認証設定も確認しておくと安心です。認証失敗が主因の拒否は[554 5.7.1 でメールが拒否される原因と対処](/blog/bounce-554-571-rejected)を参照してください。

### 452 と 550 の違いは何ですか

`452` は `4xx` で一時拒否（再送で回復しうる）、`550` は `5xx` で永続拒否です。`550 5.1.1`（宛先不明）などは送信側で宛先を見直す必要があります。詳しくは[550 5.1.1 宛先不明の原因と対処](/blog/bounce-550-511-user-unknown)を参照してください。

## まずは現状を把握しましょう

自社のドメインがどのような状態にあるか、無料の[ドメイン診断](/diagnose)で現状をチェックできます。
SPF・DKIM・DMARC・SSL の状態が数十秒でレポートされます。
配信トラブルの切り分けでお困りの方は、[お問い合わせ](/contact)からお気軽にご相談ください。専門家がわかりやすくサポートいたします。