MX 優先度（MX Priority）

概要

MX 優先度（MX Priority） は、MX レコードに付与される数値で、メール配送先サーバーの試行順序を決定します。RFC 1035 Section 3.3.9 では「PREFERENCE」フィールドとして定義されており、unsigned 16-bit integer で0〜65535の範囲を取ります。値が小さいほど優先度が高く、送信側の SMTP サーバーは最も小さいプリファレンス値を持つサーバーから順に接続を試みます。

この仕組みにより、プライマリサーバーとバックアップサーバーの役割分担が実現します。プライマリサーバーに障害が発生した場合、送信側は自動的に次に優先度の高いサーバーへフォールバックします。RFC 5321 Section 5 がこの動作を規定しており、SMTP によるメール配送の信頼性を支える基本的な仕組みです。

仕組み

送信側 SMTP サーバーはプリファレンス値の小さい順に接続を試み、同一値のサーバー間ではランダム選択で負荷を分散します。

プリファレンス値の評価ルール

送信側の SMTP サーバーが MX レコードを取得すると、以下の手順で配送先を決定します。

1. 全 MX レコードをプリファレンス値の昇順にソートする
2. 最も小さい値を持つサーバーに接続を試みる
3. 接続に失敗した場合、次に小さい値のサーバーに切り替える
4. 同じプリファレンス値のサーバーが複数ある場合、ランダムに1つを選択する

example.com.  IN  MX  10  mail-primary.example.com.
example.com.  IN  MX  20  mail-secondary.example.com.
example.com.  IN  MX  30  mail-tertiary.example.com.

上記の構成では、mail-primary.example.com（値 10）が最優先です。このサーバーが応答しなければ mail-secondary.example.com（値 20）に切り替わり、それも失敗すれば mail-tertiary.example.com（値 30）が使われます。

プリファレンス値の絶対値に意味はありません。10, 20, 30 と 1, 2, 3 の動作は同じです。ただし、値の間隔を空けておくと後からサーバーを追加しやすくなります。たとえば 10 と 20 の間に 15 のサーバーを挿入できます。

同一プリファレンス値によるラウンドロビン

同じプリファレンス値を持つ複数の MX レコードが存在する場合、RFC 5321 に従い送信側はランダムに1つを選択します。この動作を利用して、負荷分散を実現できます。

example.com.  IN  MX  10  mail1.example.com.
example.com.  IN  MX  10  mail2.example.com.
example.com.  IN  MX  20  backup.example.com.

この構成では mail1 と mail2 に均等にトラフィックが分散し、両方が利用できない場合にのみ backup が使われます。厳密なラウンドロビンではなく、送信側の実装に依存しますが、結果として負荷が分散される効果があります。

プリファレンス値の慣例

RFC は値の選び方を規定していませんが、実務では以下のような慣例があります。

用途	よく使われる値	説明
プライマリ	10	通常時のメール受信サーバー
セカンダリ	20	プライマリ障害時のフォールバック先
ターシャリ	30〜50	災害対策用やクラウドバックアップ

Google Workspace では 1, 5, 5, 10, 10 の値が使われています。Microsoft 365 では単一の MX レコードに 0 が設定されることが一般的です。

# Google Workspace の MX 設定
example.com.  IN  MX  1   aspmx.l.google.com.
example.com.  IN  MX  5   alt1.aspmx.l.google.com.
example.com.  IN  MX  5   alt2.aspmx.l.google.com.
example.com.  IN  MX  10  alt3.aspmx.l.google.com.
example.com.  IN  MX  10  alt4.aspmx.l.google.com.

# Microsoft 365 の MX 設定
example.com.  IN  MX  0   example-com.mail.protection.outlook.com.

Null MX とプリファレンス値 0

RFC 7505（2015年）は、メールを受け取らないドメインのために Null MX を定義しています。プリファレンス値 0 でホスト名にドット（.）を指定します。

no-mail.example.com.  IN  MX  0  .

Null MX を設定したドメインでは、他の MX レコードを併記できません。送信側のサーバーはこのレコードを検出すると配送を即座に中断し、NDR（Non-Delivery Report）を返します。プリファレンス値の 0 自体に特別な意味はなく、Null MX の構文として規定されているものです。

設定例

プリファレンス値の設定パターンを、プライマリ・バックアップ構成、負荷分散構成、サービス移行時の構成別に示します。

プライマリ + バックアップ構成

最も一般的な構成です。プライマリサーバーに障害が起きても、バックアップサーバーがメールを受信してキューに保持します。

example.com.  IN  MX  10  mail.example.com.
example.com.  IN  MX  20  backup-mail.example.com.

mail.example.com.         IN  A  198.51.100.1
backup-mail.example.com.  IN  A  198.51.100.2

バックアップサーバーは受信したメールを一時的にキューに保持し、プライマリサーバーの復旧後に転送します。バックアップサーバー自体がメールボックスを持つ必要はありません。

負荷分散 + バックアップ構成

トラフィックの多いドメインでは、同一プリファレンス値で負荷分散しつつ、別の値でバックアップを確保します。

