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

MXレコードの優先度は、数字が小さいほど先に試されます。10と20の差は待ち時間でも重みでもなく、順序だけを決めます。
診断に「MXレコードが1つだけです」または「同じ優先度のMXが複数あります」と出たときも、その数字だけで直すかどうかは決まりません。3つの状態について、それぞれ見る先を先に示します。
| いまの状態 | 優先度の数字の役割 | 見る先 |
|---|---|---|
| ホスト名を指すMXが1本だけ | 配送先を並べ替える役割はありません | 利用中のメールサービスの案内 |
| MXが2本以上で、すべて数字が違う | 小さいほうから試されます | 同上 |
| MXが2本以上で、同じ数字が並んでいる組がある | その組の中では順序が固定されません | 同上 |
どの行でも、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に確認)。
数値が案内と違って見えるときは、まず順序が案内どおりかを確かめてください。順序が同じなら動作は変わりません。
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のこともあります。
同じセクションは、試す代替アドレスの数に設定上の上限を設けてよいとも書いています。すべてが必ず試されるとは限りません。
MXを足すだけで届くようになるわけでもありません。足したホストが、このドメイン宛のメールを受け取って正しい宛先へ渡せる必要があります。受け取る側は、DATA に対して 250 OK を返した時点で、そのメッセージを配送または中継する責任を引き受けます(同 セクション6.1)。予備のサーバーを自分で足すなら、利用中のメールサービスがその構成に対応しているかを先に確認してください。
同じ優先度が並んでいるとき
別々の配送先に同じ優先度が付いている状態です。仕様違反ではなく、このときの動作も定められています。
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になっていることがあり、優先度が2組重なります。実際に引いた出力は docs/seo/evidence/w14-mx-dig-2026-08-27.md に残してあります。
案内どおりであれば、この表示を理由に変える必要はありません。案内と違っている場合も、すぐ直すとは限りません。新規の契約向けに案内が新しくなっただけで、古い構成がそのまま動いていることがあります。契約と移行の状況を確かめてから決めてください。複数のサービスが関わる構成では、数字を自分の判断で入れ替えないでください。
なお、2本のMXが同じホスト名を指しているなら、優先度を分けても配送先は増えません。
SiteKensaは、優先度が重なっている組のホスト名がすべて、その構成を案内していると確認できたメールサービスのものだった場合、この項目を表示しません。それ以外は表示します。判別しているのはホスト名だけで、本数と優先度の並びが案内どおりかまでは見ていません。
MXが1本だけという表示で確かめること
「MXは冗長化のために複数書くもの」という説明を見かけますが、本記事で確認した2社は、どちらも1本を案内しています。
| サービス | 現在の案内 | 一次情報 |
|---|---|---|
| Google Workspace | smtp.google.com を優先度 1 で1本。2023年より前に利用を開始したドメインは aspmx で始まる複数のレコードになっていることがあり、機能しているなら変更は不要 |
MXレコードの設定手順(2026-08-26に確認) |
| Microsoft 365 | <MXトークン>.mail.protection.outlook.com を1本。複数のMXは配送の問題を招きうると書いている |
外部DNSレコードの一覧(2026-08-26に確認) |
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 365の受信サーバーはAを4件・AAAAを4件返しました(2026-08-27に手元の dig で確認。出力とホスト名を選んだ理由は docs/seo/evidence/w14-mx-dig-2026-08-27.md にあります。件数は時期や地域で変わります)。
ただし、IPアドレスの件数から機器の台数や障害の独立性は分かりません。1つのアドレスの先に複数のサーバーが並んでいることも、複数のアドレスが同じ設備を指していることもあります。使えるアドレスの種類も送る側の環境で決まり、同 セクション5.2 は、IPv6のみのクライアントが A レコードを引く必要はないと書いています。
参照元の多い順に並んだ一覧(Majestic Million。順位は参照しているサブネットの数を主な指標にしています)から抽出した.jpドメイン19,581件のうち、通常の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: を必ず見てください。応答が空に見えるとき、意味の違う状態が混ざっています。
| 応答 | 意味 |
|---|---|
NOERROR で、引いた種類の行がある |
そのアドレスが存在します。A を引いたなら IN A、AAAA を引いたなら IN AAAA の行の数がアドレスの数です |
NOERROR で、引いた種類の行が無い |
この種類のアドレスは返っていません(RFC 2308 セクション2.2 のNODATA。名前自体があるかどうかは、権威セクションの内容まで見ないと決まりません) |
NXDOMAIN |
その名前が存在しません(同 セクション2.1) |
SERVFAIL など |
調べられませんでした。存在しないという意味ではありません |
下の3つは短い出力だけでは安定して区別できないので、設定を判断する前にここを見てください。
Windowsの nslookup は、問い合わせ先のアドレスなど説明の行も一緒に出します。行数をそのままアドレスの数と数えないでください。
参照先のアドレスが1件も無い場合は、参考情報ではなく修正が必要な項目として診断に出ます。
変更するときに控えておくもの
この表示を理由にMXを変える必要は、案内と一致しているならありません。食い違っていて直すことになったら、次の3つを先に済ませてください。
- いまの値を控える。
dig MX example.jpのANSWER SECTIONを残します。優先度の数字とホスト名の末尾のドットまで含めてください。管理画面の入力欄を撮っておくのも有効です。ここを飛ばすと元へ戻しにくくなります。TTLの元の値は管理画面か権威サーバーで確認してください。digが表示するTTLは、リゾルバのキャッシュの残り時間であることがあります - 別のメールサービスの外部アドレスから、テストメールを送って届くか確かめる。 同じサービス内の自分宛の場合、外部の配送経路を通らずに届くことがあります
- 反映を確かめる。 変更後に
dig MXが新しい値を返した場合も、それはそのリゾルバで見えたということです。他の送り主が使うリゾルバに古い値が残っているあいだは、新旧のどちらへ届くかが分かれます。権威サーバーの値と見比べる方法はDNSの変更が反映されないときの確認方法にあります
届かない状態が続くなら、控えておいた値へ戻してください。新しいサーバー側の設定漏れがはっきりしているなら、待たずに戻してかまいません。
戻すのはMXレコードだけにしてください。SPFとDKIMは仕組みが違い、送信に使うサービスを変えていないなら触る必要がありません。変えている場合の書き換え方はメールサーバー移行のDNS切り替え手順にまとめてあります。同じ記事に、古いサーバーを解約する前に確かめることも書いてあります。
MXが1本も無い場合
この記事の主題からは外れますが、診断の表示が近いので行き先を示します。
MXレコードが1本も無いドメインでは、そのドメイン名自身のアドレスレコードが配送先として扱われます(RFC 5321 セクション5.1 の暗黙のMX)。そのIPアドレスでSMTPサーバーが待ち受けていなければ届きませんが、待ち受けている構成もあります。
- 受け取らないなら、Null MXとは?メールを受信しないドメインの設定値
- 受け取るなら、事業者別の設定ガイドから利用中のサービスを選んでMXを設定する
- 参照先が別名(CNAME)になっているなら、MXの参照先がCNAMEではいけない理由
暗黙のMXが働くのはMXが1本も無いときだけです。MXがあってその参照先が使えない状態でも、ドメイン名のアドレスへは戻りません(同 セクション5.1)。
まとめ
- 優先度は小さいほうから試す順序で、数字の間隔に意味はありません(RFC 5321 セクション5.1)
- ホスト名を指すMXが1本だけなら、優先度の数字は配送順を決める役割を持ちません
- 同じ数字が並んでいるとき、その組の中の順序は固定されません。均等な分散が保証されているわけでもありません
- 管理画面が数値を変換することがあります。順序が案内どおりかを見てください
- IPアドレスの件数から、機器の台数や障害の独立性は判断できません
いまの設定はMXレコードの診断で確認できます。
まずは全体を診断してみましょう
専門知識がなくてもいまの設定状況と具体的な対処方法をわかりやすく確認できます。
ドメイン設定を診断する利用中のDNS事業者が分かっているなら事業者別の設定手順から直接進めます。