メールバウンス率の安全な基準と原因別の改善手順

サーバーから 250 OK が返っていても、メールのバウンス率が急上昇することがあります。配信できたと思っていたのに、二十分後に送信ダッシュボードを見ると失敗率は 8%。さらに、キューに追加した再試行が状況を悪化させているかもしれません。

これは単なる配信の不具合ではなく、送信者レピュテーションがリアルタイムで損なわれている状態です。メールのバウンス率は、ISP が正当な送信者か、購入したデータベースへ大量送信する業者かを判断するうえで重視するシグナルです。Gmail、Outlook、Yahoo は、対策を講じる前に必ず警告してくれるわけではありません。自動化されたしきい値に基づいて処理するため、そこを超えると、失敗した送信だけでなく、何年もメールを開いてきた購読者を含むリスト全体で配信性が低下する可能性があります。

ここでは、各バウンスの意味、確認すべき正確な SMTP コード、問題がプライマリドメインに及ぶ前に被害を抑える調査の順序を説明します。メールのバウンス率と送信者全体の信頼性との関係については、メール送信者レピュテーションのシグナルもご覧ください。

メールバウンスの三つの種類

メールのバウンス率とは、送信したメッセージのうち、受信サーバーに拒否された割合です。「バウンス」は一種類の障害ではありません。三つの種類があり、それぞれ SMTP コードも対処方法も異なります。受信サーバーが返すコードは RFC 5321 で標準化されています。三種類を同じように扱うと、リスト管理の問題がインフラの危機に発展しかねません。

ハードバウンス - 恒久的な失敗

SMTP コード: 5xx - 一般的には 550 5.1.1 User Unknown または 550 5.1.2 Bad Destination Mailbox Address

アドレスが存在しない、ドメインの有効期限が切れている、あるいは相手が三年前に退職しているといった状態です。ハードバウンスは再試行しても解決しません。最初の失敗後も送信を続けると、リストを適切に管理していないというシグナルを ISP に送ることになります。正当な送信者は、無効なアドレスへ繰り返し送信しないためです。

対処: 直ちに、かつ恒久的に配信対象から除外します。将来の再エンゲージメント用に残さず、アクティブなリストから削除してください。

ソフトバウンス - 一時的な失敗

SMTP コード: 4xx - 一般的には 421 Service not available、450 Mailbox unavailable、または 452 Insufficient storage

アドレスは有効ですが、メールボックスの容量不足、受信サーバーの停止、送信速度の制限など、一時的な理由で配信に失敗しています。多くの ESP（Amazon SES、SendGrid、Postmark）は 24-72 時間、自動的に再試行します。その期間を過ぎても失敗する場合は、ハードバウンスと同様に扱います。

対処: 再試行は ESP に任せます。72 時間を超えて続く場合は、配信対象から除外してください。

ブロックバウンス - ポリシーによる拒否

SMTP コード: 5xx - 一般的には 550 5.7.1、554 5.7.1、Google の 550 5.7.26、または Microsoft の 550 5.7.515

アドレスは存在します。それでも受信サーバーがメールを拒否したのは、宛先ではなく送信者側に理由があるためです。IP がブロックリストに登録されている、SPF レコードが壊れている、DKIM 署名の検証に失敗した、といった可能性があります。これはインフラの緊急事態です。連絡先を配信対象から外しても解決しません。

対処: 宛先リストは変更せず、先に送信インフラを修正します。

この表に含まれない四つ目の障害が、サイレントフィルタリングです。Gmail は 250 OK でメールを受け付けた後、迷惑メールへ直接振り分けたり、破棄したりする場合があります。これはメールのバウンス率には一切反映されず、代わりに開封率の急落として現れることがあります。バウンス率が良好なのにエンゲージメントが大きく低下している場合は、サイレントスパムフィルタリングの兆候かもしれません。

正常なメールバウンス率はどのくらい？

正常なメールバウンス率は一般に 2% 未満で、0.5% 未満なら健全と考えられます。重要なのは業界平均よりも、ISP の速度制限や ESP アカウントの停止につながり得る自動判定のしきい値です。一度超えただけでも監視が強まり、放置すれば停止措置を受ける可能性があります。

• 0.5% 未満 - 最適。リストが整理され、インフラも安定しています。ISP から信頼されやすい状態なので、この範囲の維持を目指します。
• 0.5%-2.0% - 許容範囲。古い B2B データベースや送信頻度の低い送信者では珍しくありません。直ちに危険とは限りませんが、急上昇があれば問題が重なる前に調査してください。
• 2.0%-5.0% - 危険域。ISP がメールの速度制限やフィルタリングを始める可能性があります。長年キャンペーンを開いてきた購読者でも、受信トレイへの到達率が低下しかねません。
• 5.0% 超 - 重大。一括スパム送信と似たパターンに見える可能性があります。Amazon SES は共有 IP プールのレピュテーションを守るため、この水準でアカウント停止を含む措置を取ることがあります。

同じくらい重要な指標が、スパム苦情率です。Google の 2024 年の送信者向け要件では、0.3%、つまり苦情 3 件 / 送信 1,000 通を、送信者が到達させるべきでない水準としています。これを超えると、メールバウンス率が低くても、Gmail でフィルタリングやゲートウェイ拒否が強まる可能性があります。

