MXレコード（Mail eXchange Record）

この用語をシェア

MXレコードとは

MXレコード（Mail eXchange Record）は、ドメイン宛のメールをどのホストが受信するかを指定するDNSリソースレコードです。RFC 1035で定義され、SMTP配送の挙動はRFC 5321で規定されています。送信側のMTA（Mail Transfer Agent、例：Postfix、Exim、Sendmail）は、宛先アドレスのドメイン部分（例：user@example.comならexample.com）についてDNSにMXレコードを問い合わせ、返ってきたホスト名の中から優先度が最も低い数値のものへ配送を試みます。

Webサイトの表示に使われるAレコード・AAAAレコードとは異なり、MXレコードは「メールの受信担当は誰か」という配送ルーティング情報だけを持ちます。ドメインを所有していても、MXレコードを設定していなければそのドメイン宛のメールは原則として受信できません（後述のNull MXは例外）。自社でメールサーバーを構築する場合はもちろん、Google WorkspaceやMicrosoft 365のようなクラウドメールサービスを利用する場合でも、DNSゾーンにMXレコードを正しく登録することが導入作業の必須項目になります。

MXレコードの構造

基本形式

# MXレコードの形式
example.com.  IN  MX  10  mail.example.com.
example.com.  IN  MX  20  mail2.example.com.

# 優先度 10 が最優先（数値が小さいほど高優先）

レコードの構成要素

要素	説明
ドメイン	メール受信対象のドメイン
優先度	10、20など（小さいほど高優先）
メールサーバー	配送先サーバーのFQDN

仕組み・詳細解説

DNS問い合わせとメール配送フロー

SMTP配送時、送信側MTAは以下の手順でMXレコードを解決してから実際の配送を行います。この一連の流れはPostfixのようなキュー型MTAでも、Sendmailのような即時配送型MTAでも基本は共通です。

1. user@sender.com が user@example.com にメール送信

2. 送信側MTAがDNS照会
   → dig example.com MX

3. MXレコード取得（優先度の低い順にソートされる）
   → 10 mail.example.com
   → 20 mail2.example.com

4. 各ホスト名をAレコード/AAAAレコードでさらに名前解決
   → mail.example.com  →  192.0.2.10
   → mail2.example.com →  192.0.2.20

5. 優先度順に配送試行（25番ポートでSMTP接続）
   → mail.example.com（優先度10）に接続・配送
   → 接続失敗やタイムアウト時のみ mail2.example.com（優先度20）にフォールバック

ここで重要なのは、MXレコードが指すのはIPアドレスではなく必ずFQDN（ホスト名）である点です。MXレコード自体は配送先の「名前」しか持たず、実際の接続先IPアドレスはそのFQDNに対するAレコード/AAAAレコードの問い合わせで別途解決します。この2段階構造のため、IPアドレスを変更してもMXレコード自体を書き換える必要がなく、運用上の柔軟性が生まれます。

優先度（Preference値）と負荷分散の仕組み

MXレコードの優先度は0〜65535の整数（16bit符号なし整数）で表現され、数値が小さいほど優先して使われます。同一優先度のレコードが複数存在する場合、多くのMTA実装ではランダムまたはラウンドロビンで配送先を選び、簡易的な負荷分散として機能します。

# 同一優先度で負荷分散する例
example.com.  IN  MX  10  mail1.example.com.
example.com.  IN  MX  10  mail2.example.com.

一方、優先度に差をつけた場合はロードバランスではなくフェイルオーバー（主系・副系）として機能します。「優先度が低い＝メイン」「優先度が高い＝バックアップ」という関係を混同しないことが実務上のポイントです。

セカンダリMXとフォールバック配送

複数のMXレコードを設定することで、メインサーバー障害時のフェイルオーバーを実現できます。ただし、セカンダリMX（バックアップMX）を用意する場合は、そのサーバーがメールを一時的にキュー（Postfixで言えばdeferredキュー）に保持し、メインサーバー復旧後に再配送できる構成になっている必要があります。単にポート25を待ち受けるだけでキューイング機構がないサーバーをセカンダリMXに指定すると、メール消失のリスクがあるため注意が必要です。

