メール不達を調査する：DNSのMXレコード確認から伝播状況の確認まで

まず結論――MXレコードはこの1コマンドで確認する

調査したいドメインのMXレコードをすぐ確認するには、dig コマンドにレコード種別 mx とドメイン名を渡します。

dig mx 調べたいドメイン名

たとえば example.com 宛のメールがどのサーバーに届くか確認するには次のようになります。

$ dig mx example.com

dig が入っていない環境では、以下でインストールしてください。

# Debian / Ubuntu
sudo apt install bind9-utils

# RHEL / AlmaLinux / Rocky Linux / CentOS Stream
sudo dnf install bind-utils

MXレコードとメール配送の仕組み

MX（Mail Exchanger）レコードは、あるドメイン宛のメールを受け取るサーバーのホスト名をDNSで公開する仕組みです。user@example.com 宛にメールを送ると、送信側のメールサーバー（MTA）は次の手順で配送を進めます。

1. example.com のMXレコードをDNSに問い合わせ、メールサーバーのホスト名を取得する
2. そのホスト名のAレコード（IPv6ならAAAAレコード）を引き、IPアドレスを得る
3. 取得したIPアドレスのポート25番（SMTP）へ接続してメールを渡す

MXレコードには優先度（プリオリティ）という数値が付きます。数値が小さいほど優先度が高く、送信側MTAは最も小さい値のサーバーへまず接続を試みます。接続できなかった場合は次に小さい値のサーバーへ自動的にフォールバックします。この仕組みを使ってプライマリとバックアップのメールサーバーを使い分けるのが一般的な構成です。

MXレコードが誤設定されているか、そもそも存在しない場合、送信元MTAは配送先を見つけられず、送信者に不達通知（バウンスメール）を返します。メール不達が報告されたとき、まずMXレコードを確認するのが実務的な第一歩です。

dig の出力を正確に読む

以下は dig mx gmail.com を実行したときの典型的な出力例です（TTLや応答サーバーは実行環境により異なります）。

$ dig mx gmail.com

; <<>> DiG 9.18.x <<>> mx gmail.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;gmail.com.                     IN      MX

;; ANSWER SECTION:
gmail.com.              3600    IN      MX      5  gmail-smtp-in.l.google.com.
gmail.com.              3600    IN      MX      10 alt1.gmail-smtp-in.l.google.com.
gmail.com.              3600    IN      MX      20 alt2.gmail-smtp-in.l.google.com.
gmail.com.              3600    IN      MX      30 alt3.gmail-smtp-in.l.google.com.
gmail.com.              3600    IN      MX      40 alt4.gmail-smtp-in.l.google.com.

;; Query time: 15 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Sun Jul 27 10:00:00 JST 2025
;; MSG SIZE  rcvd: 161

status でクエリ成否を確認する

ヘッダー行の status: NOERROR はクエリが正常に完了したことを示します。status: NXDOMAIN ならドメイン自体がDNSに存在しません。status: SERVFAIL は権威DNSサーバー側に問題があるか、委任設定が壊れているケースです。

ANSWER SECTION のMX行を読む

各行の構造は ドメイン名 TTL クラス MX 優先度 メールサーバーホスト名 の順です。上の例では優先度 5 の gmail-smtp-in.l.google.com. が最優先で選ばれます。TTL（秒）はDNSキャッシュの有効期限で、MXを変更してもこの時間が経過するまで古いサーバーへ配送が続く点に注意が必要です。

SERVER 行で利用中のリゾルバを確認する

出力末尾の SERVER: 127.0.0.53#53 は、クエリを処理したリゾルバのアドレスです。127.0.0.53 はsystemd-resolvedのスタブリゾルバを示しており、Ubuntu 18.04以降やDebian系の多くの環境でデフォルト有効です。外部DNSに直接問い合わせて結果を比較したい場合は @ でサーバーを指定します。

# Google Public DNS に直接問い合わせる
dig mx example.com @8.8.8.8

# Cloudflare DNS で確認
dig mx example.com @1.1.1.1

素早く確認したいときの出力整形

フル出力は情報量が多いため、MXレコードの値だけを手早く確認したい場面では +short オプションが便利です。

$ dig mx gmail.com +short
5 gmail-smtp-in.l.google.com.
10 alt1.gmail-smtp-in.l.google.com.
20 alt2.gmail-smtp-in.l.google.com.
30 alt3.gmail-smtp-in.l.google.com.
40 alt4.gmail-smtp-in.l.google.com.

スクリプト内でANSWER SECTIONだけを取り出したい場合は +noall +answer の組み合わせも有効です。ヘッダーや質問セクションが省かれ、grep や awk と組み合わせやすくなります。

dig mx gmail.com +noall +answer

nslookup での確認方法

nslookup も多くのLinuxディストリビューションで利用でき、-type=MX を指定することで同様の結果が得られます。

$ nslookup -type=MX gmail.com
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
gmail.com       mail exchanger = 5 gmail-smtp-in.l.google.com.
gmail.com       mail exchanger = 10 alt1.gmail-smtp-in.l.google.com.
gmail.com       mail exchanger = 20 alt2.gmail-smtp-in.l.google.com.
gmail.com       mail exchanger = 30 alt3.gmail-smtp-in.l.google.com.
gmail.com       mail exchanger = 40 alt4.gmail-smtp-in.l.google.com.

Non-authoritative answer という表記はキャッシュから返答したことを意味し、エラーではありません。権威DNSサーバーから直接応答が得られた場合はこの行は表示されません。

nslookup は出力がスクリプト処理しにくく、パーサーの実装もツールによって挙動が異なるため、現在の実務では dig が主流です。両方使える環境なら dig を優先するのが無難です。

実務でよくある確認パターンと落とし穴

MXレコードが返ってこない（ANSWER: 0）

MXレコードが設定されていないドメインは ANSWER: 0 になります。この場合、RFC 5321の規定によりAレコード（ドメインそのもののIPアドレス）にフォールバックして配送を試みるMTAもありますが、多くのクラウドメールサービスではMXなしを不達として扱います。新規ドメインでメールが受け取れない場合は、MXレコードの登録有無を最初に確認します。

DNSキャッシュによる移行期の遅延

MXレコードを変更（メールサーバー移行など）しても、旧レコードのTTLが残っている間は旧サーバーへの配送が続きます。移行前にTTLを短く（300秒程度）しておき、移行完了後に元のTTLへ戻すのが定石です。変更後は外部DNSへ直接問い合わせて伝播状況を確認します。

# 2つの外部DNSで結果を比較して伝播を確認
dig mx example.com @8.8.8.8 +short
dig mx example.com @1.1.1.1 +short

MXレコードにIPアドレスを直書きしない

MXレコードの値にはIPアドレスではなくホスト名（FQDN）を指定する必要があります。IPアドレスを直接設定するとRFC違反となり、一部のMTAは配送を拒否します。ある運用現場では、DNS管理ポータルがIPとホスト名のどちらも受け付ける設計だったために誤入力が発生し、特定ベンダーからのメールだけが届かないという問題が数日間放置された事例があります。

スプリットDNS環境での注意点

社内DNSが正しい値を返していても、外部からは別の値（またはレコードなし）が見えるスプリットDNS構成では、内部からの確認だけでは不十分です。自社ドメインのMXを検証するときは必ずパブリックDNSを指定して確認し、外部からの見え方を把握してください。

# 外部から見えるMXレコードを確認（社内DNSをバイパス）
dig mx 自社ドメイン @8.8.8.8 +short