メールバウンス率が急上昇する根本原因

連絡先を配信対象から除外する前に、送信ログのエラーコードを確認してください。どこに問題があるかを具体的に示してくれます。メールバウンス率の急上昇は、多くの場合三つの原因に分けられ、それぞれ異なる対応が必要です。すべてをリスト管理の問題として扱うと、一週間かけてリストを整理しても原因を解消できないことがあります。

リストの劣化と不正確なデータ

ログに 550 5.1.1 User Unknown が大量にあるなら、アドレスデータが古いか誤っています。概算では、メールリストは毎月およそ 2% ずつ有効性を失います。転職、企業買収、ドメインの失効などが起きるためです。二年前に整理したリストでも、現在は有効なアドレスのかなりの部分を失っている可能性があります。

gmal.com、yahoomail.com、hotmal.com といった入力ミスも状況を悪化させます。登録フォームを通過し、送信するまで気付かれないからです。購入したリストは、大きなリスクを含むものと考えてください。購入リストには、一括送信者を検出するためのスパムトラップが含まれていることがあり、一件への送信でも Spamhaus への登録につながる可能性があります。

認証の失敗

Google の 550 5.7.26 または Microsoft の 550 5.7.515 が表示される場合、メールバウンス率の上昇は宛先アドレスではなく、送信者の識別確認に失敗したことが原因かもしれません。次の三点を確認します。

• SPF: 送信 IP を許可していますか？誤って 10 回の DNS ルックアップ上限を超えていませんか？
• DKIM: 暗号署名は有効で、From ドメインと整合していますか？
• DMARC: SPF または DKIM が失敗している状態で、ポリシーを p=reject にしていませんか？

最近設定が壊れた場合や、最初から設定する場合は、SPF レコード設定ガイドをご覧ください。ブロックバウンスが起きる前に include チェーンを調べ、ルックアップ数の超過を見つける方法を含め、設定全体を説明しています。

IP またはドメインレピュテーションによるブロック

554 5.7.1 Service unavailable; Client host [x.x.x.x] blocked using Spamhaus と表示されるなら、送信 IP が Spamhaus によりブロックされています。これは宛先リストではなく、IP の過去の使用状況に関する問題です。ESP の共有 IP プールでは、別の送信者の行動がプール全体へ影響した可能性もあります。

IP ブロックは解消できる場合がありますが、IP の変更だけでメールバウンス率がすぐ改善するとは限りません。ドメインレピュテーションは IP を変更しても引き継がれるため、回復がより困難です。ドメインレピュテーションに起因するブロックバウンスからの回復には、IP の交換だけでなく、数週間にわたる低ボリュームで健全な送信が必要になることがあります。

トリアージ手順：この順番で修正

メールバウンス率が急上昇したときは、修正内容と同じくらい順番が重要です。手順を飛ばすと、連絡先を除外して一見解決したように見えても、根本原因が次回の送信で新たなバウンスを生み続けます。次の順番で進めてください。

手順 1：ハードバウンスを直ちに削除

バウンスレポートをエクスポートし、「User Unknown」または「Bad Destination」を伴う 5xx コードをすべて抽出します。該当するハードバウンスをアクティブなリストから直ちに削除してください。将来の再エンゲージメントキャンペーン用に休止させるだけでは不十分です。無効なアドレスへの送信は、そのたびに受信側 ISP への否定的なデータとなり、蓄積していきます。

手順 2：認証レコードを監査

次のキャンペーンを送る前に、認証設定を確認します。SPF レコードが一つ壊れただけでも、主要なプロバイダーではアクティブリスト全体への送信がブロックバウンスになる可能性があります。

# Check your SPF record - count each DNS lookup mechanism (must stay at or under 10)
dig txt yourdomain.com +short

# Check your DMARC policy - p=reject blocks everything if SPF/DKIM are failing
dig txt _dmarc.yourdomain.com +short

# Check your DKIM selector - replace "selector1" with your actual selector name
dig txt selector1._domainkey.yourdomain.com +short

複数のドメインで認証を管理している場合、SPF のルックアップ上限は見落としやすい問題です。単独では正常なドメインもあれば、ネストされた include: チェーンを継承し、気付かないうちに回数が 12 へ増えるドメインもあります。その結果、Gmail がそのドメインからのメールを SPF エラーとして全面的にブロックする可能性があります。

手順 3：ブロックリストを確認

送信 IP を複数の RBL に対応するチェッカーで調べます。MXToolbox でも構いません。ブロックリストへの登録によって、メールバウンス率が一晩で膨らむことがあります。主要プロバイダーでの配信に実際に影響し得るリストは次のとおりです。

• Spamhaus SBL/XBL/ZEN: Tier 1。登録されると Gmail、Outlook、Yahoo への配信に深刻な影響が出る可能性があります。送信を停止し、原因を確認してから速やかに削除を申請してください。
• SpamCop: Tier 1。同様に大きく影響する場合があります。登録理由によっては、数日間の健全な送信後に自動解除されることもあります。
• UCEPROTECT Level 3: 多くの主要プロバイダーは直接利用していないとみられます。監視は続けつつ、配信問題との関連が確認できた原因を優先してください。

