まず結論――MXレコードはこの1コマンドで確認する
調査したいドメインのMXレコードをすぐ確認するには、dig コマンドにレコード種別 mx とドメイン名を渡します。
dig mx 調べたいドメイン名たとえば example.com 宛のメールがどのサーバーに届くか確認するには次のようになります。
$ dig mx example.comdig が入っていない環境では、以下でインストールしてください。
# Debian / Ubuntu
sudo apt install bind9-utils
# RHEL / AlmaLinux / Rocky Linux / CentOS Stream
sudo dnf install bind-utilsMXレコードとメール配送の仕組み
MX（Mail Exchanger）レコードは、あるドメイン宛のメールを受け取るサーバーのホスト名をDNSで公開する仕組みです。user@example.com 宛にメールを送ると、送信側のメールサーバー（MTA）は次の手順で配送を進めます。
example.comのMXレコードをDNSに問い合わせ、メールサーバーのホスト名を取得する- そのホスト名のAレコード（IPv6ならAAAAレコード）を引き、IPアドレスを得る
- 取得した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: 161status でクエリ成否を確認する
ヘッダー行の 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 +answernslookup での確認方法
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 +shortMXレコードにIPアドレスを直書きしない
MXレコードの値にはIPアドレスではなくホスト名（FQDN）を指定する必要があります。IPアドレスを直接設定するとRFC違反となり、一部のMTAは配送を拒否します。ある運用現場では、DNS管理ポータルがIPとホスト名のどちらも受け付ける設計だったために誤入力が発生し、特定ベンダーからのメールだけが届かないという問題が数日間放置された事例があります。
スプリットDNS環境での注意点
社内DNSが正しい値を返していても、外部からは別の値（またはレコードなし）が見えるスプリットDNS構成では、内部からの確認だけでは不十分です。自社ドメインのMXを検証するときは必ずパブリックDNSを指定して確認し、外部からの見え方を把握してください。
# 外部から見えるMXレコードを確認（社内DNSをバイパス）
dig mx 自社ドメイン @8.8.8.8 +short「コマンドは打てる。次は”現場で通用する型”を最短で身につけたい」——そんなあなたへ。
ネットの断片的なTipsをコピペするだけでは、体系的な運用スキルはなかなか積み上がりません。リナックスマスター.JPの無料メルマガ「リナマガ」では、現場で実際に使うLinuxサーバー運用の考え方を、順を追って実務目線でお届けしています。いま登録された方には、安全なサーバー構築の「型」をまとめた『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼント中です。
＞＞ 図解60P『Linux入門マニュアル』を無料で受け取る
（メルマガ登録は10秒・いつでも解除OK）
※ 「独学の時間がもったいない」「プロから現場の技術を最短で学びたい」という本気の方には、2日で実務レベルが身につく初心者向けハンズオンセミナーもご用意しています。
