MXレコード完全ガイド：仕組み・優先度・設定ミスの対処法と実践チェックリスト

2025年11月20日 最終更新日時 : 2025年11月20日 エバープレイ編集部

MXレコードとは何か — 基本の定義

MXレコード（Mail Exchangeレコード）は、DNS（ドメインネームシステム）に登録するリソースレコードの一つで、ドメイン宛ての電子メールを受け取るメールサーバ（MTA: Mail Transfer Agent）を指定するための情報です。SMTP（メールの送受信プロトコル）を使って他のメールサーバがメールを配信する際、送信側のMTAはまず受信ドメインのMXレコードを参照して配信先サーバを決定します。

基本動作と優先度（Preference）

MXレコードは「優先度（Preference、Priority）」と「ホスト名（Exchange host）」から成ります。優先度は数値（小さいほど高優先）で表され、同じドメインに複数のMXレコードがある場合、数値の小さいものから順に接続を試みます。もし優先度が同じMXが複数ある場合は、多くのMTAでラウンドロビンやランダムな順序で接続先を選びます。

例（ゾーンファイル形式）:

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

上記ではまず mail1.example.com（優先度10）へ接続し、失敗すると mail2.example.com（優先度20）へフォールバックします。

技術的な詳細と関連RFC

  • MXレコードの定義は歴史的にはRFC 1035（DNS）で、メール配送の仕様はRFC 5321（SMTP）で扱われています。
  • 「MXが存在しない場合」はRFC 5321に従い、送信MTAはそのドメインのA/AAAA（ホストのアドレス）レコードを使って配送を試みます（暗黙のフォールバック）。
  • RFC 2181では、MXレコードの値として指定するホスト名に関する注意点（エイリアス使用の制限など）が示されています。
  • RFC 7505は「Null MX」について規定しており、ドメインがメールを受け付けないことを明示するために「ドメイン名 IN MX 0 .」のような記述が使えます。

MXレコードとその他のDNSレコードの関係

重要な注意点：

  • MXレコードの「ターゲット（ホスト名）」は最終的にA（IPv4）またはAAAA（IPv6）で名前解決される必要があります。多くのDNS運用者・RFCは、MXのターゲットをCNAMEに向けることを推奨していません（問題を引き起こす可能性があります）。
  • MXがない場合はA/AAAAにフォールバックしますが、これは受信用であり、送信ポリシー（SPF、DKIM、DMARC）とは別です。
  • SPFレコードでは「mx」メカニズムを使うと、そのドメインのMXレコードで指定されたホストが送信を許可される送信元として扱われます。つまり、MXとSPFは連携して考える必要があります。

よくある設定ミスとその対処

  • MXのターゲットにCNAMEを設定してしまう：多くの環境で動作不良を引き起こすので、MXのターゲットは直接A/AAAAレコード（またはその名前が正しくA/AAAAを持つこと）にしてください。
  • MXターゲットに対応するA/AAAAが存在しない：配送不能になります。MXを設定したら対応するA/AAAAの存在を確認。
  • ドメイン直下のレコードで「末尾のドット」を忘れる：ゾーン管理ツールによっては相対名として解釈され違う名前が作られることがあります。管理ツールの仕様に合わせて記述を確認。
  • TTLが長すぎる：切り替えや障害対応時に影響が残ることがあります。切り替え時はTTLを短くしてから変更する運用が一般的です。
  • ポート25の遮断：クラウド環境やISPでアウトバウンド/インバウンド25番ポートが制限されているとメール配送不可になります。ファイアウォール設定やホスティングの制限を確認。

冗長化とバックアップMX

複数のMXレコードを設定することで冗長化を図れます。優先度の低い（数値が大きい）MXを用意しておけば、一次サーバがダウンしても受信を継続できます。ただし、バックアップMXを設定する場合は、バックアップ先での迷惑メール対策（スパムブロック、配信ポリシー）やローカル配送の扱いを適切に設定しておく必要があります。

Null MX（メール受け付けしないドメイン）

RFC 7505で規定される「Null MX」はドメインがメールを一切受け付けないことを明示するために使います。例：

example.com. IN MX 0 .

上記は「example.comはメールを受け付けない」と宣言します（多くのMTAはこれを見て配送を諦めます）。ただし、すべての実装が完全に対応しているわけではないため運用時は要注意です。

メール送信との違い（MXは受信用）

MXレコードはあくまで「受信」に関する情報です。送信（Outbound）に関しては、送信サーバ側でSPF（送信元の正当性）、DKIM（署名）、DMARC（ポリシー検査）を設定する必要があります。SPFには「mx」メカニズムがあり、MXで指定されたホストが送信許可ホストとして扱われますが、一般的には送信側で明示的なSPF/DKIMの設定が必要です。

検査・トラブルシューティング方法

  • MXレコードの確認コマンド（一例）:
    • dig: dig mx example.com
    • nslookup: nslookup -type=mx example.com
  • MXターゲットのA/AAAA確認: dig A mail.example.com / dig AAAA mail.example.com
  • SMTP接続確認: telnet mail.example.com 25 または nc -vz mail.example.com 25 でポート25への接続を試す
  • SMTPログの確認: 受信サーバ/送信サーバのログを確認して5xx/4xxレスポンスや接続エラーをチェック
  • 逆引き（PTR）チェック: 受信側が送信側の逆引きをポリシーに使っている場合があるため、送信ホストのPTRが正しいか確認

実務上のベストプラクティス

  • MXのターゲットには必ず対応するA/AAAAレコードを設定する。可能なら複数のアドレスで冗長化する。
  • 優先度に間隔（例：10、20、30）をつけて運用すると将来の追加・調整が楽になる。
  • MXターゲットにCNAMEを使用しない（推奨）。
  • DNS TTL運用を整える：切り替えを想定するなら事前にTTLを短く設定する。
  • メール受信に関するポリシー（SPF/DKIM/DMARC）も併せて整備する。特に外部サービス（Google Workspace、Microsoft 365など）を使う場合はプロバイダ指定のMX、SPF、DKIM手順に従う。
  • 「Null MX」を使う場合は受信を本当に行わないドメインか確認する（RFC 7505を参照）。

実例：Google Workspace（Gmail）のMX設定例

Google Workspaceを導入する場合、ドメインのMXをGoogle指定のホストに設定します（例）。Googleの実設定手順に従い、指定された複数のMXレコードを登録します。さらにSPFとDKIMを合わせて設定するのが一般的です。

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.

まとめ

MXレコードはドメイン宛メールの配送先をDNS上で指定するための重要な要素で、正しい設定と運用がメールの到達性に直接影響します。MXの構成だけでなく、A/AAAAレコードの整備、SPF/DKIM/DMARCといった送信ポリシー、ファイアウォールやISPのポート制限まで含めた総合的な設計が重要です。また、RFC（特にRFC 1035、RFC 5321、RFC 2181、RFC 7505）に従うことで互換性・安定性を保てます。

参考文献

カテゴリー
IT
前の記事
カリタ・マッティラ入門：ドラマティック・ソプラノの来歴・声質・代表レパートリー＆おすすめ名盤ガイドNew!!
2025年11月20日
次の記事
スミ・ジョー（Sumi Jo）徹底解説：声の特徴・代表レパートリーとおすすめ名盤ガイドNew!!
2025年11月20日