手順 4：送信ドメインを分離

マーケティングの一括送信後にバウンスが急増した場合は、原因を特定するまでプライマリの @company.com ドメインからの送信を止めます。@newsletters.company.com のような専用サブドメインを用意し、独自の SPF と DKIM レコードを設定してください。そのレピュテーションが損なわれても、請求書、サポートチケット、契約書はプライマリドメインから送信を続けやすくなります。ただし、共通のレピュテーションシグナルがあるため、完全な分離が保証されるわけではありません。

TrekMail がインフラ面で行うこと

メールバウンス率の問題の多くは、送信者が管理すべき不正確なリストデータと、ホスティング設定が関係する認証インフラの不備に分かれます。TrekMail はインフラ面を支援し、認証に起因するブロックバウンスが繰り返し発生する可能性を抑えます。

従来の方法: 25 の顧客ドメインにわたり、SPF、DKIM、DMARC を手作業で管理します。一つの不正な include: チェーンで、ドメイン全体の SPF が機能しなくなります。DNS ログを三時間調べた末に、古いレコード一つがルックアップ数を 10 回の上限より増やし、ブロックバウンスを起こしていたと判明します。

TrekMail の方法: 各ドメインの追加時に、SPF/DKIM/DMARC ウィザードがレコードを生成して検証します。認証は設定時に処理されるため、ルックアップ数を手作業で数えたり、11pm に TXT レコードの入力ミスを直したりする必要はありません。

複数の顧客を管理する代理店にとって、BYO SMTP は追加の分離層になります。顧客は TrekMail で IMAP メールボックスをホスティングし、送信には自分の Amazon SES または SendGrid アカウントを接続します。ある顧客が送信者レピュテーションを損ない、アカウントを停止された場合でも、API キーを交換でき、メールボックスには触れずに済みます。送信アカウントを別途復旧している間も、ホスティングインフラは維持されます。

Starter プランは $3.50/month で、マネージド SMTP を含む 50 ドメインに対応します。クレジットカード不要の Nano プランは、BYO SMTP で 10 ドメインに対応します。すでに送信サービスを利用していて、ホスティングと適切な認証レイヤーだけが必要なら、無料で始められます。TrekMail のプランを比較し、最新の条件を確認して、ご自身の構成に合うものをお選びください。

メールバウンス率を 0.5% 未満に保つ三つの習慣

目の前の問題を止めた後は、次の三つの運用習慣により、継続的な手作業を増やさずにメールバウンス率を安全な範囲に保ちやすくなります。どれも初期設定後に大きな負担はかかりません。

登録時のリアルタイム検証

送信時になって偽のアドレスを発見するのでは遅すぎます。登録フォームに ZeroBounce、NeverBounce、または同様の検証 API を導入してください。これらは、メールバウンス率上昇の主因となりやすい入力ミス、使い捨てアドレス、info@、admin@、postmaster@ などの役割アカウントを、リストへの登録前に検出できます。検証一回の料金は通常、一セント未満です。一方、ESP アカウントが停止されると手動審査が必要になり、数日間にわたって送信できないことがあります。

非アクティブな購読者の配信終了

18 カ月前に放棄されたメールアドレスは、次の送信でバウンスするかもしれません。購読者が 180 日間メールを開いていないことはリスクの兆候ですが、開封データには限界があるため、非アクティブである確実な証拠ではありません。再エンゲージメントメールを一通送り、反応がなければ先回りして購読を解除します。アドレスが無効になり、将来のキャンペーンでバウンス率に加算されるまで待つよりも、一般には低コストです。

マーケティング用サブドメインの分離

可能な限り、プライマリの企業ドメインから一括キャンペーンを送らないでください。ニュースレターのメールバウンス率が、CEO の契約書送信に使うドメインのレピュテーションにも影響する可能性があります。@marketing.company.com に独自の DNS レコードを設定します。マーケティング用サブドメインのレピュテーションが損なわれても、主要業務を分離しやすくなりますが、プロバイダーが共通のドメインシグナルを参照する場合もあります。ドメインレピュテーションが IP レピュテーションより回復しにくい理由については、メールドメインのレピュテーションと低下する理由をご覧ください。

症状ではなく根本原因を修正する

メールバウンス率の高さはシグナルであり、問題そのものではありません。ハードバウンスはリストデータの質に、ブロックバウンスはインフラの不備に関係します。両方を同じように扱っても、どちらも解決せず、次の急上昇を先送りするだけかもしれません。

まずリストを整理し、次に認証を監査して、その後にブロックリストを確認します。次の問題が起きた後ではなく、次回のキャンペーン前にマーケティング送信をプライマリドメインから分離してください。

複数ドメインの認証を適切に保ち、メールボックスに触れず送信アカウントを交換できるメールインフラをお探しなら、TrekMail はその用途に合わせて設計されています。Nano プランはクレジットカード不要。Starter は $3.50/month、各有料プランには 14 日間の無料トライアルがあります。