バウンス率は送信元の評判を落とす主要因の1つです。そしてバウンスの大半は、送る前に減らせます。ここでは実際にできる検証と、その限界を整理します。

送る前にできる4つの検証

順検証落とせるものコスト
1形式の検証タイプミス、全角、スペース混入ほぼゼロ
2MXレコードの確認ドメインごと消えている宛先低い
3重複と表記ゆれの統合同じ会社への複数送信低い
4除外リストとの照合過去にバウンス・拒否した宛先低い

この4つで、バウンスの発生源のうち「明らかに送るべきでないもの」はほぼ落とせます。残るのは「ドメインは生きているが、そのアドレスは存在しない」ケースです。

1. 形式の検証

単純ですが効きます。リストの取り込み時に落とすべきものを挙げます。

  • @が無い、または複数ある
  • 全角文字が混ざっている（＠、．、全角英数）
  • 前後や途中にスペースがある
  • 使用できない文字が含まれる
  • ドメイン部分にドットが無い
  • 末尾が不完全（.co、.c など）

CSVからの取り込みでは、コピー時に見えないスペースが入ることがよくあります。取り込み時に必ず前後の空白を落とします。

2. MXレコードの確認 ― 何が分かるか

MXレコードは、そのドメインのメールをどのサーバーが受け取るかをDNSに記述したものです。

MXレコードの状態意味判断
存在するそのドメインはメールを受け取る設定になっている送ってよい候補
存在しないメールを受け取る設定がない送らない
ドメイン自体が引けないドメインが失効している可能性送らない

会社の統合・廃業・ドメイン変更があった場合、ここで落とせます。とくに古いリストではこの検証の効果が大きくなります。

MX確認の限界

重要な限界を明示します。MXレコードがあっても、そのアドレスが存在するとは限りません。

状況MX確認の結果実際に送ると
ドメインは生きているがアドレスは廃止通過するバウンスする
担当者が退職してアドレスが削除された通過するバウンスする
推測で作ったアドレス通過する高確率でバウンス

3行目が示す通り、MX確認は「推測でアドレスを作る」ことの正当化にはなりません。推測アドレスはMXを通過しますが、存在しない確率が高く、そもそも公開されていたアドレスではないため法的な根拠も失います。

SMTPでの存在確認について

技術的には、SMTPで接続してRCPT TOの応答を見る方法があります。ただし実務では推奨しにくい理由があります。

問題中身
確実でない多くのサーバーは存在しないアドレスでも受け付ける応答を返す（catch-all設定）
不審な挙動になり得る接続と切断を繰り返すと、送信元IPの評価に影響する可能性がある
時間がかかる件数が多いと現実的でない

したがって実務では、MX確認までを事前に行い、残りは少量から送って実測するのが合理的です。ウォームアップ期間中は送信量が小さいので、バウンスの実測をこの期間に済ませられます。

3〜4. 統合と照合、そして結果の書き戻し

検証と同じくらい重要なのが、結果をマスタに書き戻すことです。

起きたことマスタに書くこと次回の効果
ハードバウンス恒久除外フラグ二度と送らない
ソフトバウンス回数をカウント3回で恒久扱いに切り替え
MXなしで除外除外理由と判定日再検証の判断ができる
配信停止横断の拒否フラグ全案件から外れる

バウンスしたアドレスは削除ではなく除外として残します。削除すると、別のリストから同じアドレスが入ってきたときに再送してしまいます。「送ってはいけない記録」として持つことに意味があります。

運用の順序

まとめると、次の順で回します。

  1. 取り込み時：形式の検証、前後の空白の除去
  2. 取り込み時：表記ゆれの正規化と重複統合
  3. 配信計画時：MXレコードの確認
  4. 送信の直前：除外リスト（バウンス・拒否・クールダウン）との照合
  5. 送信後：バウンス結果をマスタに書き戻す

4番目を「配信計画時」ではなく「送信の直前」に置くのが要点です。計画から送信までの間に、別の案件が同じ相手に接触している可能性があります。

まとめ

  • バウンスの大半は送る前に減らせる。形式検証・MX確認・重複統合・除外照合の4つ
  • MXレコードで分かるのはドメインがメールを受け取れるかまで。個別アドレスの存在は分からない
  • MX通過は推測アドレスの正当化にならない
  • SMTPでの存在確認は確実でなく、挙動として不審に見える可能性がある
  • 残りは少量から送って実測する。ウォームアップ期間がその機会になる
  • バウンスは削除せず除外として記録し、マスタに書き戻す