メールのバウンスとは？読み方と主なエラーコードの意味

バウンスとは何か、そしてそれが起こる2つの瞬間

この言葉は紙の郵便から借りてきたものであり、それは誤ったイメージです。何かが送り返されてくるわけではありません。メッセージはサーバーからサーバーへと手渡されていき、それを抱えたまま処分できなくなった最後のサーバーが、古いメッセージについての新しいメッセージをあなた宛てに書き、代わりにそれを送ってくるのです。知ることができるのはそのレポートに書かれていることだけであり、レポートの質は、それを書いた機械の質を超えることはありません。

それが作られる瞬間には、まったく異なる2種類があり、その違いを見分けることこそが診断の大部分を占めます。また、あなたの立場からは失敗のように見えて、実際にはそうではない結果も2つあります。

つまり「バウンスした」という言葉は、2つのことを指しています。1つは自分のソフトウェアが見せてくれたエラーであり、もう1つは見知らぬ相手の機械があなたに書いた手紙であって、読むべきレポートがあるのは後者だけです。このガイドの残りは、すべてそのレポートについての話です。

本当の理由がどこにあるか

配信レポートは3つの部分からなるメッセージであり、その形式はRFC 3464以来変わっていません。第1部は、人間に向けて、自分に一番近い機械が書いたお詫びです。第2部は機械が読み取るためのブロックであり、事実が書かれているのはここだけです。第3部は元のメッセージそのもの、あるいはそのヘッダーだけであり、どのメッセージが失敗したのかを判別できるようになっています。

From: Mail Delivery System <MAILER-DAEMON@mail.example.org>
To: <you@example.org>
Subject: Undelivered Mail Returned to Sender
Content-Type: multipart/report; report-type=delivery-status;
        boundary="B7F21C4"

--B7F21C4
Content-Type: text/plain; charset=us-ascii

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients.

--B7F21C4
Content-Type: message/delivery-status

Reporting-MTA: dns; mail.example.org
Arrival-Date: Tue,  8 Sep 2026 10:14:02 +0000

Final-Recipient: rfc822; sales@example.com
Action: failed
Status: 5.1.1
Remote-MTA: dns; mx.example.com
Diagnostic-Code: smtp; 550 5.1.1 <sales@example.com>: Recipient
        address rejected: User unknown in virtual mailbox table

--B7F21C4
Content-Type: text/rfc822-headers

中央の部分は、この順番で読みます。

Final-Recipient:

どのアドレスが失敗したかです。1通のレポートには宛先ごとにブロックが含まれることがあり、複数の相手に送ったメッセージでは、これがどの相手についてのものかを見分ける手がかりになります — そして他の相手には、届いている可能性も十分あります。

Action:

failedはバウンスです。delayedは、サーバーがまだ試みている最中で何もあきらめていないという警告であり、あとから「うまくいった」という2通目のレポートが届くこともあります。relayedとdeliveredはそもそも失敗ではなく、失敗と読み違えやすいので注意が必要です。

Status:

拡張ステータスコードです — 3つの数字からなり、あなたではなくソフトウェアに読ませることを想定しています。プロバイダ同士を比較できるのはこの部分であり、自由記述の文ではそうはいきません。

Diagnostic-Code:

重要なのはこの行です。相手側のサーバー自身の回答が一字一句そのまま引用されており、応答コードと、その管理者が書いた自由な文がここに含まれています。これより上にあるものはすべて又聞きであり、これだけが原文です。

Remote-MTA:

それを述べたホストです。失敗が経路に関するものであるときは、一度目を通す価値があります。見覚えのないホスト名は、たいてい、そのドメイン宛てのメールが想定と違う場所へ向かっていること、あるいはかつて向かっていた場所へ向かっていることを意味します。

