MXレコードの優先度は小さい数字が先｜同じ値・1つだけの判断

MXレコードの優先度は、数字が小さいほど先に試されます。10と20の差は待ち時間でも重みでもなく、順序だけを決めます。

診断に「MXレコードが1つだけです」または「同じ優先度のMXが複数あります」と出たときも、その数字だけで直すかどうかは決まりません。3つの状態について、それぞれ見る先を先に示します。

どの行でも、DNSに書いてある形だけでは足りません。利用中のメールサービスが公開している設定手順と見比べてください。

優先度の数字は「小さいほうから試す」という意味です

MXレコードは、優先度とホスト名の組で書きます。優先度は、複数あるときに試す順序を決める数字です。

example.jp.  IN  MX  10 mail1.example.jp.
example.jp.  IN  MX  20 mail2.example.jp.

RFC 1035 セクション3.3.9 は、この数字を「同じ名前に付いた複数のMXレコードのあいだでの優先順位を表す16ビット整数」と定義しています。同じセクションに「小さい値のほうが優先される」とあります。

送る側の動作は RFC 5321 セクション5.1 が定めています。

MX records contain a preference indication that MUST be used in sorting if more than one such record appears (see below). Lower numbers are more preferred than higher ones. （MXレコードは優先度の指定を含み、そのようなレコードが複数現れる場合は並べ替えにこれを使わなければならない。小さい数字のほうが大きい数字より優先される）

数字の間隔に意味はありません

10 と 20 でも 1 と 2 でも、順序が同じなら試される順番は変わりません。数字の差が待ち時間や重み付けを表すことはありません。数値を直接入力できる管理画面なら、メールサービスが指定した数字をそのまま入れてください。

上の引用が「そのようなレコードが複数現れる場合」と条件を付けているとおり、並べ替える相手が1件しかなければ数字は順序に関わりません。ホスト名を指すMXが1本だけなら、優先度の数字は配送順を決める役割を持ちません。

なお、優先度 0 でホスト名が .（ドット1つ）のMXが1本だけ、という形は別物です。これはNull MXという「このドメインでメールを受け取らない」宣言で、RFC 7505 セクション3 は他のMXレコードと併存してはならないと定めています。詳しくはNull MXとは？メールを受信しないドメインの設定値をご覧ください。

管理画面が数値を割り当て直すことがあります

DNSの管理画面によっては、指定した数値をそのまま保存せず、追加した順に自前の値を割り当てます。Wixは優先値を変更できないと案内しており、次の対応表を載せています（MX レコードの優先度の変更。2026-08-27に確認）。

大小の順序は保たれます。ただし、指示値で同じだった組が別々の値になります。 上の表では 5 の 2 本が 30 と 40 に、10 の 2 本が 50 と 60 に分かれています。

これは動作の違いになります。同じ優先度の宛先が複数あって、一方を選ぶ明確な理由がないとき、送る側は順序を無作為にします（後述）。値が分かれていれば、小さいほうから順に並べ替えられるので、順序は固定されます。分散させる意図で同じ値を指定していた場合、その意図は保たれません。

こうした管理画面を使っていて、指示値に同じ数字の組があるなら、利用中のメールサービスに確認してください。

1本目でメールを渡せなかったとき、次の候補も試せる必要があります

同じセクションは、送る側に代替アドレスを順に試せる実装を求めています。

To provide reliable mail transmission, the SMTP client MUST be able to try (and retry) each of the relevant addresses in this list in order, until a delivery attempt succeeds. （確実にメールを送るため、SMTPクライアントは、配送が成功するまでこの一覧の中の該当する各アドレスを順に試し、再試行できるようになっていなければならない）

候補の一覧は、MXの並びに加えて、各ホスト名が持つIPアドレスからも作られます。したがって次に試されるものは、同じホスト名の別のIPアドレスのこともあれば、同じ優先度の別のMXのことも、次の優先度のMXのこともあります。

同じセクションは、試す代替アドレスの数に設定上の上限を設けてよいとも書いています。すべてが必ず試されるとは限りません。ただし続けて「いずれにせよ、SMTPクライアントは少なくとも2つのアドレスを試すべきである」とも書いています。

MXを足すだけで届くようになるわけでもありません。足したホストが、このドメイン宛のメールを受け取って正しい宛先へ渡せる必要があります。受け取る側は、データを受け切ったことを示す 250 OK を返した時点で、そのメッセージに全面的な責任を負います（RFC 5321 セクション4.1.1.4）。予備のサーバーを自分で足すなら、利用中のメールサービスがその構成に対応しているかを先に確認してください。

同じ優先度が並んでいるとき

別々の配送先に同じ優先度が付いている状態です。仕様違反ではなく、このときの動作も定められています。

