メールが届かないとき、MXレコードの誤りは「値の書き方」「書いた場所」「指す先のホスト」の3点にほぼ集約されます。この記事では、dig で現在の MX を読み取り、よくある書式ミスを可能性の高い順に一つずつ確認して直す手順を説明します。読み終えるころには、どのレコードのどこが間違っているかを自分で特定し、修正後に正しく反映されたかを確かめられるようになります。
なお、サーバー移転やメールサービスの乗り換えの直後に起きた不達は原因の傾向が異なるため、別記事「サーバー移転・メール切替後のMXレコード誤設定を修正する方法」で扱っています。この記事は「MXを自分で入力・編集したあとに届かなくなった」場面を想定しています。
まず症状を読み取る
外部（Gmail などの別アドレス）から自ドメイン宛てにテストメールを送り、戻ってきたエラーメール（バウンス）の本文を確認します。文言は送信側のサーバーによって異なりますが、おおむね次のように読み分けられます。
- 「ドメインが見つからない」「MX も A も無い」といった趣旨: MX がそもそも存在しない、または別の名前に作られている
- 「接続できない」「タイムアウト」: MX はあるが、指す先のホストの IP が古い・存在しない、またはポート25が受け付けていない
- 「宛先ユーザーが存在しない」（550 番台でユーザー不明の趣旨）: MX は正しく、メールサーバー側のアカウント設定の問題
最後のケースは DNS ではなくメールボックスの問題なので、この記事の手順の前にメールサーバー側を確認してください。
現在のMXを dig で確認する
管理画面の表示ではなく、DNS が実際に返している値を見ます。
# 公開リゾルバー経由で MX を確認
dig example.com MX +short
# そのドメインの権威ネームサーバーを調べる
dig example.com NS +short
# 権威ネームサーバーに直接問い合わせる（キャッシュの影響を受けない）
dig @ns1.example-dns.net example.com MX
# Windows の場合
nslookup -type=mx example.com正常なら 10 mail.example.com. のように「優先度 ホスト名」の形で返ります。公開リゾルバーと権威サーバーで結果が違う場合は、修正自体は済んでいてキャッシュが残っているだけの可能性があります。権威サーバーの回答を正として判断してください。
よくある誤設定と直し方（可能性の高い順）
1. 編集しているDNSが実際に使われていない
レジストラとレンタルサーバーの両方に DNS 管理画面がある環境では、使われていない側を編集していることがよくあります。dig example.com NS +short の結果に出てくるネームサーバーを管理しているサービスだけが有効です。結果が編集した画面のサービスと違うなら、正しい側で MX を作り直します。
2. ホスト名（名前）欄の入れ間違い
ドメイン直下のメールアドレス（info@example.com）を受けるには、MX はドメインそのもの（多くの画面で @ または空欄）に作ります。よくある誤りは次の2つです。
- ホスト欄に
mailと入れてしまい、mail.example.comの MX になっている - ホスト欄に
example.comと入れ、画面がドメイン名を自動で付け足してexample.com.example.comになっている
dig mail.example.com MX +short や dig example.com.example.com MX +short で値が返るなら、この誤りです。正しい名前に作り直し、誤って作ったレコードは削除します。
3. 値の末尾ドットの抜け（ゾーンファイルを直接書く場合）
BIND などのゾーンファイルでは、末尾にドットの無い名前はゾーン名が補われます。MX 10 mail.example.com と書くと mail.example.com.example.com を指すことになります。ゾーンファイルでは mail.example.com. とドットを付けるか、ゾーン内の名前なら mail とだけ書きます。管理画面型の DNS は自動で補正するものが多いですが、挙動はサービスごとに違うため、dig の結果に余計なドメインが付いていないかで判断してください。
4. 値にIPアドレスやCNAMEの名前を入れている
MX の値はホスト名でなければならず、IP アドレスは書けません。画面によっては入力を受け付けてしまいますが、送信側からは正しく扱われません。また RFC 2181 では、MX が CNAME（別名）を指すことも認められていません。動く場合もありますが、送信側の実装によっては配送に失敗します。
# MX の指す先が A/AAAA を持つか、CNAME になっていないか
dig mail.example.com A +short
dig mail.example.com AAAA +short
dig mail.example.com CNAME +shortCNAME が返る場合は、MX の値を CNAME の行き先の正式なホスト名に変えるか、mail.example.com を A レコードに変えます。
5. 指す先のホストに A レコードが無い・IP が古い
MX が mail.example.com を指していても、そのホストの A レコードが無かったり、以前のサーバーの IP のままだったりすると配送できません。メールサーバーの管理画面やプロバイダーの案内に記載された IP と、dig mail.example.com A +short の結果を照らし合わせます。
6. 優先度の誤解と古いMXの残り
優先度は「数字が小さいほど優先」です。新しいメールサーバーを 20、古いものを 10 にしていると、古い方へ配送され続けます。また、使っていない古い MX が残っていると、優先側が一時的に応答しないときにそちらへ流れ、メールが行方不明になります。使っていない MX は削除してください。
7. 意図しない Null MX
0 .（値がドットだけ）の MX は RFC 7505 で定められた「このドメインはメールを受け取らない」という宣言です。テンプレートやメールを使わない設定の名残で入っていると、全メールが拒否されます。受信するドメインなら削除します。
修正の進め方と反映の確認
変更前に、現在の DNS レコードを管理画面のエクスポート機能やスクリーンショットで控えておきます。戻せる状態を作ってから編集するのが安全です。
- 時間に余裕があれば、修正前に MX の TTL を 300 秒程度に下げ、元の TTL の時間だけ待つ
- 誤った MX を修正・削除し、正しい値を登録する
- 権威ネームサーバーに直接
dig @権威サーバー example.com MXを投げて、新しい値を確認する - 外部アドレスから再度テストメールを送り、受信とバウンスの有無を見る
古い値がキャッシュされている間は、送信側によって新旧どちらかに配送されます。キャッシュが消える目安は「変更前の TTL の長さ」です。手元の PC のキャッシュを消しても、相手側のメールサーバーのキャッシュは消えないことを覚えておくと、待つべき時間を見誤りません。
ポート25への接続確認として nc -vz mail.example.com 25 などを使う方法もありますが、家庭向け回線やクラウドの一部ではポート25の外向き通信が制限されていることがあり、つながらなくても誤設定とは限りません。外部からの実際のテスト送信を最終判断にしてください。
WordPress サイトで見落としやすい点
WordPress のお問い合わせフォームや通知メールが自ドメイン宛てに届かないとき、原因が MX ではなく送信側にあることもあります。MX の修正後も WordPress からのメールだけが届かない場合は、送信元ドメインの SPF・DKIM・DMARC の設定や、SMTP 経由で送るプラグインの設定を確認してください。MX は「受信先を示すレコード」で、送信の認証は TXT レコードの担当です。
管理画面の表記や入力欄の名前はサービスごとに異なり、変更されることもあります（2026年10月現在）。迷ったときは、利用している DNS サービスの公式ヘルプで「MX レコード」の項目を確認してください。
まとめ
- MX の誤りは「編集した DNS が有効か」「名前欄」「値の書式」「指す先のホスト」「優先度」の順に確認すると早く見つかる
- 判断は管理画面ではなく、権威ネームサーバーへの dig の結果で行う
- MX の値はホスト名で、IP アドレスや CNAME は使わない。使っていない MX や意図しない Null MX は削除する
- 変更前にレコードを控え、TTL の分だけ反映を待ってから外部からのテスト送信で確かめる