example.com.  IN  MX  10  mail1.example.com.   # メイン
example.com.  IN  MX  20  mail2.example.com.   # バックアップ（キューイング可能な構成が前提）
example.com.  IN  MX  30  mail3.example.com.   # 2次バックアップ

Null MXレコード（メール非受信の明示）

RFC 7505で定義されるNull MXは、「このドメインはメールを一切受信しない」ことをDNS上で明示的に宣言する仕組みです。配送先ホスト名として「.」（ルート、すなわち空のホスト名）を優先度0で指定します。

# Null MXの設定例（メールを受信しないドメイン用）
no-mail.example.com.  IN  MX  0  .

MXレコードを単に「未設定」にした場合、一部のMTAはドメインのAレコードにフォールバックしてメール受信を試みてしまうことがあり、意図せずメールを受信・拒否するグレーな挙動になりがちです。サブドメインや資産保有目的で取得しているだけのドメインなど、メールを扱わないドメインにはNull MXを明示的に設定しておくことで、迷惑メール業者による悪用や不要なリトライ配送を防ぐ効果があります。

具体例・ユースケース

ケース1：自社運用の小規模構成（メイン＋バックアップ）

社内でPostfix＋Dovecotによるメールサーバーを構築する典型的な構成です。物理・仮想サーバー1台を本番用に、もう1台を同一優先度またはやや高い優先度のバックアップとして用意し、可用性を確保します。

example.co.jp.       IN  MX  10  mail1.example.co.jp.
example.co.jp.       IN  MX  20  mail2.example.co.jp.
mail1.example.co.jp. IN  A   192.0.2.11
mail2.example.co.jp. IN  A   192.0.2.12

ケース2：クラウドメールサービスへの移行時のMX切り替え

オンプレミスのPostfixからGoogle Workspaceへ移行する場合、移行当日にMXレコードを一括で書き換えるのではなく、TTLを事前に短く（例：300秒程度）変更しておき、切り替え後も旧サーバーを一定期間稼働させて未反映のDNSキャッシュ経由で届くメールを取りこぼさないようにするのが実務上の定石です。

# 移行前日までにTTLを短縮
example.com.  IN  MX  300  10  mail.example.com.

# 移行当日：Google WorkspaceのMXへ切り替え
example.com.  IN  MX  1   ASPMX.L.GOOGLE.COM.
example.com.  IN  MX  5   ALT1.ASPMX.L.GOOGLE.COM.

ケース3：マルチリージョンでの冗長構成

拠点や可用性要件によっては、地理的に離れたデータセンター・クラウドリージョンにそれぞれメールサーバーを配置し、MXの優先度で「通常時に受けるリージョン」と「災害時のフォールバック先」を分けるユースケースもあります。この場合、両リージョン間でメールキューやメールボックスストレージ（Maildir等）を同期する仕組みが別途必要になる点に注意します。

ケース4：サブドメインへのメール受信委任

親会社のドメイン配下で部門ごとにメールシステムを分けたい場合、サブドメイン単位でMXレコードを個別に設定し、異なるメールサーバー（あるいは異なるクラウドメールサービス）に委任することができます。

sales.example.com.  IN  MX  10  mail-sales.example.com.
support.example.com. IN MX  10  mail-support.example.com.

メリット・デメリット

観点	メリット	デメリット・注意点
可用性	複数MX設定でメインサーバー障害時にもメールを取りこぼしにくい	セカンダリMX側にキューイング能力がないと逆にメール消失のリスクがある
柔軟性	IPアドレスの変更をMX自体の書き換えなしに吸収できる（A/AAAAレコード経由の解決）	DNS浸透（TTL経過）を待つ必要があり、切り替え直後は反映に時間差が出る
運用コスト	設定自体はゾーンファイルへの数行追加のみで完結しシンプル	設定ミス（CNAME指定、末尾ドット忘れ等）が起きやすく、影響がメール不達という形で顕在化しやすい
セキュリティ	Null MXにより「メールを扱わないドメイン」を明示し悪用や誤配送を防げる	MXレコード自体はDNSSECを導入しない限り改ざん・キャッシュポイズニングの対象になり得る

混同されやすい用語・類似技術との違い

MXレコードは他のDNSレコードや関連技術としばしば混同されます。それぞれの役割の違いを整理します。

