同じドメインのMXレコードが何行も並び、行ごとにTTLが違ったり、同じメールサーバーが二重に登録されていたりする場合は、MXを「1つの名前に対する1組の情報」として整理し直すことで解消できます。手順は、権威ネームサーバーで今の状態を正確に見る、残す行と消す行を決める、TTLを1つの値にそろえる、反映を確かめる、の4段階です。この記事では、重複や不一致がなぜ起きるのか、どれが問題でどれが問題でないのかを見分けたうえで、安全に整理する方法を説明します。
MXの「重複」と「TTLの不一致」は何が問題なのか
DNSでは、同じ名前・同じ種類のレコードの集まりを1つのまとまり（RRset）として扱います。example.com のMXが2行あれば、それは2件のMXを含む1つのRRsetです。
このまとまりについて、DNSの仕様（RFC 2181）は「同じRRsetに含まれるレコードのTTLは同じ値にする」と定めています。行ごとにTTLが違う状態は仕様に合っておらず、受け取った側は最も短いTTLにそろえて扱うことが求められています。つまり、片方の行だけTTLを長くしても、その長さは期待どおりには効きません。DNSサーバーのソフトウェアによっては、読み込み時に警告を出して1つの値にそろえるものもあります。
重複については、次の3つを区別すると整理しやすくなります。
- まったく同じ行が2つある（優先度もホスト名も同じ）: DNSの仕組みでは同じレコードは1件として扱われるため意味がなく、管理画面上の混乱のもとになるだけです。
- 同じホスト名が別の優先度で2回登録されている（例:
10 mail.example.comと20 mail.example.com）: 1台目が応答しないとき、同じサーバーに再送するだけなので冗長化になっていません。 - 別のホスト名が同じ優先度で並んでいる: 送信側が両方に振り分けるための設定で、意図したものなら問題ありません。
3つ目は重複ではなく正しい構成の場合があります。消す前に、それぞれの行が何のためにあるのかを確かめることが大切です。
権威ネームサーバーで今の状態を正確に見る
TTLの確認では、普段使っているキャッシュDNSの答えをそのまま信じないことが大事です。キャッシュDNSが返すTTLは「残り時間」なので、問い合わせるたびに減っていき、設定値とは一致しません。設定値を見るには、権威ネームサーバーに直接問い合わせます。
# ドメインの権威ネームサーバーを調べる
dig example.com NS +short
# 権威ネームサーバーに直接MXを問い合わせる（設定どおりのTTLが返る）
dig @ns1.example-dns.jp example.com MX +norecurse +noall +answer
# 比較用：キャッシュDNSの答え（TTLは残り時間）
dig example.com MX +noall +answer出力の2列目がTTLです。権威ネームサーバーの答えで行ごとにTTLが違っていれば、不一致が設定に残っています。
NSが複数ある場合は、すべてのネームサーバーに同じ問い合わせをして結果を並べます。
for ns in $(dig example.com NS +short); do
echo "== $ns"
dig @"$ns" example.com MX +norecurse +noall +answer
doneネームサーバーによってMXの行数や値が違う場合、重複の原因は「同じDNSサービスの中に余分な行がある」のではなく、「NSに別々のDNSサービスが混ざっていて、それぞれに違うMXが入っている」ことかもしれません。この場合はどちらか一方の管理画面を直しても解消しないので、NSの構成から見直します。
重複と不一致が生まれやすい場面
原因が分かると、直したあとに再発させない手当てもできます。よくあるのは次の場面です。
- メールサービスの乗り換え時に古いMXを消し忘れた: 新旧のMXが並び、優先度の低い旧サーバーに一部のメールが届き続けることがあります。
- 行ごとにTTLを入力するDNS管理画面で、追加した行だけTTLを変えた: レコードを1行ずつ登録する画面では、同じ名前のMXでも別々のTTLを入力できてしまいます。
- メールサービスの案内どおりに追加したら、既存の行と同じ内容だった: 画面の入力欄の違い（末尾のドットの有無、ホスト名欄の
@と空欄の違い）で、別の行に見えて実は同じという例もあります。 - ゾーンファイルを手で編集した: 行ごとにTTLを書く書き方と、
$TTLの既定値に任せる書き方が混ざると、同じ名前のMXでTTLがずれます。
なお、Amazon Route 53 のようにTTLを「レコードの組」に対して1つだけ設定するDNSサービスでは、同じ組の中でTTLが食い違うことは起こりません。また同じ値を同じ組に二重に入れようとすると、登録時にエラーになるのが一般的です。不一致や重複が起きやすいのは、主に1行ずつ登録する管理画面と、手書きのゾーンファイルです。
残す行と消す行を決める
整理を始める前に、現在のMXの一覧（優先度・ホスト名・TTL）を控えておきます。DNSサービスによってはゾーンのエクスポート機能があるので、使える場合は書き出しておくと元に戻すときに役立ちます。
そのうえで、次の基準で残す行を決めます。
- 今メールを受けているサービスの案内にあるMXだけを残す（Google Workspace や Microsoft 365 などは、それぞれの管理画面やヘルプに現在のMX値が載っています）
- 同じホスト名が複数の優先度で並んでいたら、案内にある優先度の1行だけにする
- 旧サービスのMXは、旧サービス側で受信を止める時期と合わせて消す。すぐ消せない場合は、優先度を新サービスより低くして、いつ消すかを決めておく
- メールを受け取らないドメインで「MXが無い」ことを明示したい場合は、RFC 7505 のNull MX（
0 .）を1行だけ置きます。Null MXは他のMXと並べてはいけないので、併用している行があれば整理します
MXの宛先にはホスト名を書き、IPアドレスやCNAMEの名前は書きません。宛先のホスト名にA（IPv6も使うならAAAA）があることも、このとき合わせて確かめておきます。
TTLを1つの値にそろえる
TTLの値は、変更の予定に合わせて決めます。
- 当面変更の予定がない: 3600秒（1時間）前後が扱いやすい値です。DNSサービスの既定値に任せてもかまいません。
- 近いうちにメールサービスを移す: 移行の1〜2日前までに300秒程度へ下げ、移行後に落ち着いたら元に戻します。
大切なのは値の大小よりも、同じ名前のMXすべてに同じTTLを付けることです。管理画面で1行ずつTTLを入力する方式なら、すべての行を同じ値に書き換えます。TTLを下げる場合、新しいTTLが効き始めるのは、古いTTLの分の時間が過ぎてからです。今のTTLが86400秒（1日）なら、下げた設定が各地のキャッシュに行き渡るまで最大1日かかります。
BINDなどでゾーンファイルを管理している場合は、MXの行にTTLを明記してそろえ、SOAのシリアル番号を上げてから読み込み直します。
; 修正前：TTLがばらばらで、同じホストが二重に登録されている
example.com. 3600 IN MX 10 mx1.example.net.
example.com. 300 IN MX 20 mx2.example.net.
example.com. 3600 IN MX 30 mx1.example.net.
; 修正後：TTLを3600にそろえ、重複した行を削除した
example.com. 3600 IN MX 10 mx1.example.net.
example.com. 3600 IN MX 20 mx2.example.net.# 書式を確認してから読み込み直す（パスは環境に合わせて変更）
named-checkzone example.com /etc/bind/zones/example.com.zone
sudo rndc reload example.comnamed-checkzone でエラーや警告が出たら、読み込む前に内容を直します。ゾーンファイルを編集する前には、元のファイルをコピーしてバックアップを取っておきます。
反映を確かめる
修正後は、まず権威ネームサーバーの答えが意図どおりかを、すべてのNSについて確かめます。先ほどの for ループをもう一度実行し、行数・優先度・ホスト名・TTLがすべてのネームサーバーで同じになっていれば、設定側の作業は完了です。
キャッシュDNSの答えが新しくなるのは、古い答えのTTLが切れてからです。Google Public DNS（8.8.8.8）やCloudflareの1.1.1.1など、複数の公開DNSに問い合わせて変化を見ます。
dig @8.8.8.8 example.com MX +noall +answer
dig @1.1.1.1 example.com MX +noall +answer最後に、外部のメールアドレスから実際にメールを送り、受信できるかを確かめます。受信したメールのヘッダーにある Received の行を見ると、どのサーバーを経由して届いたかが分かるので、消したはずの旧サーバーを通っていないかも確認できます。
整理したあとに再発させないために
MXの変更は、受信の停止につながりやすい作業です。次の点を運用のルールにしておくと、同じ状態に戻りにくくなります。
- MXを触るときは、作業前の一覧を残し、作業後に権威ネームサーバーで一覧を取り直して見比べる
- メールサービスを乗り換えたら、旧MXを消す日を決めて記録しておく
- 1行ずつTTLを入力する管理画面では、同じ名前のMXを追加・変更するたびに、他の行のTTLも同じかを見る
- MXと一緒に、SPF（TXT）やDKIMの設定も新しいメールサービスのものに切り替わっているかを確かめる
DNSサービスの画面構成や入力欄の名前はサービスごとに違い、更新で変わることもあります（2026年10月現在）。この記事の手順は、画面の表記ではなく「権威ネームサーバーで何が返っているか」を基準に進めると、どのサービスでも同じ考え方で使えます。
まとめ
- 同じ名前のMXは1つのRRsetとして扱われ、TTLは全行で同じ値にするのが仕様です。行ごとに違うと、短い方にそろえて扱われます。
- まったく同じ行や、同じホストを別の優先度で重ねた行は削除の対象です。別のホストを同じ優先度で並べた行は、意図した構成なら残します。
- 確認は権威ネームサーバーに直接問い合わせ、NSが複数あればすべてで同じ結果になるかを見ます。
- 残すMXは、今使っているメールサービスの案内に合わせて決め、旧サービスのMXは受信を止める時期と合わせて消します。
- 修正後は公開DNSと実際のメール送信で反映を確かめます。