example.jp.  IN  MX  10 mail1.example.jp.
example.jp.  IN  MX  10 mail2.example.jp.

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

If there are multiple destinations with the same preference and there is no clear reason to favor one (e.g., by recognition of an easily reached address), then the sender-SMTP MUST randomize them to spread the load across multiple mail exchangers for a specific organization. （同じ優先度の宛先が複数あり、そのうち1つを選ぶ明確な理由（たとえば到達しやすいアドレスだと分かっている場合など）がないときは、送信側SMTPは、特定の組織の複数のメール交換機に負荷を分散させるため、それらを無作為に並べ替えなければならない）

無作為化が求められているのは「1つを選ぶ明確な理由がないとき」だけです。均等な分散が保証されているわけではありません。並べ替えの対象になるのも、その優先度の組の中だけです。

同じ優先度が並ぶ構成は、メールサービスが案内していることがあります。Google Workspaceを2023年より前から使っているドメインでは、aspmx で始まる複数のMXになっていることがあります。確認した一例では優先度が 1 / 5 / 5 / 10 / 10 で、同じ数字が2組ありました（2026-08-27に1ドメインで実測。ほかの旧構成が同じ並びとは限りません）。

案内どおりであれば、この表示を理由に変える必要はありません。案内と違っている場合も、すぐ直すとは限りません。上のGoogle Workspaceのように、案内の値が新しくなったあとも古い構成を引き続きサポートする、と事業者が明記していることがあります。契約と移行の状況を確かめてから決めてください。複数のサービスが関わる構成では、数字を自分の判断で入れ替えないでください。

なお、2本のMXが同じホスト名を指しているなら、優先度を分けても配送先は増えません。

この診断が見るのは優先度が重なっている組のホスト名だけで、それ以外のMXは判定に入りません。その組のホスト名がすべて、同じ数字が並ぶ構成を案内していると一次情報で確認できた事業者のものだった場合に、この項目を表示しません。照合しているのはホスト名で、本数や優先度の値が案内どおりかまでは見ていません。

MXが1本だけという表示で確かめること

本数を決めるのは利用中のメールサービスの案内です。Google WorkspaceとMicrosoft 365の現在の案内は、どちらも1本です。

Microsoftのページには日本語版もありますが、この箇所の訳が原文と逆の意味になっています。原文は「単一のMXレコードにしておくことで多くの潜在的な問題を避けられます」で、日本語版は「多くの潜在的な問題が発生する可能性があります」です（2026-08-27に確認）。この箇所については英語版を見てください。

MXが1本というだけでは、障害時の可用性は判断できません

RFC 5321 セクション5.1 は、送る側が試す配送先の一覧について次のように書いています。

When the lookup succeeds, the mapping can result in a list of alternative delivery addresses rather than a single address, because of multiple MX records, multihoming, or both. （問い合わせが成功したとき、その対応付けは、複数のMXレコード、マルチホーム、またはその両方によって、単一のアドレスではなく代替の配送先アドレスの一覧になることがある）

代替の配送先は、MXの本数からだけでなく、1つのホスト名が複数のIPアドレスを持つことからも生まれます。smtp.google.com はAを5件・AAAAを4件、microsoft.com が使っているMicrosoft 365の受信先はAを4件・AAAAを4件返しました（2026-08-27に手元の dig で確認。件数は時期や地域で変わります）。

ただし、DNSの応答だけでは、IPアドレスと機器や拠点の対応は確かめられません。件数から台数や障害の独立性を読み取ることはできません。使えるアドレスの種類も送る側の環境で決まり、同 セクション5.2 は、IPv6のみのクライアントが A レコードを引く必要はないと書いています。

参照元の多い順に並んだ一覧（Majestic Million。順位は参照しているサブネットの数を主な指標にしています）から抽出した.jpドメイン19,581件を2026-08-26に数えました。ホスト名を指すMX（Null MXを除く）を1本以上確認できたのは15,993件で、そのうち11,282件（70.5%）がMX1本でした。この11,282件の A と AAAA の件数の内訳は実測データのページにあります。無作為抽出ではないので、.jp全体の割合ではありません。

判断は、利用中のメールサービスの案内に戻ります。案内どおりであれば、そのままにしてください。

設定を確認する方法

いちばん簡単なのはMXレコードの診断にドメイン名を入れることです。本数に加えて、MXの参照先から A または AAAA を取得できたかもまとめて表示するので、応答を読み分けなくて済みます。

コマンドで確かめる場合は、+short を付けないでください。status: と各セクションが表示されず、応答の違いを区別しにくくなります。

$ dig MX example.jp

見るところは、status: の値と ANSWER SECTION にある IN MX の行です。

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; ANSWER SECTION:
example.jp.   3600  IN  MX  10 mail.example.jp.

