MXレコード設定ミスによるメール障害事例｜メールが届かない原因と確認ポイントを解説
KoAN
目次
MXレコード設定ミスによるメール障害事例
メールシステムの障害原因として意外に多いのがDNS設定ミスです。
特にMXレコードの設定ミスは、メールの送受信に直接影響するため、企業システムでは重大な障害につながることがあります。
Webサイトは正常に表示されているにもかかわらず、メールだけ届かないというケースではMXレコードが原因になっていることも少なくありません。
本記事ではMXレコードの基本的な仕組みから、実際によく発生する設定ミスや障害事例、確認方法について解説します。
MXレコードとは
MXレコード（Mail Exchange Record）は、メールサーバの所在を示すDNSレコードです。
送信側メールサーバは、宛先ドメインのMXレコードを参照して配送先を決定します。
例えば次のような設定です。
example.com. IN MX 10 mail.example.com.送信サーバはmail.example.comへメールを配送します。
メール配送の流れ
メール送信時には次のような流れになります。
送信サーバ
↓
MXレコード確認
↓
mail.example.com
↓
Aレコード確認
↓
203.0.113.10
↓
SMTP接続
MXレコードだけでなくAレコードも重要です。
正常な設定例
example.com. IN MX 10 mail.example.com.
mail.example.com. IN A 203.0.113.10実務ではこの構成が一般的です。
障害事例① MXレコードが存在しない
非常に多いミスです。
ドメインは存在しています。
example.com
しかしMXレコードがありません。
dig example.com MX
結果です。
ANSWER: 0
メール配送できない可能性があります障害事例② MX先のAレコードが無い
次のような設定です。
example.com MX 10 mail.example.com.しかしmail.example.comのAレコードが存在しません。
送信サーバは接続先IPアドレスを取得できません。
確認方法
$ dig example.com MX
$ dig mail.example.com A両方確認する必要があります。
障害事例③ IPアドレスをMXへ直接設定
誤った設定例です。
example.com MX 10 203.0.113.10MXレコードにはホスト名を指定する必要があります。
IPアドレスは指定できません。
障害事例④ CNAMEをMXに指定する
RFC上推奨されない設定です。
example.com MX 10 mail.example.com.
mail.example.com CNAME server.example.net.動作する場合もありますが避けるべきです。
障害事例⑤ 末尾ドット忘れ
BIND運用で頻発します。
誤りです。
mail.example.com
正しくは以下です。
mail.example.com.
意図しないホスト名になる場合があります。
障害事例⑥ 優先順位逆転
MXレコードには優先順位があります。
MX 10 mail1.example.com.
MX 20 mail2.example.com.
数値が小さい方が優先です。
意図と逆になっているケースがあります。
障害事例⑦ 古いメールサーバが残る
移行時によく発生します。
MX 10 old-mail.example.com.
MX 20 new-mail.example.com.
古いサーバへ配送され続けます。
障害事例⑧ TTLによる反映遅延
MX変更直後によく発生します。
example.com. 86400 IN MX
TTLが24時間の場合です。
古いメールサーバへ配送されることがあります。
障害事例⑨ セカンダリーDNS未同期
権威DNSが複数ある場合です。
ns1
↓
新MX
ns2
↓
旧MX
送信側によって結果が変わります。
SOA確認方法
$ dig @ns1.example.com SOA example.com
$ dig @ns2.example.com SOA example.comシリアル番号を比較します。
障害事例⑩ SPFとの混同
初心者によくあります。
MXは配送先です。
SPFは送信許可サーバです。
役割が異なります。
メールが届かない時の確認手順
まずMXレコードを確認します。
$ dig example.com MX
結果例です。
example.com. MX 10 mail.example.com.次にAレコード確認
$ dig mail.example.com AIPアドレスが取得できることを確認します。
SMTPポート確認
メールサーバが応答するか確認します。
$ telnet mail.example.com 25
または
$ nc -zv mail.example.com 25Gmail配送障害時の確認
GmailではDNS設定も厳しく確認されます。
- MX
- SPF
- DKIM
- DMARC
- PTR
これらが正しく設定されているか確認します。
Google Workspace移行時の障害
移行時によく発生します。
旧MX
↓
残存
新MX
↓
追加
一部メールが旧サーバへ配送されます。
Microsoft 365移行時の障害
こちらも同様です。
旧MX削除忘れによる配送ミスが発生します。
実務で使う確認コマンド
$ dig example.com MX
$ dig mail.example.com A
$ dig example.com SOA
$ dig @8.8.8.8 example.com MXまずはこれを確認します。
実務でよくある原因ランキング
- MX先Aレコード未設定
- TTLによる反映遅延
- 優先順位設定ミス
- 旧MX削除忘れ
- セカンダリーDNS未同期
- 末尾ドット忘れ
- メールサーバ停止
実務で覚えておきたいポイント
- MXレコードは配送先を指定する
- MX先にはAレコードが必要
- 優先順位は数字が小さい方が優先
- CNAMEは避ける
- TTLを考慮する
- MX変更時は全権威DNSを確認する
まとめ
MXレコードはメール配送を支える重要なDNSレコードです。
設定ミスが発生するとメールの遅延や配送失敗につながり、業務へ大きな影響を与えることがあります。
特にMX先のAレコード、優先順位、TTL、セカンダリーDNSの同期状況は重要な確認ポイントです。
メール障害が発生した場合は、まずdigコマンドでMXレコードを確認する習慣を身につけることが重要です。
