MXの参照先が解決できない原因と直し方｜IPアドレス直書きの修正も

結論 — 修正は必要ですが、メールが止まっているとは限りません

診断結果に「MXのホスト名が解決できません」または「MXにIPアドレスが直接指定されています」と表示された方へ。

• どちらも、MXに書いた値から配送先のIPアドレスへたどり着けない状態です。前者は名前を引いてアドレスが返らなかった状態、後者は値がホスト名になっていない状態で、仕様が求めている形にありません
• ただし、他にアドレスを取得できるMXが残っているならそちらへ配送されることがあります。この場合、いまメールが止まっているとは限りません
• アドレスを取得できるMXが1本も無い場合、確認できた設定のままでは配送先がありません

どれに当たるかは、アドレスを取得できるMXが残っているかどうかで決まります。次の節で確かめます。

自分がどの状態かを確かめる

確かめ方は、2通りあります。どちらか一方で足ります。

• 診断の表示を読む。コマンドは、要りません
• dig コマンドで自分で引く。macOSとLinuxで使えます

2つは、近い判定を出しますが同じではありません。診断は、Aの問い合わせが失敗した時点で判定を保留し、AAAAを引きません。手作業の手順は、AとAAAAの両方を引きます。

診断の表示から読む

「MXのホスト名が解決できません」「MXにIPアドレスが直接指定されています」の見出しの下には、説明文が出ます。その中に次のいずれかの文があり、それが3つの状態を分けています。ご自分の画面と見比べてください。

見出しの括弧の中には、MXが指しているホスト名が入ります (「MXのホスト名が解決できません (mail.example.jp)」の mail.example.jp の部分)。直す先は、2通りあり、そのホスト名を書いたMXを変えるか、そのホスト名のA／AAAAレコードを足すかです。どちらにするかは、下の「直し方」で分かれます。診断結果に同じ見出しが複数出ているならその本数だけ対象があります。

まだ診断を通していない場合は、MXレコードの診断にドメイン名を入れてください。

digで確かめる

ここから先は、dig コマンドを使う場合の手順です。上の表で状態が分かったなら読み飛ばして「直し方」へ進んでください。

以下は、macOSで2026年9月5日にコマンドを実行した結果です。Windowsのコマンドプロンプトに付属する nslookup では確かめていないため、この記事では表示の読み方を書きません。Windowsをお使いの場合は、上の「診断の表示から読む」で同じことが分かります。

例には gmail.com を使います。ご自分のドメイン名に置き換えて実行してください。

手順1。MXの一覧を出します。

$ dig +short MX gmail.com
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.

左の数字は、優先度です。小さいほうが、優先されます (RFC 5321 セクション5.1)。値そのものの読み方は、MXレコードの優先度は小さい数字が先にあります。右がホスト名で、この記事で確かめるのはこちらです。

192.0.2.1 のようにIPアドレスの形をした値が並んでいたら、それが「MXにIPアドレスが直接指定されています」と表示された値です。

手順2。出てきたホスト名を1つずつ引きます。

一覧に出たホスト名をAとAAAAの両方で引きます。どちらか一方でもアドレスが返れば、その宛先のアドレスは、引けています。

$ dig +short A gmail-smtp-in.l.google.com
192.178.226.26
$ dig +short AAAA gmail-smtp-in.l.google.com
2404:6800:400b:c017::1a

dig +short は、アドレスを表示できないとき0行だけを出します。名前が無いのか、その種類のレコードが無いのか、問い合わせ自体が失敗したのかは、この表示から区別できません。理由まで見るには +noall +comments を付けます。

$ dig +noall +comments +answer A 192.0.2.1
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51449
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

status: NXDOMAIN は、その名前がDNS上に存在しないという答えです。上の例は、説明用に予約されているIPアドレス 192.0.2.1 をホスト名として引いたもので、2026年9月5日に実行しました。

$ dig +noall +comments +answer A _dmarc.sitekensa.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37680
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

status: NOERROR で ANSWER: 0 は、その名前について、問い合わせた種類のレコードが返らなかったという答えです。Aで引いてこうなったならAは返らなかったことになります。アドレスが無いと言えるのはAAAAでも同じくアドレスが返らなかったときです。

status: SERVFAIL や REFUSED、そして応答そのものが返らないときは、答えが得られていません。この場合、設定が正しいとも誤っているとも判断できません。時間をおいて引き直してください。

手順3。結果を次の表で読みます。

行の並びは、「診断の表示から読む」の表と同じです。

診断も同じ区切りで判断しています。1本ずつ見て「届きません」と表示するのではなく、全部を見終えてからどれも使えないと確定したときにだけ、そう表示します。