レポートの一番上にある文は証拠にはなりません。自分の送信サーバーが、ただ中継しているだけの失敗について、そのソフトウェアにたまたま組み込まれている文言で書いたものだからです。まったく同じお詫びの文が、まったく無関係な2つのDiagnostic-Code:行の上に載ることもあり、だからこそ上から読んだバウンスは読み違えられがちなのです。

2つの数字と、決め手になる1桁

拒否は次のように書かれており、スペースでつながれた3つの別々の要素からなります。

550 5.1.1 <sales@example.com>: Recipient address rejected: User unknown

550は応答コードです。3桁の数字で、SMTP自身がRFC 5321で定義しており、プロトコルが次にどう動くかを決めるために必要とする部分です。5.1.1はRFC 3463による拡張ステータスコードで、3桁では表現しきれなかったために追加されました。それより後ろはすべて自由記述のテキストであり、そのサーバーを運用している人が書いたもので、何によっても標準化されていません。

どちらの数字も同じ桁から始まっており、その桁こそが判定そのものです。

2番目の数字は分類です — 何がまずかったのかを示します。見たことのないコードに出会ったとき、それが何なのかを最も早く見当づける方法です。

ハードバウンス（hard bounce）

5から始まるものです。アドレスが間違っている、存在しなくなった、あるいはポリシーとして拒否されており、同じメッセージを送り直しても何も変わりません。大量配信者は最初の1回でそのアドレスをリストから外します。そのまま送り続けることが、送信ドメインをあらゆる場所で一斉にスロットリングされる原因になるからです。

ソフトバウンス（soft bounce）

4から始まるものです。満杯のメールボックス、混雑したサーバー、一時的なポリシーによる拒否などです。誰の手も借りずに再試行され、たいていは届きます。それについて知らされるのは、再試行が先に尽きてしまった場合だけです。

どちらの用語も、仕様書には登場しません。どちらも送信業界がその最初の桁を指すために使う略語であり — それでも知っておく価値はあります。今後手にするどの配信到達率ツールも、この言葉でレポートしてくるからです。

実際に出会うコード

IANAが管理するレジストリには何十種類も登録されていますが、日常で出会うのはその十数種類ほどです。以下は、誰もが目にするバウンスのほぼすべてをカバーしています。

この一覧にないコードも存在し、そのすべてに意味がありますが、見たことのないコードに出会ったときは、ほぼ間違いなく.7.です — 誰かのポリシーであり、その内容は横の行に、その人自身の言葉で書かれています。

一時的なアドレスで起こりうること、起こりえないこと

ほとんど何も起こりません — そしてそれをはっきり述べておく価値があります。ここでバウンスだと言われがちなことのうち3つは、実はバウンスではないからです。

「user unknown」は起こりえません

サーバーは公開ドメイン上のあらゆる名前を受理します。anything@grabmail.ioは、誰かが入力する前からすでに有効なアドレスです。照合すべきメールボックスの一覧がそもそも存在しないからです — つまりGrabMailからの5.1.1というものは存在しません。テンプメールの仕組みで、その仕組み全体を扱っています。

有効期限切れはバウンスではありません

メッセージは届いてから5日後に削除されますが、その時点で送信サーバーはとっくの昔に250を受け取っており、やり取りのことなどすっかり忘れています。誰にも通知されないのは、何も失敗していないからです。配信は成功しており、あとになってから削除されただけです。受信箱が保持される期間が、その後半部分を扱うガイドです。

アドレスを拒否するフォームはバウンスではありません

そもそもメールは一切送られていません。サイト側がドメインを一覧と照合し、フォームのほうを拒否したのです。メールサーバーには何も届いておらず、読むべきものもありません。サインアップフォームが使い捨てメールを拒否する理由は、まったく別の問題であり、答えも別に用意されています。

沈黙もまた、バウンスではありません

届くはずのものが届かず、レポートも誰からも送られてこない場合、もし失敗が起きているとすれば、それはあなたには見えない送信側で起きています。届かないメールでは、確認する価値がある順番でその原因を扱っています。

