到達率 · 2026年9月21日

バウンスと苦情：到達率を本当に損なうのはどちらか

バウンスは技術的な失敗ですが、苦情はレピュテーションを致命的に損ないます。送信レピュテーションを保ち、メールを受信トレイに届け続けるための両者への対処方法を解説します。

根本的な違い

バウンスは、受信側サーバーがメールを拒否する技術的な失敗です。苦情は、受信者がメールを迷惑メールとして報告するユーザーの操作です。バウンス率の高さはリストの衛生管理が不十分であることを示し、苦情は同意や関連性の欠如を示します。苦情は、コンテンツが望まれていないことをISPに直接伝えるシグナルであるため、レピュテーションへの打撃ははるかに大きく、ブラックリストへの登録が早まり、IPレンジ全体で配信率が低下します。

バウンスを理解する

バウンスは、メールを受信者のメールボックスに配信できなかった場合に発生します。エンジニアリングの観点では、配信試行の失敗です。バウンスはハードバウンスとソフトバウンスの2種類に分類されます。

ハードバウンス

ハードバウンスは恒久的な失敗です。メールアドレスが存在しない、ドメインが無効である、または受信側サーバーがIPを恒久的にブロックしている、といった状態です。これらのアドレスへの送信は直ちに停止する必要があります。ハードバウンスしたアドレスへの送信を続けることは、古いリストや購入したリストを使っていることを示す主要なシグナルとしてISPに受け取られます。これは迷惑な一斉送信メールの典型的な特徴です。

ハードバウンスでよく見られるSMTPエラーコードは次のとおりです。

550: User unknown（ユーザー不明）
554: Transaction failed（トランザクション失敗）
550 5.1.1: Bad destination mailbox address（宛先メールボックスのアドレスが不正）

ソフトバウンス

ソフトバウンスは一時的な失敗です。メールボックスが容量いっぱいである、サーバーが一時的に停止している、メッセージサイズが上限を超えている、といった原因が考えられます。これらは連絡先をすぐに削除する理由にはなりませんが、ソフトバウンスが繰り返される場合は、最終的にハードバウンスとして扱うべきです。

ソフトバウンスでよく見られるSMTPエラーコードは次のとおりです。

421: Service not available, closing transmission channel（サービス利用不可、送信チャネルを閉じます）
450: Requested mail action not taken: mailbox unavailable（要求されたメール処理は実行されませんでした：メールボックス利用不可）
451: Requested action aborted: local error in processing（要求された処理は中止されました：処理中のローカルエラー）

苦情を理解する

苦情は、ユーザーがメールクライアントで「迷惑メールとして報告」や「迷惑メールに移動」をクリックしたときに発生します。バウンスとは異なり、メール自体はメールボックスに正常に配信されています。ここでの失敗は技術的なものではなく、行動に関するものです。

GmailやOutlookなどのISP（インターネットサービスプロバイダー）は、総送信量に対する苦情の割合を追跡しています。苦情率がごく低いしきい値（多くの場合0.1%程度）を超えると、レピュテーションが低下します。影響は実施中の特定のキャンペーンにとどまらず、そのIPまたはドメインから送信されるすべてのメールに及びます。

到達率の階層構造

プロバイダーによる受け付け、配信、受信トレイへの到達という3つの異なる概念を区別することが重要です。

プロバイダーによる受け付け：受信側サーバーが接続とメッセージを受け付けます。ここで失敗するとバウンスになります。
配信：メッセージが受信者のメールストアに正常に格納されます。
受信トレイへの到達：メッセージが迷惑メールフォルダではなく受信トレイに振り分けられます。苦情はこの段階に直接影響します。

苦情率が高い場合、メールは「配信済み」（サーバーに受け付けられた状態）にはなっても、個々のユーザーが苦情を送ったかどうかに関係なく、すべてのユーザーで迷惑メールフォルダに直行する可能性があります。

対応の仕組みを設計する

インシデント対応を担うエンジニアとしては、手作業でのクリーンアップに頼るわけにはいきません。配信イベントを処理する自動化されたパイプラインが必要です。

サプレッションリスト

本格的な送信環境には、必ずサプレッションリストが必要です。これは、二度とメールを送ってはならないアドレスのデータベースです。Webhook経由でbounceまたはcomplaintイベントを受け取ったら、システムはそのアドレスを直ちにサプレッションリストに追加する必要があります。

SendHQを使っている場合、こうしたサプレッションはAPIレベルで処理されます。そのため、アプリケーションのロジックがサプレッション対象のアドレスに送信しようとしても、実際に送出される前にシステムがブロックします。