example.com.  IN  MX  10  mail1.example.com.
example.com.  IN  MX  10  mail2.example.com.
example.com.  IN  MX  10  mail3.example.com.
example.com.  IN  MX  50  backup.example.com.

プリファレンス値 10 の 3 台が通常時のメール受信を分担し、全台障害時に backup が稼働します。

メールサービス移行時の構成

メールサービスを旧環境から新環境に移行する際、プリファレンス値を使って段階的に切り替えられます。

# Phase 1: 旧環境を優先、新環境をバックアップとして追加
example.com.  IN  MX  10  old-mail.example.com.
example.com.  IN  MX  20  new-mail.example.com.

# Phase 2: 新環境を優先に切り替え
example.com.  IN  MX  20  old-mail.example.com.
example.com.  IN  MX  10  new-mail.example.com.

# Phase 3: 旧環境を削除
example.com.  IN  MX  10  new-mail.example.com.

Phase 1 と Phase 2 の間は、新旧両方のサーバーでメールを受信できる状態を維持します。TTL を事前に短くしておくと切り替えが速くなります。

確認方法

dig で MX レコードを確認すると、プリファレンス値とホスト名がセットで表示されます。

dig MX example.com

出力の ANSWER SECTION で、各レコードのプリファレンス値を確認します。

;; ANSWER SECTION:
example.com.		3600	IN	MX	10 mail1.example.com.
example.com.		3600	IN	MX	20 mail2.example.com.
example.com.		3600	IN	MX	30 mail3.example.com.

左から順に、ドメイン名、TTL、クラス、レコードタイプ、プリファレンス値、ホスト名です。プリファレンス値が意図した優先順位になっているかを確認します。

+short オプションを使うと、プリファレンス値とホスト名だけが簡潔に表示されます。

dig MX example.com +short

10 mail1.example.com.
20 mail2.example.com.
30 mail3.example.com.

外部の視点からも確認したい場合は、Labee Dev Toolbox の DNS API を使うと、外部の視点から見た結果を取得できます。

curl "https://labee.dev/api/dns?domain=example.com&type=MX"

レスポンスの records.MX 配列に、各 MX レコードの priority（プリファレンス値）と exchange（ホスト名）が返ります。

{
  "success": true,
  "data": {
    "domain": "example.com",
    "records": {
      "MX": [
        { "priority": 10, "exchange": "mail1.example.com" },
        { "priority": 20, "exchange": "mail2.example.com" },
        { "priority": 30, "exchange": "mail3.example.com" }
      ]
    }
  },
  "error": null,
  "meta": { "responseTime": 42 }
}

priority の値が小さい順に並んでいれば、プライマリからバックアップへのフォールバック構成が正しく設定されています。

よくある問題

プリファレンス値の設計ミスや移行時の削除忘れが、メール配送の障害やセキュリティリスクにつながります。

全ての MX レコードに同じプリファレンス値を設定した

全 MX レコードのプリファレンス値を 10 に揃えると、送信側はランダムに 1 つを選択します。意図的な負荷分散であれば問題ありませんが、プライマリとバックアップの役割を持たせたい場合は値を変えて優先順位を明示します。

バックアップサーバーの設定が不十分な状態で同一値を設定すると、メールボックスを持たないサーバーにメールが配送されて受信できない事態が起きます。

バックアップ MX サーバーがスパムの中継に悪用される

バックアップ MX サーバーのセキュリティ設定が甘い場合、スパマーが意図的にプライマリを避けてバックアップに接続し、スパムメールを中継させることがあります。バックアップ MX にもプライマリと同等のスパムフィルタリングとメール認証（SPF、DKIM、DMARC）を適用します。

バックアップ MX が不要な場合は、単一の MX レコードだけを残すか、Null MX で明示的にメール受信を拒否します。

プリファレンス値の間隔が狭すぎてサーバーを追加できない

1, 2, 3 のように連番でプリファレンス値を設定すると、後から中間にサーバーを挿入できません。10, 20, 30 や 10, 50, 100 のように間隔を空けておくと、将来的なサーバー追加に対応できます。

すでに間隔が詰まっている場合は、既存の全 MX レコードのプリファレンス値を同時に変更します。プリファレンス値の変更は相対的な順序が保たれる限りメール配送に影響しないため、安全に実施できます。

メールサービス移行後に旧 MX レコードを放置する

Google Workspace から Microsoft 365 に移行した際、旧 MX レコードを削除し忘れると、プリファレンス値によっては旧サーバーにメールが届き続けます。旧サーバーが停止済みであれば配送失敗になり、メールが失われます。

移行完了後は旧 MX レコードを必ず削除し、dig MX で新しい MX レコードだけが返ることを確認します。

DNS キャッシュにより MX 変更が反映されない

MX レコードのプリファレンス値を変更しても、TTL が長い場合は DNS キャッシュに古い値が残ります。MX レコードの変更前に TTL を 300 秒程度に短縮しておき、変更後にキャッシュが入れ替わるのを待ちます。変更完了後は TTL を元の値（3600 秒など）に戻します。