残る本物の拒否はただ1つ、サイズの上限です。サイズを事前に申告する送信サーバーは、1バイトも保存されないうちに、その場で追い返されます。

>>> MAIL FROM:<news@example.com> SIZE=7602176
<<< 552 5.3.4 Message size exceeds fixed limit

サイズを事前に申告しない送信元には、代わりにメッセージの末尾で、バイト数が数え終わったところで同じ答えが返されます。いずれにせよコードは5.3.4であり、何も保存されず、本人には自分のメールシステムを通じて伝わります — これこそが、受け取ってから捨てるのではなく、門前で拒否する理由のすべてです。

この上限を引き上げるプランやヘッダーは存在せず、それ以外のことでバウンスが起こることもありません。受信容量の上限も、レート制限も、誰かがすでにその名前を使っているという理由での拒否もありません。共有ドメインで同じ名前を入力した2人は、単にそのメールボックスを共有することになります。これは配信上の性質ではなく、プライバシー上の性質です。

ドメインをここに向けた直後に起こるバウンス

ドメインをキャッチオールの受信箱に向けるのは、DNSレコード1件だけの作業であり、それが生み出すバウンスのほぼすべては、設定そのものではなく、変更前後の1時間ほどに集中しています。ケースは5つあり、それぞれ見た目が異なります。

1. レコードがまだ存在しない段階。MXもなく、代わりのアドレスレコードもないドメインは、送信者に5.4.4か5.1.2を返します。配信先がどこにもなく、再試行する価値もありません。
2. 変更が伝わっている最中の段階。すでにレコードを引いていた送信者は、TTLが切れるまで古い答えを使い続けます。この期間のバウンスは、Remote-MTA:行に古いホストの名前が載っており、それこそが、設定を間違えた場合との見分け方です。
3. 変更が伝わりきった段階。そのドメイン上のあらゆる名前が受理されるようになり、ここでも「user unknown」は起こらなくなります。優先度10でsmtp.grabmail.ioを指すレコード1件だけがあれば、メールを受け取るために公開すべきものは他に何もありません。
4. そのドメインが以前null MXを公開していた場合。パーキングされたドメインには、「このドメインは一切メールを受け取らない」ことを意味するレコードが設定されていることがよくあります。それをキャッシュしていた送信者は、その後こちらが何を公開していようと、キャッシュが失効するまで5.1.10を返し続けます。
5. そのドメインがメールの送信も行っている場合。送信メールに対する5.7.26は、ここまでの話とは無関係です。それは、メッセージを送った何かを自分のSPFやDMARCがカバーできていないということです。受信専用ガイドは最も厳格なケースを扱っており、送信も行うドメインには、代わりに通常の段階的な移行が必要です。

レコードを確認すれば、誰もバウンスを読む前に、その大半に答えが出ます。

$ dig +short MX yourdomain.com

答えは1行のはずです。優先度、ホスト、そして末尾のドットです。それ以外の結果 — 2行になる、見覚えのないホストが出る、何も返ってこない — は、3分後に届くはずのバウンスを先取りしているにすぎません。自分のドメインをここに向けるが設定の全体であり、メールが届くようになったらなりすましを止める3つのレコードを公開しましょう。

送った覚えのないメッセージへのバウンス

それは普通の失敗レポートとまったく同じ見た目で届き、見たこともないメッセージを、聞いたこともない相手宛てに引用しています。何かに侵入されたわけではありません。誰かが、エンベロープの送信者欄にあなたのアドレスを書き込んでメールを送り、受信サーバーはそれを配信できないと分かる前に受理してしまい、そのあと失敗したメッセージに対して正しいことを行ったのです。レポートを書き、渡されていた送信者宛てに送る、という行動です。その送信者とは、あなたのことです。