行は「所有者名・TTL・クラス・種別・値」の順に並びます。上の例なら 3600 がTTLです。ANSWER SECTION には IN CNAME など別の種類の行が混ざることがあるので、IN MX と書かれた行だけを数えてください。

参照先のアドレスも同じように引きます。

$ dig A mail.example.jp
$ dig AAAA mail.example.jp

status: を必ず見てください。ANSWER SECTION に該当するレコードが無いとき、意味の違う状態が混ざっています。

NODATAをどう見分けるかは同 セクション2.2 が定めています。RCODEが NOERROR で、応答部に該当するレコードが無く、そのうえで権威部にSOAがあるか、NSが1つも無いか、のどちらかです。上の表の条件は、これを dig の出力の見え方に置き換えたものです。

この表は IN クラスへの問い合わせを前提にしています。dig は指定しなければ IN を引きます。

レコードが返らない下の4つは短い出力だけでは安定して区別できないので、設定を判断する前にここを見てください。

Windowsの nslookup は、問い合わせ先のアドレスなど説明の行も一緒に出します。行数をそのままアドレスの数と数えないでください。

参照先のアドレスが1件も無い場合は、参考情報ではなく修正が必要な項目として診断に出ます。

変更するときに控えておくもの

この表示を理由にMXを変える必要は、案内と一致しているならありません。食い違っていて直すことになったら、次の3つを先に済ませてください。

1. いまの値を控える。 dig MX example.jp の ANSWER SECTION を残します。優先度の数字とホスト名の末尾のドットまで含めてください。管理画面の入力欄を撮っておくのも有効です。ここを飛ばすと元へ戻しにくくなります。TTLの元の値は管理画面か権威サーバーで確認してください。dig が表示するTTLは、リゾルバのキャッシュの残り時間であることがあります
2. 別のメールサービスの外部アドレスから、テストメールを送って届くか確かめる。 同じサービスの中だけで送受信した場合、確かめたい経路を通らないことがあります
3. 反映を確かめる。 変更後に dig MX が新しい値を返した場合も、それはそのリゾルバで見えたということです。他の送り主が使うリゾルバに古い値が残っているあいだは、新旧のどちらへ届くかが分かれます。権威サーバーの値と見比べる方法はDNSの変更が反映されないときの確認方法にあります

届かない状態が続くなら、控えておいた値へ戻してください。新しいサーバー側の設定漏れがはっきりしているなら、待たずに戻してかまいません。

戻すのはMXレコードだけにしてください。SPFとDKIMは仕組みが違い、送信に使うサービスを変えていないなら触る必要がありません。変えている場合の書き換え方はメールサーバー移行のDNS切り替え手順にまとめてあります。同じ記事に、古いサーバーを解約する前に確かめることも書いてあります。

MXが1本も無い場合

この記事の主題からは外れますが、診断の表示が近いので行き先を示します。

MXを引いて空の一覧が返ったとき、その名前が優先度 0 の暗黙のMXとして扱われます。MXの参照先はアドレスレコードで引くので、結果としてその名前のアドレスが配送先になります。CNAMEを辿ってから空の一覧が返った場合、扱われるのは辿ったあとの名前です（RFC 5321 セクション5.1 の暗黙のMX）。同じセクションは、名前が存在しないという応答ならエラーとして報告し、一時的なエラーなら送信を保留して後で試す、と分けて書いています。暗黙のMXへ進むのは空の一覧が返ったときだけです。得られたIPアドレスのどれでもSMTPサーバーが待ち受けていなければ届きませんが、待ち受けている構成もあります。

• 受け取らないなら、Null MXとは？メールを受信しないドメインの設定値
• 受け取るなら、事業者別の設定ガイドから利用中のサービスを選んでMXを設定する MXはあるがその参照先が別名（CNAME）になっている場合は、MXの参照先がCNAMEではいけない理由にあります。参照先のアドレスを引けない場合は、MXの参照先が解決できない原因と直し方にあります。

暗黙のMXが働くのはMXが1本も無いときだけです。MXがあってその参照先が使えない状態でも、ドメイン名のアドレスへは戻りません（同 セクション5.1）。

まとめ

• 優先度は小さいほうから試す順序で、数字の間隔に意味はありません（RFC 5321 セクション5.1）
• ホスト名を指すMXが1本だけなら、優先度の数字は配送順を決める役割を持ちません
• 同じ数字が並んでいるとき、その組の中の順序は優先度の数字では決まりません。無作為にする義務は、送る側に一方を選ぶ明確な理由がないときに限られ、均等な分散も保証されていません
• 管理画面が数値を変換することがあります。大小の順序だけでなく、同じ数字の組がそのまま保たれているかも見てください
• IPアドレスの件数から、機器の台数や障害の独立性は判断できません

いまの設定はMXレコードの診断で確認できます。