用語	役割	MXレコードとの違い
Aレコード / AAAAレコード	ホスト名をIPv4/IPv6アドレスに変換	MXが指すホスト名を最終的にIPアドレスへ解決する側。MX単体では配送先IPは分からない
CNAMEレコード	別名（エイリアス）を正規名に転送	MXレコードの配送先ホスト名としてCNAMEを指定することはRFC上禁止されている
SRVレコード	汎用的なサービス（ホスト＋ポート）の場所を示す	SMTP専用のMXと異なり、XMPPやSIPなど任意サービスの場所指定に使う汎用レコード
PTRレコード	IPアドレスからホスト名への逆引き	MXが「宛先ドメイン→受信サーバー」を示すのに対し、PTRは「送信元IP→ホスト名」の正当性確認に使われる別方向のレコード
SPF（TXTレコード）	そのドメインを名乗ってメールを送ってよい送信元IPを列挙	MXは「メールの受信担当」、SPFは「送信の正当性検証」を担い、役割の方向が逆
メールリレー（スマートホスト）	自社MTAが外部への送信を中継させる仕組み（Postfixのrelayhost設定等）	MXは受信側の設定、リレー・スマートホストは送信側の設定であり、混同されやすいが逆方向の役割
Null MX（RFC 7505）	ドメインがメールを一切受信しないことの明示	「MXレコード未設定」とは異なり、意図的な非受信であることをDNS上で示す点が異なる

自社メールサーバー運用への応用

DNSゾーンファイル設定例

; example.com zone file
example.com.      IN  MX  10  mail.example.com.
mail.example.com. IN  A   192.0.2.10

Route 53（AWS）での設定

{
  "Name": "example.com",
  "Type": "MX",
  "TTL": 300,
  "ResourceRecords": [
    "10 mail.example.com"
  ]
}

MXレコード確認方法

# コマンドライン確認
dig example.com MX
dig +short example.com MX
nslookup -type=MX example.com

# 実際の配送経路までシミュレーションしたい場合
dig example.com MX +noall +answer
dig mail.example.com A

# オンラインツール
https://mxtoolbox.com/
https://dnschecker.org/

Postfixとの関係

Postfixで自社メールサーバーを運用する場合、MXレコードは受信側のDNS設定であり、Postfix自体の設定ファイル（main.cf）に直接MXレコードを書く項目はありません。ただし以下の関係を理解しておく必要があります。

• mydestination: 自ホストが「最終配送先」として受け取るドメイン一覧。MXレコードでこのサーバーを向いているドメインと一致している必要があります。
• relay_domains: 自ホストが中継（他サーバーへの再配送）だけを行うドメイン。セカンダリMXとして動作させる場合に設定します。
• smtp_bind_address / inet_interfaces: MXが指すIPアドレスで実際にPostfixがポート25をLISTENしているか一致させる必要があります。MXの向き先とPostfixの待受設定がずれると、DNSは正しくても接続できないという事象が起こります。

受信側ではDovecotがLMTPまたはPOP3/IMAP経由で最終的なメールボックス配送・保管を担当します。MXレコードはあくまで「どのホストのPostfix（25番ポート）にたどり着くか」を決めるだけで、そこから先のDovecotへの受け渡しはPostfix側のmailbox_transport（lmtp:unix:private/dovecot-lmtp等）の設定領域になります。

MXレコード設定のベストプラクティス

推奨設定

• 複数サーバー設定: 最低2つのMXレコード（冗長化）
• 適切なTTL: 300〜3600秒程度（変更時の柔軟性と問い合わせ負荷のバランス）。移行作業の直前だけ一時的に300秒程度まで下げるのが実務上の定石です。
• PTRレコード設定: 各メールサーバーの逆引き設定。多くの受信側MTAは送信元IPのPTRが存在しないメールを疑わしいと判定するため、MXが指すサーバー側にも正引き・逆引きの一致を確保します。
• Aレコード対応: MXレコードのFQDNは必ずAレコード（またはAAAAレコード）で解決可能にする
• 優先度の間隔: 10、20、30のように余白を持たせておくと、後から中間の優先度でサーバーを追加しやすくなります。
• SPF/DKIM/DMARCとの整合: MXレコードはメール受信経路を決めるだけで送信ドメイン認証には関与しませんが、受信側でMXを運用するなら、送信側のSPFやDKIM、DMARCも合わせて整備しておくことが実務上のセットです。

