1.はじめに
システムやアプリケーションからメールを送信した際、「メールが届かない（バウンスした）」というトラブルに遭遇したことはありませんか？
そんな時、ついアプリケーション側のプログラムのエラーや、送信元サーバー（SendGridやSESなど）の設定を疑ってしまいがちです。
しかし、実は根本的な原因が 「宛先ドメインのDNS（特にMXレコード）の設定」 にあるケースが非常に多いのです。
この記事では、メール送信時の「届かない（バウンス）」トラブルと、その原因になりやすい「MXレコード」の関係を整理し、エンジニアがトラブル時にまず確認すべきポイントを解説します。
2. 前提知識のおさらい
そもそも、MXレコードやバウンスとは何でしょうか？簡単に整理します。
MXレコード（Mail eXchanger）とは？
DNSレコードの一種で、「そのドメイン宛のメールを、どのサーバーに届けるべきか」 を指定する「宛先案内状」のようなものです。
優先度（Priority）の概念
複数のMXレコードを設定することができます。数値が小さい（優先度が高い）サーバーから順に配送を試みる仕組みになっており、メインサーバーとバックアップサーバーを分ける際などに使われます。
💡 豆知識：なぜ優先度に「10」や「100」がよく使われるのか？
実際のDNS設定を見ると、優先度に10や100といった数字がよく使われています。これは「優先度がとても低いから」ではなく、「とりあえずキリの良い10や100をメインにしておいて、将来もし他のサーバーを前後に足したくなった時のために、前後の数字（1〜9や11〜99など）を空けておこう」 という、システム管理者たちの昔からの知恵（慣習）によるものです。
メールのバウンス（Bounce）とは？
送信したメールが相手に届かず、差し戻されてしまうことです。大きく2種類に分かれます。
ハードバウンス（Hard Bounce）
恒久的なエラー。宛先のメールアドレスが存在しない、ドメインが存在しないなど、何度再送しても届かない 状態です。
ソフトバウンス（Soft Bounce）
一時的なエラー。相手のメールボックスが容量オーバーになっている、相手サーバーが一時的にダウンしているなど、時間を置けば届く可能性がある状態です。
3. MXレコードとバウンスはどう関係しているのか？（4つのケース）
ここからが本題です。「相手先のMXレコードになんらかの問題がある」ことで発生するバウンスのシナリオを、4つのケースに分けて解説します。
ケースA：MXレコードが存在しない（未設定・引き忘れ）
結果: 即座にハードバウンス
解説: 送信側サーバーがDNSに問い合わせても「このドメインのメールの送り先がわからない」と判断され、即座にエラーが返ります。相手側がドメインを取得した直後や、サーバー移行時のDNS設定漏れで頻発します。
ケースB：MXレコードの向け先（バリュー）が間違っている
結果: ハードバウンス、またはタイムアウト（ソフトバウンスを経てハードバウンス）
解説: レコードの記述にタイポがある、あるいは解約済みの古いメールサーバーを指定したままになっているケースです。無関係なサーバーに接続に行き拒否されるか、応答がなくタイムアウトになります。
ケースC：優先度（Priority）設定のミス
結果: メインサーバー障害時にバウンスが発生する
解説: 複数のMXレコードの優先度をすべて同じに設定してしまったり、バックアップとして指定した側のサーバーが死んでいるケースです。メインサーバーが一時的にダウンした際、本来ならサブにフォールバックしてほしいのに、うまく機能せずにバウンスしてしまいます。
ケースD：DNSキャッシュの残留（TTLの問題）
結果: 移行作業直後に一時的なバウンスや不達が発生する
解説: 相手側がメールサーバーを移行した直後によく起こります。「DNSの浸透待ち」と呼ばれることもありますが、正確には 「古いDNSキャッシュ（TTL）の有効期限が切れていない」 状態です。世界中のDNSサーバーのキャッシュが更新されるまでは、古いMXレコードを参照する通信と新しいMXレコードを参照する通信が混在し、不安定になります。
4. バウンスを防ぐ・解決するためのトラブルシューティング
実際にバウンスが発生した際、どのように調査すればよいか、実践的な方法を紹介します。
① エラーメール（NDR）のログを読む
バウンスした際に返ってくるエラーメール（Non-Delivery Report）には、原因のヒントが隠されています。以下のキーワードやステータスコードを探しましょう。
Diagnostic-Code: smtp; 550 5.4.4 <user@example.com>: Recipient address rejected: Domain not found (NXDOMAIN)
NXDOMAIN / Domain not found: ドメイン自体が存在しない、または名前解決ができていません（ケースAなど）。
Connection timed out: MXレコードは引けたものの、その先のサーバーに繋がりません（ケースBなど）。
5.x.x のコード: 致命的なエラー（ハードバウンス）を示します。
② MXレコードをコマンドで確認する
原因がDNSにありそうなら、実際にターミナルからコマンドを叩いてみましょう。
digコマンドの例
$ dig example.com MX +short
10 mail.example.com.
20 backup-mail.example.com.
何も返ってこない場合はMXレコードが設定されていません。
nslookup コマンドの例（Windows等）
$ nslookup -type=MX example.com
5. 補足：SPF / DKIM / DMARC との違い
「DNSに設定するメール関連のレコード」というと、SPF・DKIM・DMARC を思い浮かべる方も多いと思います。これらもバウンスに関わりますが、役割が全く異なります。混同しないように整理しておきましょう。
MXレコード： メールを 「受信」するための経路案内
SPF / DKIM / DMARC： メールを 「送信」する際の身元証明（なりすまし・スパム扱いによるバウンスを防ぐため）
MXレコードは「相手の家（サーバー）の住所」、SPF/DKIM/DMARCは「自分が送る手紙の署名・身分証」とイメージすると分かりやすいです。
6. まとめ
MXレコードはメール配送の要であり、設定ミスや名前解決の失敗は即座にバウンスに繋がります。
バウンスが発生した際は、アプリのバグを疑う前に、まずエラーログを確認する癖をつけましょう。
そして、dig コマンドやWebツールを使って、宛先ドメインのMXレコードが正しく引けるかを調べるのが解決への近道です。
メール配信のトラブルシューティングにおいて、DNSの知識は間違いなく強力な武器になります。この記事が、謎のバウンスに悩むエンジニアの助けになれば幸いです！