MXとは

MXを読むときの前提

MX（Mail Exchanger）は、そのドメイン宛メールをどのメールサーバーへ配送するかを示すDNSレコードです。Webの接続先を示すA/AAAAとは違い、受信メールの配送経路を決めます。

実務では、MXの優先度、宛先ホスト、宛先ホストのA/AAAA、TTL、旧MX残存、SPF/DMARCとの整合、メールゲートウェイやクラウドメールサービス側の受信設定を合わせて確認します。

証跡には、対象ドメイン、MX優先度、宛先ホスト、宛先ホストのA/AAAA、TTL、権威DNS回答、利用者側DNS回答、配送ログ、確認時刻を残します。

優先度と複数MXを確認する

MXは優先度の小さい値から試されます。複数MXがある場合、平常時の主系と予備系、クラウドメールの複数宛先、旧メール基盤の残存を分けて確認します。

主系だけ正常でも、予備系が古い環境を指していると、障害時や一部送信元からの再配送で古い基盤へメールが流れます。優先度、宛先、実際の配送ログを合わせて見ます。

• MX優先度と宛先ホストをすべて保存する。
• 宛先ホストのA/AAAAも確認する。
• 旧MXや不要な予備系が残っていないか見る。

受信基盤側の準備を見る

MXを新しい宛先へ向けても、受信基盤側でドメイン受信が有効化されていなければ配送は失敗します。Microsoft 365、Google Workspace、メールセキュリティゲートウェイ、SaaSでは、所有確認、受信ドメイン、ルーティング、スパム対策設定を確認します。

配送確認ではDNS回答だけでなく、SMTP応答、受信ログ、バウンス、Message traceを残します。DNS変更とメール基盤変更を別チケットにすると責任境界が曖昧になりやすいです。

• 受信サービス側のドメイン有効化を確認する。
• SMTP応答と配送ログを保存する。
• バウンス内容とDNS回答を同じ時刻で見る。

SPF/DMARCとの関係を分ける

MXは受信先を示すレコードで、SPFは送信元を示すTXTレコードです。MXを変えてもSPFが自動で正しくなるわけではありません。メール移行では、送信基盤、受信基盤、DMARCレポートを分けて確認します。

受信基盤を切り替えると、DKIM署名やDMARC alignment、転送経路、受信側の判定も変わることがあります。MXだけを見てメール認証全体を正常と判断しません。

• 受信MXと送信SPFを混同しない。
• 移行後のAuthentication-Resultsを確認する。
• DMARCレポートで新旧送信元を確認する。

変更証跡と引き継ぎ

MX変更では、旧MX、新MX、優先度、TTL、受信サービス側設定、配送確認、戻し条件を残します。切替直後は旧MXへ配送される可能性があるため、旧環境の受信継続期間も明記します。

引き継ぎでは、正のメール受信基盤、管理画面、配送ログの見方、関連語としてDNS、TXTレコード、SPF、DKIM、DMARCを残すと確認しやすくなります。

• 新旧MXとTTLを変更記録へ残す。
• 旧受信基盤の停止日と転送条件を記録する。
• 配送ログとバウンス確認手順を残す。

関連語

同じ主要カテゴリの用語

DNS・名前解決の学習順

同じ主要カテゴリの用語をまとめて確認できます。現在の用語を起点に、前後の用語へ進むと文脈を保ったまま読み進められます。

InfraEngKit内の関連機能