DNSのMXレコードの確認方法について

DNSのMXレコードは、そのドメイン宛のメールをどのメールサーバーが受信するかを示すDNSレコードです。

メールの受信設定確認や、Google Workspace・Microsoft 365・独自メールサーバーの切り分けでよく使われます。

MXレコードとは何か

MXは Mail Exchanger の略です。

たとえば example.com 宛にメールを送る場合、送信側のメールサーバーは通常、まず example.com のMXレコードを調べ、どのメールサーバーへ配送すべきかを判断します。

MXレコードには、主に次の2つの情報が入ります。

• 優先度
• 配送先メールサーバーのホスト名

たとえば次のような設定です。

• 10 mail1.example.com
• 20 mail2.example.com

この場合、数字が小さい方が優先されるため、通常は mail1.example.com が先に使われ、利用できないときに mail2.example.com が使われます。

MXレコードがない場合はどうなるか

通常、送信側メールサーバーはまずMXレコードを参照します。

ただし、MXレコードが存在しない場合でも、ドメインのAレコードまたはAAAAレコードを使って配送を試みることがあります。

そのため、MXレコードがない＝必ずメール受信できないとは限りません。

ただし、実務上はメールを受信するドメインにはMXレコードを明示的に設定するのが一般的で安全です。

MXレコードを確認する方法

MXレコードの確認方法は、大きく分けると次の3つです。

1. コマンドで確認する
2. オンラインのDNS確認ツールで調べる
3. DNS管理画面で設定内容を確認する

実務では、次のように使い分けると分かりやすいです。

• 外部から見える現在の状態を確認したい
  → コマンドまたはオンラインツール
• 設定内容そのものを確認・修正したい
  → DNS管理画面

コマンドで確認する方法

nslookup を使う方法

Windowsでも比較的使いやすい定番のコマンドです。

nslookup -type=mx example.com

または対話モードでも確認できます。

nslookup
set type=mx
example.com

表示例

example.com    MX preference = 10, mail exchanger = mail1.example.com
example.com    MX preference = 20, mail exchanger = mail2.example.com

見方

• MX preference = 10
  → 優先度
• mail exchanger = mail1.example.com
  → メール受信サーバーのホスト名

dig を使う方法

dig は、より詳細にDNS情報を確認したいときに便利です。

MacやLinuxでよく使われます。

dig example.com MX

簡潔に表示したい場合は、次のようにします。

dig example.com MX +short

表示例

10 mail1.example.com.
20 mail2.example.com.

補足

末尾の . は、完全修飾ドメイン名（FQDN）を表しており、正常な表示です。

host コマンドを使う方法

Linux環境では host コマンドでも確認できます。

host -t MX example.com

表示例

example.com mail is handled by 10 mail1.example.com.
example.com mail is handled by 20 mail2.example.com.

オンラインツールで確認する方法

コマンドを使わずに確認したい場合は、DNS確認サイトでドメイン名を入力し、レコードタイプに MX を指定して調べる方法があります。

オンラインツールのメリット

• 初心者でも使いやすい
• 表示が見やすい
• DNSの伝播状況を確認しやすい

注意点

• ツールによって表示形式が異なる
• DNSキャッシュの影響で、最新状態がすぐに見えないことがある
• 社内専用DNSや非公開DNSの情報は確認できない

DNS管理画面で確認する方法

DNS管理サービスの管理画面で、設定されているMXレコードそのものを確認する方法です。

たとえば、次のようなサービスで確認できます。

• お名前.com
• ムームードメイン
• Xserver
• Cloudflare
• Route 53
• さくらのレンタルサーバ
• Google Cloud DNS

管理画面では一般的に、次のような項目で表示されます。

• 種別: MX
• 名前: @ または空欄、あるいは対象サブドメイン
• 値: mail.example.com
• 優先度: 10

注意点

管理画面で正しく設定されていても、外部からすぐ同じように見えるとは限りません。

DNS変更後は、必ず外部からの確認も行うのが安全です。

実際の確認手順

たとえば example.com のMXレコードを確認するときは、次の順番で見ると整理しやすいです。

手順1：DNS管理画面で設定を確認する

まず、意図したMXレコードが登録されているか確認します。

手順2：外部からMXレコードを確認する

nslookup -type=mx example.com

または

dig example.com MX +short

ここで、実際に公開されているMXレコードが見えます。

手順3：MXの向き先ホスト名が正しく解決できるか確認する

たとえばMXが mail.example.com なら、そのホスト名が正しくA/AAAAレコードに解決できるか確認します。

dig mail.example.com A +short

dig mail.example.com AAAA +short

または

nslookup mail.example.com

これは非常に重要です。

MXレコードの値にはIPアドレスではなく、メールサーバーを表すホスト名（FQDN）を設定します。

そのホスト名が正しく名前解決できなければ、メール配送に支障が出る可能性があります。

MXレコード確認時に見るべきポイント

MXレコードが存在するか

まず、対象ドメインにMXレコードがあるか確認します。

ただし前述のとおり、MXがなくてもA/AAAAへの配送が試されることはあります。

それでも、実務ではMXレコードを明示的に設定しておくのが一般的です。