直し方

直す前にいまのMXを全部控えてください。1本消したあとで元へ戻す必要が出たとき、控えが無いと戻せません。

控えるのはMXの一覧とその参照先のA／AAAAレコードの両方です。この記事の直し方では、どちらも変えることがあります。TTLも一緒に控えるなら、+short を外して実行してください (下の「直したあとの確認」で使います)。診断だけで進んだ場合は、DNSの管理画面でMXとA／AAAAの一覧を開き、画面を保存するか書き写してください。診断結果の「観測した内容を見る」にも値は出ますが、そこに出るのは問題があると判定された1本だけで、全部の控えにはなりません。

原因としてよくあるものを4つ挙げます。同時に当てはまることもあるので、上から順に確かめてください。

1. メールサービスが指定する値と違っている

メールサービスを乗り換えたときや設定を手で入れ直したときに起きます。

利用しているメールサービスの管理画面か公式の手順で指定されているMXの値を確認し、いまの値と見比べてください。いまの値は、DNSの管理画面のMXの一覧で見られます (直前の節で控えたものと同じです)。違うところだけを直します。

優先度: {メールサービスが指定する数字}
ホスト名: {メールサービスが指定するホスト名}

この項目について、SiteKensaは、そのまま貼れる値を作りません。正しいMXの値は、利用しているメールサービスによって決まります。DNSに公開されている情報から分かるのは「いまどうなっているか」だけで「本来どうあるべきか」は、分かりません。判断できない値を判断できたかのように出さない方針にしています。

事業者ごとの入力欄と画面の位置は、事業者別の設定ガイドにあります。

2. MXの参照先にA／AAAAレコードが無い

MXの参照先には、アドレスレコードが必要です (RFC 2181 セクション10.3)。返すのはアドレスレコードを少なくとも1つで、AとAAAAはその例として挙がっています (RFC 5321 セクション5.1)。診断の見出しに出ているホスト名をご自分で編集できるDNSで管理しているならここを足せば直ります。ご自分のドメイン名で終わっていてもそのサブドメインを別の事業者へ委任している場合は、編集する場所が変わります。

入れる値が分かる場合だけ、この方法を選んでください。以前の値をそのまま戻せるのはその値がいまも正しいと確認できたときだけです。移転して別のサーバーになっているなら古い値は使えません。

入れる値が分からないときは、下の「3. IPアドレスを直接書いている」ではなく、上の「1. メールサービスが指定する値と違っている」に戻り、いま使っているメールサービスが指定するホスト名へMXを向け直してください。

3. IPアドレスを直接書いている

MXの値がIPアドレスの形をしている場合 (192.0.2.1 など) は、そこをホスト名に置き換えます。IPアドレスは、そのホスト名のAレコードまたはAAAAレコードへ移します。

直す前
  種類 MX / 名前 @ / 優先度 10 / 値 192.0.2.1

直したあと
  種類 MX / 名前 @ / 優先度 10 / 値 mail.example.jp
  種類 A  / 名前 mail.example.jp / 値 192.0.2.1

これは項目の対応を示したもので、そのまま貼り付ける書式ではありません。欄の名前と並びは、お使いのDNS管理画面に合わせてください。

いまMXに書いてあるIPアドレスをそのままAレコードへ入れられるのはそのアドレスでメールを受け取っている場合です。移転したあとで値が古いなら上の「1. メールサービスが指定する値と違っている」に戻ってください。

メールサービスを利用しているなら自分でホスト名を決めずにそのサービスが指定するホスト名をMXに書きます。この場合、Aレコードを足す必要はありません。相手側が用意しています。

4. 使っていない古いMXが残っている

メールサービスを乗り換えたあと、前のサービスのMXを消し忘れている形です。移行が終わっているなら消してかまいません。切り替えの最中ならまだ受け取っているほうを残します。

消す前に残す側を2つ確かめてください。1つは、残すホスト名がアドレスを返すこと。もう1つは、そのホスト名がいま使っているメールサービスの指定値と一致していることです。前者だけでは足りません。アドレスが返ってもそこが受信をやめている場合があります。

この確認には、残すホスト名を名指しで引く必要があります。上の手順2と同じ形で dig +short A <残すホスト名> と dig +short AAAA <残すホスト名> を実行してください。診断が表示するのは問題のあるMXだけなので、残す側の確認には使えません。コマンドを使えない場合は、DNSの管理画面でそのホスト名のA／AAAAレコードが登録されていることを見てください。