よくある設定ミス

• ❌ CNAMEの使用: MXレコードの配送先ホスト名にCNAMEを指定するのはRFC違反であり、多くの実装で正しく動作しません
• ❌ IPアドレス指定: FQDNを指定（IPアドレス直接指定不可）
• ❌ 末尾ドット忘れ: ゾーンファイルを直接編集する場合、FQDNは末尾ドット必須（mail.example.com.）。多くの管理画面型DNSサービスでは自動補完されますが、BIND形式のゾーンファイルを手編集する際は特に注意が必要です
• ❌ 自己参照: example.com → example.com（ループ発生）
• ❌ TTLの設定忘れ: 移行時にTTLが長いまま（例：86400秒＝1日）だと、切り替え後も旧サーバーへの配送が長時間続いてしまう
• ❌ 優先度の逆転: バックアップに低い優先度を設定してしまい、普段使われないはずのサーバーがメインとして扱われる

クラウドメールサービスとの連携

Google Workspace

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

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

関連ブログ記事

• Docker Mailserver完全ガイド
• メール認証技術SPF/DKIM/DMARC

まとめ

MXレコードは、メールシステムの基盤となるDNS設定です。自社メールサーバーを構築する際は、複数サーバーの設定、適切な優先度、PTRレコードとの組み合わせにより、安定したメール配送を実現できます。設定ミスはメール不達の原因となるため、DNSツールでの確認が重要です。

AIエンジニアとしての実務経験

MXレコードの重要性を痛感したのは、ドメイン移管プロジェクトでした。クライアントのメールサービスをGoogle WorkspaceからDockerベースの自社サーバーに移行する際、DNSの切り替えタイミングが非常にクリティカルでした。

移行計画では、まず新サーバーを準備し、両方のMXレコードを並行運用する期間を設けました。優先度10に新サーバー、優先度20にGoogle Workspaceを配置し、徐々にメールを新サーバーに集約していきました。DNS TTLを事前に300秒に短縮しておくことで、問題発生時の切り戻しも迅速に行えるようにしました。

興味深かったのは、一部のメールサーバーがMXレコードの優先度を無視して、複数サーバーにランダムに配送することがあったことです。RFC違反ですが、現実にはそういった挙動も考慮する必要がありました。

また、AI生成メールの到達率改善プロジェクトでは、MXレコードの調査ツールを開発しました。宛先ドメインのMXレコードを事前に解決し、SMTP接続テストを行うことで、配送前に問題を検出できるようになりました。

MXレコードの最新動向（2025年）

• Null MX（RFC 7505）: メール受信を拒否するドメインの明示的な設定方法
• DNSSEC普及: MXレコードの改ざん防止のためDNSSEC署名が推奨
• クラウドメール統合: Google/Microsoftのメール統合でMX設定が複雑化
• マルチクラウド対応: 複数プロバイダーを組み合わせた冗長化構成の普及
• IPv6対応: AAAAレコードと組み合わせたデュアルスタックMX構成

よくあるトラブルと失敗例

• CNAMEとの併用: MXレコードはCNAMEを指せない。Aレコードで解決可能なFQDNを指定
• 末尾ドットの忘れ: ゾーンファイルでFQDN末尾のドットを忘れ、相対名として解釈される
• TTL設定ミス: 長すぎるTTLで変更が反映されない。移行時は事前に短縮
• 優先度の誤解: 数値が大きいほど高優先と勘違い。小さいほど優先度が高い
• 単一MX: バックアップサーバーなしで障害時にメール損失。最低2サーバー推奨
• Aレコード設定忘れ: MXで指定したホスト名のAレコードが未設定でメール不達

権威ある外部リソース

• RFC 5321 - SMTP（MX処理を含む）
• RFC 7505 - Null MX
• MXToolbox - DNS診断ツール
• DNS Checker - 全世界からのDNS確認
• Cloudflare - MXレコード解説

よくある質問（FAQ）

この用語についてもっと詳しく

MXレコードに関するご質問や、メールサーバー構築のご相談など、お気軽にお問い合わせください。