これはバックスキャッター（backscatter）と呼ばれる現象で、それが証明することははっきり言っておく価値があります。あなたのメールボックスについては何も証明しません。エンベロープ送信者を偽装するのに、何かへのアクセスは一切必要ありません — やり取りの中に1行を書き込むだけのことです。それをした誰かに必要だったのはあなたのアドレスだけであり、それすら推測されたものかもしれません。

本物のバウンスとの見分けは、次の3点でおよそ10秒でつきます。

• 返送されてきたメッセージが自分のものではない。レポートの第3部には元のメッセージ、あるいは少なくともそのヘッダーが含まれています。書いた覚えがなければ送った覚えもないということであり、レポートの残りはすべて他人の問題についてのものです。
• Received:チェーンが、使ったことのない場所から始まっている。下から上へと読みましょう。一番下の行が実際にメッセージを送り込んだ機械であり、それはあなたのプロバイダではありません。メールヘッダーの読み方では、その向きと、なぜ一番下が正直な端なのかを扱っています。
• 日時が合わない。バックスキャッターは、レポートが届くより何時間も、あるいは何日も前に送られたメッセージについて報告することが多く、それは誰か別の人のキャンペーンをずっと再試行し続けているキューから出てきたものです。

直すべきものも、答えるべきものも何もありません。そのアドレスが自分の所有するドメインのものであれば、SPFとDMARCを公開することが、唯一効果のある形でこれを減らします。受理する前に送信者のポリシーを確認する受信サーバーは、やり取りの最中に偽造を拒否し、誰に対してもレポートを生成しません。受信専用ドメインの3つのレコードは、その最も厳格な形であり、公開するのも群を抜いて簡単です。

共有の公開ドメイン上にある短い名前は、迷惑メールを多く集めるのと同じ理由で、これも多く集めます。推測しやすいからであり、エンベロープ送信者を選ぶ偽造者は、あなた個人を狙っているわけではありません。これは他人についてのノイズであり、迷惑メールと違って、何かを訓練してくれるボタンもありません — 迷惑メール対策のボタンが実際にしていることで、実際に効くボタンについて扱っています。

読み解く順番

1. まずどちらの種類かを見極める。送信した瞬間に自分のメールアプリに出たエラーは拒否です。あとになってMAILER-DAEMONから届いたメッセージはレポートであり、読むべき内容があるのはレポートのほうだけです。
2. 本当に自分が送ったメッセージについてのものか確認する。返送されたコピーは第3部に入っています。自分のものでなければバックスキャッターであり、それ以上見る必要はありません。
3. 生のソースを開く。冒頭のお詫びは自分のサーバーの定型文であって理由ではなく、機械可読のブロックはどこでも初期状態では表示されません。
4. Status:を見つけ、最初の桁を読む。4はまだ再試行中で、いずれ自然に成功するかもしれません。5は最終的なものであり、これ以上何も起こりません。
5. Diagnostic-Code:を読む。これは相手側自身が書いた文であり、あなたを拒否したルールが実際に名指しされている唯一の場所です。
6. 2番目の桁を確認する。.1.はアドレス、.2.はメールボックス、.4.は経路、.7.は誰かのポリシーです。通常はこれだけで、誰の問題なのかが分かります。
7. 誰の問題かに応じて行動する。アドレスの問題は正しいアドレスを手に入れることで、経路の問題はDNSを直すことで、ポリシーの問題はそのポリシーを満たすことで解決します。あるいは、相手に自分たちのログを見てもらうという手もあります — そこには、送られてきたものよりもずっと詳しく、同じ拒否の理由が記録されています。

答えにならないことが2つあります。5のあとに同じメッセージをそのまま送り直せば、同じ拒否が繰り返されるだけであり、何度も行えば送信ドメインのレピュテーションをあらゆる場所で一斉に傷つけます。そして、レポートに返信しても誰にも届きません。それは空のエンベロープ送信者から来ており、そもそもそれこそがあなたに配信できた理由だからです。

質問