優先度が適切か

優先度は数字が小さい方が高優先です。

例

• 1 mail.primary.example.com
• 5 mail.backup.example.com

この場合は mail.primary.example.com が優先されます。

MXの値がホスト名になっているか

正しい例

• mail.example.com

避けるべき例

• 192.0.2.10

MXレコードには、IPアドレスではなくホスト名を指定します。

MX先ホストがA/AAAAレコードに解決できるか

MXの向き先であるホスト名が、AレコードまたはAAAAレコードに解決できることを確認します。

MX先ホストがCNAMEになっていないか

これも見落とされやすい重要ポイントです。

実務上、MXの向き先ホスト名にはCNAMEを使わず、直接A/AAAAへ解決される名前を使うのが基本です。

たとえば、MXが mail.example.com を向いているなら、その mail.example.com 自体がCNAMEではなく、直接A/AAAAを持っている状態が望ましいです。

不要なMXが残っていないか

メールサービス移行時によくあるミスです。

たとえばGoogle WorkspaceやMicrosoft 365へ移行したのに、旧メールサーバーのMXが残っていると、メールが想定外のサーバーへ配送される原因になります。

TTLの影響を理解する

TTLは、DNS情報をどれくらいキャッシュしてよいかを示す値です。

TTLが長い場合、古いDNS情報がキャッシュに残りやすく、その結果として変更後もしばらく古い情報が参照されることがあります。

つまり、TTLそのものが反映を遅らせるというより、キャッシュの影響で切り替えがすぐに見えないと考えると正確です。

サブドメインのMXを確認する方法

サブドメインに対してメール受信設定がある場合は、そのサブドメインを指定して確認します。

dig sub.example.com MX +short

または

nslookup -type=mx sub.example.com

ドメインとサブドメインでは、メール受信設定が別になっていることがあるため、確認対象を正確に指定することが大切です。

よくあるトラブルと原因

MXレコードが見つからない

考えられる原因は次のようなものです。

• まだ設定していない
• 確認対象のドメイン名を間違えている
• 別のDNSサーバーを見ている
• DNS変更がまだ外部に反映されていない

管理画面では正しいのに、外部確認では違って見える

考えられる原因は次の通りです。

• ネームサーバーの向き先が想定と違う
• 実際に使われている権威DNSではない場所を編集している
• DNSキャッシュが残っている
• CDNやDNS管理サービスの構成を誤認している

MXは正しく見えるのにメール受信できない

ここは重要です。

MXレコードの確認だけで、メール受信が正常だとは断定できません。

MX確認で分かるのは、主に次の点です。

• 受信先としてどのホストが設定されているか
• 優先度がどうなっているか
• そのホスト名が名前解決できるか

一方で、次のような問題はMX確認だけでは分かりません。

• SMTPサーバーが実際に稼働しているか
• 25番ポートなどが到達可能か
• メールボックス容量が不足していないか
• 受信ルールやフィルタで弾かれていないか
• サービス側で障害が起きていないか

つまり、MXはDNS上の配送先情報を確認するものであり、実際のメールサービスの正常動作までは保証しないという点を押さえておく必要があります。

MXレコードとあわせて確認したいDNS設定

メール関連では、MXだけでなく次のレコードも重要です。

Aレコード / AAAAレコード

MXが向いているホスト名の実際の接続先を示します。

SPF

主に送信元サーバーの正当性を示すためのTXTレコードです。

DKIM

送信メールの電子署名検証に使う公開鍵情報です。

DMARC

SPFやDKIMの認証失敗時の扱いや、レポート方針を定義します。

整理すると、次のように考えると分かりやすいです。

• MX
  → 受信先の指定
• SPF / DKIM / DMARC
  → 主に送信ドメイン認証

すぐ使える確認コマンドまとめ

MXレコード確認

nslookup -type=mx example.com

dig example.com MX +short

MX先ホストのAレコード確認

dig mail.example.com A +short

MX先ホストのAAAAレコード確認

dig mail.example.com AAAA +short

詳細確認

dig example.com MX

具体例

たとえば example.com のMXを確認した結果が次の通りだったとします。

dig example.com MX +short

結果

10 mail.example.com.

次に、MX先ホストが正しく解決できるか確認します。

dig mail.example.com A +short

結果

203.0.113.10

この場合は、次のように読みます。

• example.com 宛メールは
• 優先度10の mail.example.com に配送され
• そのホスト名は 203.0.113.10 に解決される

この状態であれば、少なくともDNS上はメール受信先が定義されていると判断できます。

まとめ

MXレコード確認で特に重要なのは、次のポイントです。

• 対象ドメインにMXレコードがあるか
• 優先度が正しいか
• MXの向き先がホスト名になっているか
• そのホスト名がA/AAAAに解決できるか
• MX先ホストがCNAMEになっていないか
• 不要な旧MXが残っていないか

そして、最後に大事なのは、MX確認はあくまでDNS設定の確認であり、メールサーバー自体の正常性確認とは別という点です。

以上、DNSのMXレコードの確認方法についてでした。

最後までお読みいただき、ありがとうございました。