MXレコードは、そのドメイン宛てのメールをどのメールサーバーへ配送するかを示すDNSの情報です。Webサイトの表示先を決める情報とは分けて読みます。
ここでは優先度と配送先の見方、DNS以外に確認する項目を整理します。
MXの値は優先度とサーバー名で読む
MXには、配送先となる名前と優先度を設定します。優先度は小さい数値の方が優先されます。RFC 5321の配送先決定
次は説明用の仮例です。実際のメールサービスが案内する値ではありません。
| 対象ドメイン | 優先度 | 配送先の名前 |
|---|---|---|
| example.com | 10 | mail-a.example.com |
| example.com | 20 | mail-b.example.com |
この例では10の方を先に選ぶための情報になります。ただし、二つの名前を書いただけで、両方のサーバーが正しく受信・中継できる保証にはなりません。
配送先の名前をアドレスへ解決する
MXの配送先にはメールサーバーの名前を指定し、その名前をAやAAAAでアドレスへ解決します。RFC 5321のIPv6とMX
CloudflareのMX解説も、MXの配送先をCNAMEの別名にしない条件を説明しています。Web用のCNAME設定を、そのままメール配送先の設定へ転用しないようにします。
確認時は「MXが返るか」と「その配送先のアドレスを解決できるか」を別の項目にします。
優先度だけで配送結果を説明しない
同じ優先度の配送先が複数あり、特定の配送先を優先する明確な理由がない場合は、SMTPの仕様は負荷を分散するために選択をランダム化するよう定めています。一方、受信可否には接続先の状態やサービス側の設定も関わります。
仮にDNSの結果が正しくても、メールサービス側で対象ドメインや受信者を設定していなければ、目的のメールボックスへ届くとは判断できません。「MXを登録したのでメール設定は完了」とせず、受信側の準備と照合します。
変更前に確認する項目を揃える
| 確認事項 | 調べる内容 |
|---|---|
| 現行の配送先 | 公開されているMXと管理担当 |
| 新しい配送先 | サービスが指定する名前・優先度 |
| 受信側の準備 | ドメイン・アカウント・必要な受信設定 |
| 移行中の扱い | 旧側に届くメール、利用者への案内 |
| 完了の確認 | 許可された試験メールと受信結果 |
この表は変更計画の例です。配送先変更と、SPF・DKIM・DMARCなど送信や認証に関わる設定は、役割を分けて確認します。MXがあることだけで送信メールの信頼性が保証されるわけではありません。
DNSの応答とメールの受信を別々に確認する
変更後は、対象ドメインのMX、配送先の名前解決、サービス側の受信結果を順に確認します。古い応答が残る可能性はDNSのTTLとキャッシュと合わせて考えます。
名前・優先度・接続先・受信設定を対応づけると、DNS側で調べることとメールサービス側で調べることを分担しやすくなります。