MX レコード

概要

MX レコード（Mail Exchange Record） は、あるドメイン宛てのメールを受け取るサーバーのホスト名と優先度を指定する DNS レコードです。RFC 5321（SMTP）と RFC 1035 で定義されています。@example.com 宛てにメールを送ると、送信側の SMTP サーバーはまず example.com の MX レコードを引き、そこに記載されたサーバーに接続を試みます。MX レコードが存在しない場合、RFC 5321 の規定に従い A レコードへのフォールバックが行われることがあります。

MX レコードには 2 つのフィールドがあります。プリファレンス値（優先度） と エクスチェンジ（ホスト名） です。プリファレンス値が小さいほど優先して使われます。

仕組み

MX レコードはプリファレンス値とホスト名のペアで構成され、メール配送の優先順位とフォールバック先を決定します。

レコードの構造

MX レコードは次のフィールドで構成されます。

example.com.  3600  IN  MX  10  mail.example.com.

フィールド	例	説明
NAME	example.com.	メールを受け取るドメイン名
TTL	3600	キャッシュ保持時間（秒）
CLASS	IN	インターネットクラス
TYPE	MX	レコードタイプ
PREFERENCE	10	優先度。値が小さいほど優先される
EXCHANGE	mail.example.com.	メール受信サーバーのホスト名

プリファレンス値と配送の優先順位

送信側の SMTP サーバーは MX レコードのプリファレンス値が最も小さいサーバーから順に接続を試みます。最優先サーバーへの接続が失敗した場合、プリファレンス値が次に小さいサーバーに切り替えます。

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

上記の場合、mail1.example.com が最優先です。mail1 が応答しなければ、プリファレンス値 20 の mail2 または mail3 にランダムで振り分けられます（値が同じ場合はランダム選択）。

プリファレンス値自体に意味はなく、相対的な大小関係だけが重要です。10 と 20 でも 1 と 2 でも動作は同じです。ただし、一般的に 10 と 20（または 5 と 10）のような間隔を持たせておくと、後からサーバーを追加しやすくなります。

MX レコードの指定先は A レコードを持つホスト名

MX レコードのエクスチェンジフィールドには、IP アドレスを直接書けません。必ず A レコード（または AAAA レコード）を持つホスト名を指定します。また、CNAME を MX の指定先として使うことは RFC 2821 で明示的に禁じられています。

; 正しい設定
example.com.   IN  MX  10  mail.example.com.
mail.example.com.  IN  A   198.51.100.1

; 誤った設定（CNAME を MX の指定先に使っている）
example.com.   IN  MX  10  mailalias.example.com.
mailalias.example.com.  IN  CNAME  mail.example.com.

MX レコードとメール認証の関係

MX レコード自体はメール配送の経路を定めるだけですが、メールスパム対策のために SPF（RFC 7208）、DKIM（RFC 6376）、DMARC（RFC 7489）が連携します。SPF レコードは MX レコードで指定したサーバーの IP アドレスを include またはメカニズムで認証します。DMARC ポリシーが reject になっていると、SPF または DKIM の検証に失敗したメールは受信側で破棄されます。

設定例

自前のサーバー構成から Google Workspace / Microsoft 365 などの SaaS、メールを受け取らないドメインまで、代表的なパターンを示します。

シングルサーバー構成

小規模なサービスでプライマリとバックアップを 1 台ずつ持つ構成です。

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

Google Workspace での設定

SaaS のメールサービスを使う場合は、各サービスから指定された MX レコードを設定します。Google Workspace の場合は aspmx.l.google.com が最優先サーバーです。

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 での設定

Microsoft 365 では *.mail.protection.outlook.com 形式のホスト名が使われます。

example.com.  IN  MX  0  example-com.mail.protection.outlook.com.

MX レコードを持たないドメインへのメール配送

意図的にメールを受け取らないドメインは、NULL MX（RFC 7505）を設定することを推奨します。

noreply.example.com.  IN  MX  0  .

プリファレンス値 0 で SMTP ホスト名にドット（.）を指定します。これにより、送信側のサーバーが MX レコードを認識して即座に配送を中断し、スパムメールの誤送信も減らせます。

確認方法

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.

ホスト名が実際に A レコードを持っているかどうかも合わせて確認します。

dig A mail1.example.com

;; ANSWER SECTION:
mail1.example.com.	3600	IN	A	198.51.100.1

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

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

レスポンスの records.MX にプリファレンス値とホスト名が返ります。

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

よくある問題

MX レコードの設定ミスはメール配送の失敗に直結し、原因の切り分けに時間がかかるケースがあります。

MX レコードのホスト名に IP アドレスを直接書いた

MX レコードのエクスチェンジフィールドに 198.51.100.1 のような IP アドレスを設定しても、多くの実装では正しく動作しません。ホスト名を設定してそのホスト名に A レコードを設定します。

プリファレンス値が全て同じでフォールバックが機能しない

全ての MX レコードのプリファレンス値が 10 に揃っていると、送信側は等コストのサーバーとしてランダムに選択します。プライマリとバックアップの役割を持たせたいなら、値を変えて優先順位を明示します。

MX 変更後もメールが旧サーバーに届く

TTL が長い（例: 86400 秒）場合、古い MX レコードがキャッシュに残り続けます。MX レコードの変更前に TTL を 300 秒に下げ、変更後は TTL を元の値に戻します。切り替え直後は新旧両方のサーバーで受信できるようにしておくと安全です。

Google Workspace や Microsoft 365 に切り替えたが既存の MX レコードを削除し忘れた

既存の MX レコードを残したまま新しいサービスの MX レコードを追加すると、プリファレンス値によっては旧サーバーにメールが届き続けます。移行後は不要な MX レコードを必ず削除します。

MX レコードを設定したが SPF と整合していない

SPF レコードが古い IP アドレスを許可していると、新しい MX サーバーから送ったメールが受信側で SPF 不合格になります。MX レコードを変更するときは SPF レコードも同時に見直します。