
**この記事でわかること**

- 「届かない（バウンス）」と「届くが遅い（遅延）」はまったく別の問題であること
- 遅延の代表的な原因 5 つと、それぞれの見分け方
- 原因別のチェック手順を一覧表で整理
- 自社で確認できる範囲と、専門家に相談すべき境目

## まず「届かない」と「届くが遅い」を切り分ける

「メールが遅い」という相談で最初にやるべきは、症状の切り分けです。次の 2 つはまったく別の問題で、対処も変わります。

- **バウンス（届かない）**: 送ったメールがエラーで戻ってくる、または相手に永久に届かない状態。送信者に自動返信（バウンスメッセージ）が返ることが多い
- **遅延（届くが遅い）**: メール自体は最終的に届くが、数分〜数時間など想定より時間がかかる状態。エラーは出ないため気付きにくい

![バウンスと遅延の切り分け](/blog/mail-delay-causes-check/bounce-vs-delay.svg)

届かない（バウンス）側の判断は、戻ってきたエラーコードを読むのが近道です。コード別の意味は [バウンスメールの分類と読み方](/blog/email-bounce-classification) と [SMTP 応答コード一覧](/blog/smtp-reply-codes-reference) で整理しています。ここからは、エラーは出ないのに遅い「遅延」に絞って原因を見ていきます。

## 遅延が起きる代表的な原因 5 つ

エラーを伴わない遅延は、主に次の 5 つのどれかです。多くは送信側と受信側の「間」で起きるため、片方のログだけ見ても気付きにくいのが特徴です。

### 1. グレーリスティング（一時的な受信拒否）

受信側サーバーが、初めて見る送信元からのメールを一度わざと「あとでもう一度送ってください」と返す仕組みです。正規のメールサーバーは時間を置いて再送するため最終的には届きますが、その再送までの待ち時間ぶん遅れます。新規取引先への初回メールが数分〜数十分遅れるのは、これが典型です。

仕組みと、グレーリスティングで返る 451 系応答の対処は [グレーリスティングと 451 応答の対処](/blog/greylisting-451-fix) で詳しく解説しています。

### 2. 送信側のキュー滞留

自社のメールサーバーや配信サービスの「送信待ち行列（キュー）」に大量のメールが溜まり、順番待ちで送出が遅れる状態です。メルマガ一斉配信の直後や、サーバー負荷が高い時間帯に起きやすくなります。

### 3. DNS 応答の遅延

受信側がメールを受け取る際、送信元ドメインの SPF / DKIM / DMARC レコードを DNS（ドメインの住所録のような仕組み）に問い合わせます。この DNS 応答が遅い、またはタイムアウトしかけていると、認証処理が長引いて配送全体が遅れます。

### 4. 大量送信によるレート制限

短時間に大量のメールを送ると、受信側 ISP が「一度に受け取る量」を絞り、残りを「あとで」と返すことがあります。これは 421 系の一時応答で起きることが多く、[421／4xx 系一時障害の対処](/blog/smtp-421-470-fix) で扱っています。

### 5. スパム判定に伴う遅延配送

受信側がメールを「怪しい」と判定したとき、即拒否ではなく「いったん保留してから配送する」挙動をとる場合があります。認証（SPF / DKIM / DMARC）が弱いドメインほどこの保留に入りやすくなります。認証の基礎は [DMARC とは何か](/blog/what-is-dmarc) を参照してください。

## 原因別チェック手順の一覧表

「うちはどれか」を絞り込むための早見表です。上から順に確認すると切り分けが進みます。

![遅延の原因を切り分けるフロー](/blog/mail-delay-causes-check/delay-causes-flow.svg)

| 疑う原因 | 主な症状 | 確認すること |
|---|---|---|
| グレーリスティング | 新規宛先の初回だけ遅い／再送後に届く | 受信側のログで一時拒否（451 系）の有無 |
| キュー滞留 | 一斉配信の直後だけ全体が遅い | 送信側サーバー／配信サービスのキュー件数 |
| DNS 応答遅延 | 宛先を問わず遅い | SPF / DKIM / DMARC レコードの応答状況 |
| レート制限 | 大量送信時に一部が後回し | 送信ログの 421 系一時応答の有無 |
| スパム判定の遅延配送 | 特定の受信側でだけ遅い | 認証（SPF/DKIM/DMARC）の整合 |

どの原因でも、最終的な手がかりはメールの「ヘッダ」に残った各サーバーの通過時刻です。ヘッダの読み方は [メールヘッダの読み方ガイド](/blog/email-headers-reading-guide) を参照してください。

## 自社で確認する手順と、相談すべき境目

Web 担当者・情シスが自社で確認できるのは、おおむね次までです。

1. 遅れたメールの **ヘッダの `Received:` 行**を上から下に見て、どのサーバー間で時間が空いたかを特定する
2. 新規宛先だけ遅いなら **グレーリスティング**を、一斉配信時だけ遅いなら **キュー滞留／レート制限**を疑う
3. 宛先を問わず遅いなら、自社ドメインの **SPF / DKIM / DMARC** が正常かを [無料診断](/diagnose) で確認する

これらで原因が絞れない、あるいは「ヘッダの場所が分からない」段階であれば、専門家への相談を推奨します。また、症状が遅延ではなく「届くメールと届かないメールがある」場合は、遅延ではなくバウンスの可能性が高いので、[会社のメールが届かない原因の整理](/blog/company-mail-not-delivered-causes) もあわせて確認してください。

## よくある質問

**Q. メールが数分遅れるのは異常ですか。**
A. 必ずしも異常ではありません。グレーリスティングや混雑時の再送で数分の遅れが出るのは正常な挙動の範囲です。問題は、毎回・全宛先で慢性的に遅い場合や、業務に支障が出るほど遅い場合です。

**Q. 遅延の原因はどこを見れば確実に分かりますか。**
A. メールヘッダの `Received:` 行が最も確実です。各サーバーを通過した時刻が記録されており、どの区間で時間が空いたかを追えます。

**Q. 認証設定（SPF/DKIM/DMARC）が遅延に関係するのですか。**
A. 関係します。認証が弱いと受信側がメールを保留しやすくなり、結果として配送が遅れることがあります。まずは認証の状態を確認するのが近道です。

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

[無料のドメイン診断](/diagnose) では、メール認証（SPF / DKIM / DMARC）と SSL の設定状況を 30 秒でチェックできます。遅延の原因が「経路（認証）」側にあるかどうかの一次切り分けに使えます。

設定状況がわからない方や、ヘッダの読み方から相談したい方は、[お問い合わせフォーム](/contact) からお気軽にご相談ください。専門家がわかりやすくサポートいたします。