このドメインでメールを受け取らないなら受信しないことを示すNull MXを設定する形もあります。ただしRFC 7505 セクション4.2 は、MailFromやFromに使うドメインへNull MXを公開しないほうがよいとしています。詳しくはNull MXとは？メールを受信しないドメインの設定値をご覧ください。

直したあとの確認

DNSの変更は、すぐには全ての送信側へ伝わりません。送信側が問い合わせに使うDNSサーバー (リゾルバ) に前の答えが残っており、それを何秒使い回してよいかはレコードごとのTTLで決まります。

待つ時間は、何を変えたかで違います。値を書き換えた場合 (MXの向き先を変えた、古いアドレスを直した) は、変更前に返っていた答えに付いていたTTLが目安になります。無かったレコードを足した場合 (参照先にA／AAAAを新しく作った) は、「そのレコードは無い」という答えが残る時間で、こちらはゾーンのSOAレコードが決めます (RFC 2308 セクション5)。この記事の直し方では、どちらも起きえます。

おおよその目安として、TTLが300秒なら5分、3600秒なら1時間、86400秒なら24時間です。ただしこれは上限ではありません。TTLが切れたあとも権威サーバーへ届かない間は期限切れの答えを使ってよいと定めた仕組みがあり (RFC 8767 セクション4)、その場合はさらに長くなることがあります。

設定した値そのものは、権威サーバーへ直接聞くと分かります。ふだんの dig が返すTTLは、キャッシュに残っている秒数で、設定値とは限りません。反映を確かめる手順は、DNSが反映されないときの確認方法にあります。

直したら、MXレコードの診断でもう一度確認してください。ただしDNSが直ったこととメールが届くことは別です。この記事の最後の節をご覧ください。

なぜ直すのか — 仕様が求めていること

MXに書いた名前は、アドレスを返すことが求められる

RFC 5321 セクション5.1 は、MXの応答について次のように定めています。

the data field of that response MUST contain a domain name. That domain name, when queried, MUST return at least one address record (e.g., A or AAAA RR) that gives the IP address of the SMTP server to which the message should be directed.

(その応答のデータ部は、ドメイン名を含まなければならない。そのドメイン名は、問い合わせたとき、メッセージを送るべきSMTPサーバーのIPアドレスを与えるアドレスレコード (AまたはAAAA) を少なくとも1つ返さなければならない)

IPアドレスを書くとそれがホスト名として扱われる

MXの値に書くのはドメイン名です。RFC 1035 セクション3.3.9 は、MXのデータ部を次のように定めています。

EXCHANGE A <domain-name> which specifies a host willing to act as a mail exchange for the owner name.

(EXCHANGE　そのMXレコードを置いたドメイン宛のメールを受け付ける用意があるホストを指す、ドメイン名)

そこにIPアドレスの文字列を書くとDNSの上ではその文字列がドメイン名として扱われます。192.0.2.1 を dig で引くと次の答えが返ります。

$ dig +noall +comments A 192.0.2.1
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51449

実際にMXへIPアドレスを書いていたドメインを6件選び、それぞれから値を1つずつ取ってAで引いたところ、6件ともNXDOMAINでした (2026年9月5日に確認。いずれもIPv4の表記)。RFC 1123 セクション2.1 の解説部分もこの形の名前について触れています。

a valid host name can never have the dotted-decimal form #.#.#.#, since at least the highest-level component label will be alphabetic.