Webhookの処理

Webhookハンドラーは、おおよそ次のような形になります（Node.jsによる概念的な例）。

app.post('/webhooks/email', async (req, res) => { const event = req.body; switch (event.type) { case 'bounce': if (event.detail.category === 'permanent') { await suppressionService.add(event.detail.email, 'hard_bounce'); } break; case 'complaint': await suppressionService.add(event.detail.email, 'spam_complaint'); break; case 'delivered': await trackingService.markAsDelivered(event.detail.messageId); break; } res.sendStatus(200); });

AIエージェント特有の問題：冪等性と承認

AIエージェントにメール送信を任せると、到達率の面で深刻な事態が起こるリスクが高まります。ループに陥ったエージェントが、1人のユーザーに同じメールを誤って1,000通送信し、苦情が殺到するおそれがあります。

冪等キー

重複送信を防ぐため、必ず冪等キーを使用してください。これにより、エージェントがタイムアウトによってリクエストを再試行しても、メールは1回しか送信されません。

ヒューマン・イン・ザ・ループ（HITL）

重要度の高い連絡を送るエージェントには、承認キューを導入してください。エージェントが下書きを作成し、最終的なAPI呼び出しは人間が実行します。これにより、エージェントが無関係な内容を大規模なリストに送信して苦情率を急上昇させる「ハルシネーションによるスパム」の事態を防げます。

インフラとコストのトレードオフ

プロバイダー選びでは、使いやすさとコストのトレードオフがつきものです。規模が大きくなると、大量送信時の料金差は歴然としています。

Amazon SESの料金ページによると、SESのà-la-carte料金は1,000通あたり0.10 USDです。50,000通の送信量なら、約5 USDになります。一方、Postmarkの料金では、50,000通でおよそ66 USDかかります（10,000通分の基本料金15 USDに加え、超過分が1,000通あたり1.20〜1.80 USD）。

その他の選択肢は次のとおりです。

Resend：無料プランは月3,000通（1日100通まで）です。Proは月額20 USDで50,000通、超過分は1,000通あたり0.90 USDです（Resendの料金）。
SendGrid：無料プランは現在60日間のトライアルです。Essentialsは月額19.95 USDからです（SendGridの料金）。
Mailgun：月額15 USDで10,000通、超過分は1,000通あたり1.10〜1.80 USDです（Mailgunの料金）。

SESのほうが安価ですが、サプレッションリストやレピュテーションを自分で管理する運用負担は大きくなります。SendHQは、素のAWS設定の複雑さなしに、検証済みドメインからのトランザクション送信と組み込みのサプレッション管理を提供することで、このギャップを埋めます。

エンジニアのための到達率チェックリスト

バウンスと苦情の両方を最小限に抑えるため、次の技術チェックリストに従ってください。

DNSの検証：SPF、DKIM、DMARCレコードが正しいことを確認します。SendHQ DNS Checkerで検証してください。設定の詳細は、送信ドメイン認証のガイドを参照してください。
ダブルオプトイン：明示的な確認なしにメールアドレスをリストへ追加しないでください。苦情率をほぼゼロに保つ唯一の方法です。
ワンクリック配信停止：List-Unsubscribeヘッダーを実装します。迷惑メールとして報告されるより、ユーザーが配信停止する方が望ましいです。
リアルタイムサプレッション：Webhookハンドラーが5分未満でデータベースを更新することを確認します。
監視：バウンス率が2%を超えた場合、または苦情率が0.1%を超えた場合のアラートを設定します。

まとめ：バウンスと苦情の比較

項目 | バウンス | 苦情

原因 | 技術的な失敗（無効なアドレス、メールボックスの容量超過） | ユーザーの操作（迷惑メールとして報告）

示すもの | リストの衛生管理不足／古いデータ | 無関係なコンテンツ／同意の欠如

即時の対応 | ハードバウンスを直ちに除外 | 直ちに除外

レピュテーションへの影響 | 中程度（非常に高い場合を除く） | 深刻

主な指標 | バウンス率 | 苦情率

目標 | リストをクリーンに保つ | ユーザーの信頼を保つ

まとめ

バウンスは厄介事ですが、苦情は危機です。バウンス率が高いと、ISPには「ずさんな送信者」と映ります。苦情率が高いと、「悪質な送信者」と映ります。サプレッションのロジックを自動化し、厳格なオプトインのフローを導入することで、送信レピュテーションを守ることができます。

トランザクションメールやエージェント主導のコミュニケーションを確実に扱う方法を求めるプロダクトチームは、SendHQをご覧ください。