メール到達率とは？届かない原因の切り分けと送信者要件・再発防止KPI
メールが届かないときは、件名を直す前に「送信できなかった」「受信側には受理されたが迷惑メールへ入った」「受信箱には届いたが反応されなかった」を分けます。最初にエラーコードと宛先ドメインを確認し、次にSPF・DKIM・DMARC、リスト品質、苦情、配信量の変化を調べると、原因を短時間で絞れます。
本記事のポイント
- Deliveryは受信サーバーに受理された状態、Inbox Placementは受信箱に配置された状態であり、同じ指標ではありません。
- 届かない原因は、エラーコード、宛先ドメイン、認証、配信量、リスト、苦情の順に切り分けます。
- 再発防止ではSPF・DKIM・DMARCの合否だけでなく、ハードバウンス、苦情、解除、抑止反映、送信量の変化を継続監視します。
メール到達率とは何か
実務では「到達率」という言葉が複数の意味で使われます。数字を比較する前に、配信ツールが何を分母・分子にしているか確認してください。
| 段階 | 意味 | 主な確認データ | 注意点 |
|---|---|---|---|
| 送信要求 | 配信基盤が送信処理を開始 | 送信件数、キュー、APIエラー | 送信要求の成功は相手側の受理を意味しない |
| Delivery | 受信サーバーが拒否せず受理 | Delivered、ハード/ソフトバウンス、SMTP応答 | 迷惑メールフォルダへの配置を含み得る |
| Inbox Placement | 受信箱へ配置 | 受信箱配置テスト、Postmasterデータ、ドメイン別反応 | 通常の配信レポートだけでは直接測れない場合がある |
| Engagement | 読者がクリック、返信、CV | ユニーククリック、返信、CV、商談 | 開封はApple MPPの影響を受ける |
SalesforceもDeliveryとDeliverabilityの違いを説明しています。用語はベンダーごとに揺れるため、本記事では「受信サーバーの受理」と「受信箱への配置」を分けて扱います。
届かない原因を確認する順番
| 順番 | 確認すること | 分かること | 次の対応 |
|---|---|---|---|
| 1 | SMTP応答とバウンス種別 | 宛先不存在、容量、ポリシー拒否、認証不足 | 恒久エラーは即時抑止、一時エラーは上限を決めて再試行 |
| 2 | 宛先ドメイン別の偏り | Gmail、Microsoft、独自ドメインなど特定受信側の問題 | 同時間帯・同キャンペーンのエラーを集約 |
| 3 | SPF・DKIM・DMARCとアラインメント | 正規送信元の未登録、署名失敗、From不整合 | DNS、署名ドメイン、転送経路を修正 |
| 4 | 直近の送信量・頻度・送信元変更 | 急増、未ウォームアップ、新しいIP/ドメインの影響 | 影響範囲を止め、安定量から段階的に戻す |
| 5 | ハードバウンス、苦情、解除、休眠 | リスト取得経路や関連性の劣化 | 獲得経路別に停止し、抑止リストを全経路へ反映 |
| 6 | 本文、リンク、差出人、件名 | なりすましに見える表示、短縮URL、説明不足 | 認証とリストの問題を直した後に改善 |
認証の確認は、DMARC集計レポートまで含めると送信元の漏れを見つけやすくなります。具体的な読み方はDMARC集計レポートの読み方、SPFの上限はSPF DNSルックアップ監視を参照してください。
2026年に確認すべき送信者要件
受信サービスの要件は同じではありません。特に「Yahoo」は米国Yahoo IncとYahoo! JAPANを分けて確認します。以下は2026年8月23日時点の公式情報です。
| 受信サービス | 対象 | 主な要件 | 公式情報 |
|---|---|---|---|
| Gmail | 個人用@gmail.com/@googlemail.com。約5,000通/日以上は一括送信者 | 全送信者はSPFまたはDKIM、PTR、TLS、RFC 5322。大量送信者はSPF・DKIM・DMARC、アラインメント。プロモーションはRFC 8058 One-Clickと本文解除導線 | メール送信者のガイドライン |
| Yahoo Inc | Yahoo Mail、AOLなど。公開された固定通数しきい値はない | 大量送信者はSPF・DKIM・DMARC、Fromアラインメント、解除導線、2日以内の停止。苦情率0.3%未満 | Sender Best Practices |
| Yahoo! JAPAN | LINEヤフーのYahoo!メール | DKIM・SPF・DMARCを検証。米Yahooの大量送信者要件をそのままYahoo! JAPAN要件とは扱わない | 迷惑メール対策 |
| Microsoft consumer mail | 同一RFC 5322.FromドメインからOutlook.com等へ5,000通/日以上 | SPFとDKIMの両方、DMARC、少なくとも一方のアラインメント。不足時は550 5.7.515で拒否され得る | Microsoft公式発表 |
GmailはPostmaster Toolsの迷惑メール率について、0.10%未満を維持し、0.30%以上にしないよう案内しています。0.30%は目標値ではなく、超えてはいけない上限として扱います。SPF・DKIM・DMARCは最低条件であり、到達を保証しません。同意、関連性、リスト衛生、苦情抑止が別に必要です。
問題発生から60分で行う初動
- 0〜10分：影響範囲を止める
同じ送信元・テンプレート・リストを使う予約配信を停止し、トランザクションメールへ影響があるか分けます。 - 10〜20分：証拠を保存する
SMTPコード、Message-ID、宛先ドメイン、配信時刻、送信元IP、認証結果、キャンペーンIDを保存します。 - 20〜35分：変更点を確認する
DNS、ESP、差出人、配信量、リスト取込、テンプレート、リンクドメインの直近変更を洗い出します。 - 35〜50分：原因ごとに処置する
不存在アドレスを抑止し、認証失敗を修正し、苦情増加の獲得経路を止めます。ブロックリストの場合は解除申請の手順に従います。 - 50〜60分：再開条件を決める
誰が、どの数値とテスト結果を確認したら再開できるかを記録します。全面再開ではなく、少量の健全なセグメントから戻します。
再発防止で追う運用KPI
| KPI | 見る理由 | 切り分け | 異常時の行動 |
|---|---|---|---|
| ハードバウンス率 | 不存在・恒久拒否を検知 | 獲得経路、リスト取込日、宛先ドメイン | 即時抑止し、同じ取得元を点検 |
| ソフトバウンス率と再試行回数 | 一時障害と継続拒否を分ける | SMTPコード、宛先ドメイン | 無制限再試行を止め、上限到達で抑止 |
| 迷惑メール報告率 | 同意・関連性・頻度の悪化を検知 | キャンペーン、獲得経路、セグメント | 該当配信を止め、原因を改善。フィードバックループ監視へつなぐ |
| 解除率と反映時間 | 読者の意思と抑止処理を確認 | テーマ、頻度、配信経路 | RFC 8058・本文導線・全システムのsuppressionを確認 |
| SPF/DKIM/DMARC合格率 | 正規送信元の漏れ・改変を検知 | 送信元、DKIMセレクタ、alignment | 未知送信元を停止し、DMARCレポートで特定 |
| 日次送信量の変化率 | 急増による評判悪化を予防 | ドメイン、IP、メール種別 | 増加理由を確認し、段階配信へ戻す |
マーケティングメールとパスワード再設定・請求通知などを同じ送信経路に混ぜると、一方の評判悪化が重要通知へ波及します。分離の考え方はトランザクションメールとマーケティングメールの分離設計で確認できます。
毎週・毎月のチェックリスト
配信ごと・日次
- SMTPエラーとバウンスを宛先ドメイン別に集計する
- 苦情、解除、抑止が全送信経路へ反映されたか確認する
- 前日比で送信量が急増していないか確認する
- トランザクションメールの遅延・失敗を別に監視する
週次・月次
- DMARC集計レポートで正規送信元と未知送信元を棚卸しする
- 獲得経路別のハードバウンス、苦情、解除を比較する
- 休眠アドレスの配信頻度と再許諾方針を見直す
- Gmail Postmaster Toolsなど利用できる受信側データを確認する
- 新しい送信サービス、差出人、DKIM鍵の変更を台帳へ記録する
よくある質問
メール到達率と配信率はどう違いますか？
一般に配信率は受信サーバーが拒否しなかった割合を示し、受信箱への配置までは保証しません。受信箱配置は迷惑メールフォルダを除く別の段階です。配信ツールごとに名称と分母が違うため、定義を確認します。
届かないメールの原因をどうチェックしますか？
SMTP応答とバウンス種別、宛先ドメイン、SPF・DKIM・DMARC、送信量の変化、リスト品質と苦情の順に確認します。件名や本文は、技術とリストの問題を切り分けた後に見直します。
再発防止の運用KPIは何を見ますか？
ハード/ソフトバウンス、苦情、解除と反映時間、SPF・DKIM・DMARC合格率、送信量の変化を見ます。クリックやCVは事業成果として別に追い、開封率だけで到達を判断しません。
メール到達率を改善するにはどこから始めますか？
送信元を棚卸しし、すべての正規経路でSPF・DKIM・DMARCとアラインメントを確認します。同時に、恒久エラー、苦情、解除を全経路で即時抑止し、配信量を安定させます。
公開情報と責任主体
本記事はGmail、Yahoo Inc、Yahoo! JAPAN、Microsoft、RFCの公開要件を2026年8月23日に確認し、受信サービスごとの差を分けて整理しています。送信者要件は更新されるため、運用変更前に各公式ページを再確認してください。更新方針と責任主体は編集方針と監修方針で確認できます。
