この記事では `421 4.7.0` の意味、`4xx` と `5xx` の違い、発生パターン別の対処、永続化時のチェックポイントを整理します。

## エラーコード `421 4.7.0` の正体

SMTP のステータスコードは 3 桁で表現されます（RFC 5321）。`421` は「Service not available, closing transmission channel（サービス利用不可、接続終了）」を意味し、続く拡張ステータス `4.7.0` は「Security or Policy Status（セキュリティまたはポリシー上の一時的問題）」を表します。

ポイントは先頭の数字です。

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

つまり `421 4.7.0` は「いま受け付けないが、後でもう一度試せば通る可能性がある」という応答です。きちんと実装された送信 MTA（Postfix / Exim / Microsoft 365 / Google Workspace 等）は、自動的に再試行（典型的には 5 分後 → 10 分後 → 30 分後 → … と指数的バックオフ）して配信を完遂します。

メール認証の基礎は[DMARC とは何か](/blog/what-is-dmarc)で整理しています。本記事は認証通過後の「受信側で一時的に弾かれる」パターンに絞ります。

![4xx と 5xx の違い](/blog/smtp-421-470-fix/4xx-vs-5xx.svg)

## 主な発生パターン 4 種

### パターン 1: グレーリスティング

スパム対策として、初めて見る送信元 IP / 送信者の組み合わせを **意図的に一度拒否** し、再送してきた相手だけを正規配信する仕組みです。スパム送信ツールは再送せず諦めることが多いため、簡易な選別として有効です。

挙動：初回 `421 4.7.0` → 数分〜数十分後の再送で配信成功。

対処：基本は **送信側の MTA に任せて待つだけ**。緊急の業務メールで遅延が許容できない場合は、受信側 IT 部門にホワイトリスト登録を依頼します。

### パターン 2: 受信側のレート制限

短時間に大量のメールを同一送信元から受け取ると、受信側が一時的に拒否することがあります。配信サービスからのキャンペーン、メルマガ一斉送信、業務システムからの自動通知が集中したときに発生します。

対処：送信レートを抑制（例: 毎秒 10 通以下）し、配信時間帯を分散。配信サービスを使っている場合は、サービス側のスロットリング設定を調整します。

### パターン 3: 受信サーバーの一時的負荷

受信側のメールサーバが高負荷状態（メンテナンス・トラフィック急増・ストレージ逼迫）にあると、新規接続を一時的に拒否することがあります。Microsoft 365 や Google Workspace でも、メンテナンス時間帯にこの応答が増えるケースが報告されています。

対処：送信側のリトライに任せれば数十分〜数時間で解消することがほとんど。長時間続く場合は、受信側ドメインのステータスページ（[Microsoft 365 Status](https://status.office.com/) / [Google Workspace Status](https://www.google.com/appsstatus)）を確認します。

### パターン 4: 送信元 IP の評価が「保留」

新しく立てた送信サーバや、最近 IP が変わった配信サービスからの送信は、受信側のレピュテーション（信頼度）が定まっていない期間があります。この間は安全側に倒して `421 4.7.0` を返す実装が一部存在します。

対処：送信ボリュームを段階的に増やす（IP ウォームアップ）。あわせて SPF / DKIM / DMARC を確実に整え、評価を上げる材料を揃えます。

## 切り分けと対処の手順

### Step 1: 4xx か 5xx かを確認

バウンスメールや送信側ログから、ステータスコードを正確に取得します。`421` ではなく `521` や `554` だった場合は永続拒否であり、対処方針が変わります。

### Step 2: 送信側の再送状況を確認

送信側の MTA ログ（Postfix なら `/var/log/mail.log`、Microsoft 365 なら Exchange Admin Center のメッセージトレース）で、**再送が行われているか・最終的に配信成功したか** を確認します。多くの場合、リトライで自動的に解決します。

### Step 3: 配信ログから永続化していないか判定

数時間〜1 日経っても再送が成功せず、最終的に `5xx` に変わった場合、根本原因が一時的ではなく永続的なものに変化している可能性があります。次節を参照してください。

![一時拒否から永続化までのタイムライン](/blog/smtp-421-470-fix/timeline.svg)

## 永続化したときに疑うべきこと

`421 4.7.0` が継続した結果、最終的に配信失敗（`5xx` への変化、または送信側のリトライ上限到達）に至る場合は、以下を順に確認します。

1. **送信元 IP がブロックリスト掲載されていないか**
   Spamhaus / Barracuda / SURBL などの公開 RBL を確認
2. **SPF / DKIM / DMARC の認証不備**
   特に DMARC `p=reject` 環境では、認証不一致で `5.7.x` に転落しやすい。[SPF 設定ガイド](/blog/spf-setup-guide)と[DKIM 検証手順](/blog/dkim-verification)を参照
3. **送信元ドメインのレピュテーション低下**
   Google Postmaster Tools / Microsoft SNDS で評価を確認
4. **受信側のブロックリスト登録**
   過去の苦情報告などで、受信側が独自にブロックしているケース

似たエラーコードとの混同にも注意してください。

- `421 4.4.5`: 受信サーバの内部一時エラー
- `451 4.7.1`: 受信側ポリシーによる一時拒否
- `554 5.7.1`: スパム判定による永続拒否
- `550 5.7.26`: 認証失敗。詳しくは[Gmail 550 5.7.26 の対処](/blog/gmail-550-5726-fix)
- `550 5.4.1`: 受信者ポリシー拒否。詳しくは[NDR 550 5.4.1 の対処](/blog/ndr-550-541-fix)

`5.5.2` 系（容量超過・サイズ超過）も混同されがちです。詳細は[Gmail 5.5.2 の対処](/blog/gmail-552-quota-fix)を参照してください。

### 予防のためにできること

一時拒否を減らすには、送信側の運用を整えるのが効果的です。大量配信は時間帯を分散し毎秒数通以下に抑える、配信サービスのスロットリング設定を見直す、SPF / DKIM / DMARC を確実に設定する、不達アドレスを定期的にクリーンアップする、の 4 点が効きます。

## まとめ

- `421 4.7.0` は一時拒否。多くは送信側の自動リトライで解決する
- 発生パターンはグレーリスティング / レート制限 / 受信側負荷 / IP 評価保留の 4 系統
- 永続化したらブロックリスト・認証設定・レピュテーションを順に確認

## 自社の状況を確認してみませんか

設定状況がわからない方は、無料の[ドメイン診断](/diagnose)で現状をチェックできます。
DMARC・SPF・DKIM・SSL の状態が数十秒でレポートされます。
判断に迷う場合は[お問い合わせ](/contact)からご相談ください。専門家がわかりやすくサポートいたします。