(妥当なホスト名が #.#.#.# というドット区切りの十進の形を取ることは、ありえない。少なくとも最上位のラベルは、英字になるためである)

これは、ドット区切りの十進で書いた形が正しいホスト名にならないという話で、DNSがその問い合わせを拒むという意味ではありません。上の実行例のように問い合わせは行われ、その結果として「その名前は存在しない」という答えが返ります。なお、ここで確かめたのは dig の結果までです。送信側のソフトがこの値をどう扱うかは、実装によって違いえます。

一部だけ取得できないときでも直す理由

他にアドレスを取得できる宛先が残っているならいまメールが止まっているとは限りません。それでも直すのは次の2つが理由です。

1つ目は、仕様が求める形になっていないことです。MXの参照先は、問い合わせたときにアドレスレコードを少なくとも1つ返すことが求められています (RFC 5321 セクション5.1。AとAAAAが例に挙がっています)。この状態のまま放置しても直した場合と同じ配送になる保証はありません。

2つ目は、受け取れる宛先が1本減っていることです。MXが複数あるとき、送信側は配送先のアドレスを順に試せることが求められています (RFC 5321 セクション5.1)。アドレスを取得できない宛先は、その一覧に載りません。

なお、送信側が試す宛先の数に固定の決まりはありません。同じ節は、少なくとも2つのアドレスを試すべきだとしたうえで (SHOULD)、試行数に上限を設けてよいとも書いています。ただしそこで数えているのは名前解決に成功したアドレスです。アドレスを取得できないMXがその枠を消費するとは書かれていないので、「壊れたMXがあると正常なMXまで試されない」という説明はここからは導けません。

MXが壊れてもドメイン名自身のアドレスへは落ちない

MXの問い合わせが正常に空の結果を返したとき、送信側は、ドメイン名そのもののアドレス宛にメールを届けようとします。NXDOMAINや一時的なエラーで一覧を得られなかった場合は、これに当たりません。この動きを知っていると「MXが壊れてもそちらへ落ちるのでは」と考えたくなります。そうはなりません。

RFC 5321 セクション5.1 は、次のように定めています。

If one or more MX RRs are found for a given name, SMTP systems MUST NOT utilize any address RRs associated with that name unless they are located using the MX RRs; the "implicit MX" rule above applies only if there are no MX records present.

(ある名前に対して1つ以上のMXレコードが見つかった場合、SMTPシステムは、MXレコードを経由して見つけた場合を除き、その名前に結び付いたアドレスレコードを使ってはならない。上記の「暗黙のMX」の規則が当てはまるのはMXレコードが1本も存在しない場合だけである)

MXが1本でも見つかれば、この救済は、働きません。そのMXがアドレスを返すかどうかは条件に入っておらず、レコードがあるかどうかで決まります。MXを消してドメイン名自身のアドレスへ寄せる形については、Null MXとは？メールを受信しないドメインの設定値で扱っています。

実際にどれだけあるか

Majestic Millionに掲載されている .jp ドメイン20,131件に対して、SiteKensaのMXの判定を実行しました (2026年9月5日)。分母は、Null MXではないMXを1本以上持っていた16,443件です。MXが無いドメイン、Null MXのドメイン、DNSを引けずに判定できなかったドメインは、参照先が無いか確かめられないので数えていません。

内訳です。参照先のアドレスを取得できないMXがあったのは336件で、うち143件 (約43%) は他に取得できるMXを持っていました。IPアドレスを直接書いていたのは21件で、うち6件が同じ状態です。両方を持つドメインは0件だったので、149件はこの2つの和にあたります。

ここから言えるのは他に取得できる宛先が残っていることまでです。その宛先が実際にメールを受け取っているかどうかは、DNSからは分かりません。表の1行目が示すのも、アドレスを取得できるMXが少なくとも1本あることだけです。問題のあるMXを別に持つ149件もこの行に入っています。

この母集団は、リンク元のサブネット数が多い順に並んだ一覧からの抽出で、無作為抽出ではありません。.jp 全体の割合としては読めません。

測定は次の手順で再現できます。一覧の中身もDNSの応答も日々変わるため、同じ数字が出るとは限りません。

curl -sO https://downloads.majestic.com/majestic_million.csv
awk -F, 'NR>1 {print $3}' majestic_million.csv | grep -E '\.jp$' | sort -u > jp-domains.txt
npm run build
node scripts/measure-mx-usability.mjs jp-domains.txt out.json

確認できていないMXがあるとき

DNSの問い合わせに失敗するとその参照先のアドレスを取得できるかどうかを判定できません。その場合、診断は「メールサーバーのホスト名を確認できませんでした」と表示します。これは、「MXのホスト名が解決できません」とは別の表示です。

設定が正しいか誤っているかを、今回は判断できませんでした、という意味です。時間をおいてもう一度診断してください。何度試しても同じならそのホスト名を管理しているDNS事業者へ問い合わせてください。

それでも届かないとき

MXの参照先がアドレスを返すようになってもメールが届かないことがあります。DNSから分かるのは配送先のIPアドレスを取得できるかまでです。そのあとの接続と受け入れは、送信側・通信の途中・受信側のいずれでも止まりえます。

MXレコードの診断で分かるのはこの記事が扱った表示が消えたかどうかです。設定した値がお使いのメールサービスにとって正しいかどうかは、DNSからは決められません。実際に届くかどうかは、外部のアドレスからそのドメイン宛にメールを送って確かめてください。

切り分けの全体は、独自ドメインのメールが届かない原因は？で扱っています。

診断に「MXがCNAMEを指しています」も出ている場合は、MXの参照先がCNAMEではいけない理由もご覧ください。CNAMEであることを確認でき、かつその先にアドレスが無いことも確認できたときは、両方の表示が同時に出ます。

設定を直したら、ドメインの診断でまとめて確認できます。