いまメールが止まっている人向けに、前置きなしで書きます。
サーバ会社や制作会社の案内どおりに「ネームサーバー」（ドメインの設定を預けるDNSの会社）を変えた。その直後からメールが届かなくなったなら、原因はほぼ決まっていて、新しいDNSにMXレコード（このドメインあてのメールをどのサーバへ届けるか、を書いた1行）を写し忘れています。見る順番は4つ。1つ目で原因が分かることがいちばん多く、読み終えるころには直すか戻すかを決められます。
先に良い知らせを1つ。止まっていた間のメールの多くは、まだ失われていません。 手元の検証環境で、わざとMXを写し忘れてネームサーバーを切り替えてみました。メールは相手（送信側）のサーバの待ち行列に「保留」で残り、MXを直したら後から届きました。送り主にすぐエラーが返るのは、MXもAレコードも無いときだけです。だから急ぐのは犯人探しではなく、MXを直すことです。
- この記事で出来ること
- digでMXの写し忘れを見つけ、直すか戻すかを決められる。届かなかったメールが今どこにあるかが分かる
- 前提
- ドメイン登録先か新しいDNSの管理画面に入れること（入れなければ、記事末の文面で業者に頼む）。digかnslookupが打てるPC
- 所要時間
- 確認5分、MXの追加10分。反映待ちは数分〜最長2日
目次（10）
先に：新側にMXを足す。値が分からなければ戻す
新しいDNSの管理画面に入れて、入れるべきMXの値が分かっているなら、新側にMXを足すのがいちばん早い復旧です。 下の1へ進んでください。
値が分からない、レコードが多くて写し切れない、というときは、ドメイン登録先の管理画面でネームサーバーの指定を元に戻します（旧側のDNSにレコードが残っている場合）。止めたまま調べると、1時間ごとに届かないメールが増えるからです。戻しても効くまでに最長2日かかるので、私は戻したうえで、新側にも分かる範囲のMXを入れておきます。どちらに聞かれても届く状態にするのが止血です。手順は記事末の「うまくいかなかったときの戻し方」にあります。
戻せないのは、旧側のDNSをもう消した、旧事業者を解約した、の場合です。そのときは下の1で新側にMXを足します。
管理画面に自分で入れない、コマンドは打てない、という人は、調べる前に記事末の「業者に送る文面」をいま送ってください。 下の確認は、返事を待つ間にやれば足ります。
1. 新しいネームサーバーにMXがあるか
ネームサーバーを変えると、DNSの答えは新しい事業者のDNSに登録した内容だけになります。旧側のレコードは引き継がれません。
よくあるのは、サーバ会社の「ネームサーバーをこちらに変えてください」という案内どおりに進めた形です。Web用のレコードは自動で入りますが、よそのメールサービス向けのMXは入りません。サイトは表示されるので、誰も気づかないまま半日たちます。
dig +short example.com NS
dig @ns1.example.net example.com MX +noall +answer新しいDNSにMXが入っているかを確かめる2行です。見るだけで、何も変わりません。1行目で、いまのネームサーバーの名前が返ります。2行目の ns1.example.net をその名前に置き換え、新しいネームサーバーに直接聞きます。途中のサーバが覚えている古い答え（キャッシュ）の影響を受けないので、これがいちばん確かです。Windowsなら nslookup -type=MX example.com ns1.example.net です。コマンドを打てないなら、新しいDNSの管理画面のレコード一覧に、種類が「MX」の行があるかを目で見ます。同じことが分かります。
example.com. 3600 IN MX 10 mail.example.com.左から、名前、TTL（秒）、クラス、種類、優先度、メールサーバーの名前です（値は例です。example.com 自体を実際に引くと、メールを受け取らないことを示す 0 . が返ります）。優先度は小さいほうが先に使われます（RFC 5321 5.1節）。
dig @サーバ で直接聞いた結果。写し忘れはエラーではなく「NOERROR・ANSWER: 0」で返る（検証環境・撮影 2026-09-20）検証環境で、旧側と新側のネームサーバーに同じ質問をした結果です。見るのは status と ANSWER の数。写し忘れはエラーにならず、「NOERROR・ANSWER: 0」で返ります。+short や +noall +answer で何も表示されないのは、digの故障ではなくこれです。
| 結果 | 読み方 | すること |
|---|---|---|
| MXが1行も返らない | 写し忘れ。これが本命 | メールサービスが指定するMXを登録する。SPF・DKIM・DMARCのTXTも同じく消えているので一緒に入れる |
| MXが旧メールサーバーを指している | 旧側の値を写した。メールも乗り換えたのなら誤り | 新しいメールサービスの指定値に直す |
| MXの先の名前のA / AAAAが引けない | メールサーバー名の登録漏れ | dig +short mail.example.com A で確かめ、登録する |
| 正しいMXが返る | DNSは正しい | 2へ |
MXが1行も無いとき、送信側はドメイン名そのもののA / AAAAレコードの宛先へ届けようとします（RFC 5321 5.1節）。つまりメールがWebサーバへ向かいます。
Webサーバがメールの受け口（25番ポート）を閉じていれば、相手のメールサーバは配送を保留にして、数日間、再送を続けます。その間、送り主には何も返りません。 「エラーが返ってこないから届いているはず」と取引先が思い込むので、発覚が遅れます。裏を返せば、この間にMXを直せば、保留されていたメールは後から届きます。
検証環境で再現しました。MXが無くAレコードだけが返る状態で、外の送信サーバ（Postfix）から1通送っています。見るのはログの Connection refused と status=deferred（保留）です。
![MXが空でAレコードだけが返る dig の出力と、Postfixのログ「connect to example.jp[192.0.2.80]:25: Connection refused」「status=deferred」、mailqに1通残っている様子](/shots/mail-not-arriving-after-ns-change/03-fallback-to-a-deferred.webp)
lab$ grep -E "status=|connect to" /var/log/mail.log | tail -4
（中略）
Sep 20 11:08:24 client postfix/smtp[364]: connect to example.jp[192.0.2.80]:25: Connection refused
Sep 20 11:08:24 client postfix/smtp[364]: 194C540AE6: to=<info@example.jp>, relay=none, delay=0.01, delays=0/0/0/0, dsn=4.4.1, status=deferred (connect to example.jp[192.0.2.80]:25: Connection refused)
lab$ postconf maximal_queue_lifetime bounce_queue_lifetime
maximal_queue_lifetime = 5d
bounce_queue_lifetime = 5d最後の2行が、このサーバが保留を続ける日数です（Postfixの既定値。過ぎると初めて送り主に不達通知が返ります）。Gmail や Microsoft 365 など、相手のサービスごとの日数は私は確かめていません。「数日」と見てください。
送り主へ即座に不達通知が返るのは、MXも、ドメイン名のA / AAAAも無いときだけです。通知の文面はこうなります。取引先から転送してもらったエラーに Host or domain name not found とあれば、原因は相手ではなくこちらのDNSです。
残る1つは、Webサーバがメールを受けてしまう設定の場合です。エラーにも保留にもならず、誰も見ていない場所に溜まります。新しいサーバの管理画面に、作った覚えのないメールボックスや「キャッチオール」の設定が無いかを見ます。
MXの値にCNAMEの別名を書いてはいけません（RFC 2181 10.3節）。管理画面が受け付けても、AまたはAAAAを持つ名前に直します。
2. TTLがまだ残っていないか
MXは正しいのに一部の相手からだけ届かない、なら、古い答えを覚えているリゾルバ（相手の会社やプロバイダが使っている、DNSの答えを覚えておくサーバ）が残っています。TTLは、その答えを覚えていてよい秒数です（RFC 1035）。
検証環境で、ネームサーバーを切り替えた後のキャッシュDNSに15秒おきに聞きました。2列目の数字がTTLの残り秒です。0になるまで旧い答えが返り、切れた瞬間にNSが新側に変わって、MXの行が消えています。「切り替えた直後は届いていたのに、しばらくして止まった」の正体がこれです。
dig した結果。TTLが切れるまでは旧い答えが返り、切れた瞬間にMXが消える（検証環境で再現・撮影 2026-09-20）lab$ date "+%H:%M:%S"; dig +noall +answer example.jp NS; dig +noall +answer example.jp MX
11:05:36
example.jp. 111 IN NS ns1.old-dns.example.
example.jp. 111 IN MX 10 mail.example.jp.
（中略）
11:07:23
example.jp. 4 IN NS ns1.old-dns.example.
example.jp. 4 IN MX 10 mail.example.jp.
lab$ date "+%H:%M:%S"; dig +noall +answer example.jp NS; dig +noall +answer example.jp MX
11:07:38
example.jp. 120 IN NS ns1.new-dns.example.自分のドメインでは、次の2行を何度か打ちます。
dig +noall +answer example.com NS
dig +noall +answer example.com MX- 2列目の数字が、問い合わせたリゾルバが覚えている残り秒数です。繰り返すと減っていきます
- 公開リゾルバを指定すると、外からの見え方を比べられます。
dig @192.0.2.53 example.com MX（192.0.2.53 は例。確かめたい公開DNSのアドレスに置き換えます）。会社の回線とスマホの回線で答えが違えば、まだ切り替わりの途中です - NSの指定は上位（.com や .jp）のDNSにも登録されていて、そちらのTTLは自分では変えられません。1〜2日かかることがあります
この間のメールは消えていません。旧サーバのメールボックスに入っています。 旧側のWebメールを開いてください。「届かない」と思っていたメールが、そこに並んでいることがよくあります。だから、旧側のメールボックスは絶対に先に消しません。
ここで待つ以外にできることはありません。私は、メールソフトに新旧両方のアカウントを入れて、どちらに届いても読めるようにして待ちます。
MXを足したのに、digでまだ見えないとき
慌てて設定を書き換えないでください。「無い」という答えも、一定時間キャッシュされます（ネガティブキャッシュ。RFC 2308 5節）。覚えている時間は、SOAレコードの最後の数字（minimum）とSOA自身のTTLの小さいほうです。事業者の設定次第で、数分のことも1時間のこともあります。
検証環境でも、新側にMXを足した直後は、MXの代わりにSOAの行が返りました（2列目の 6 が「無い」を覚えている残り秒）。
lab$ date "+%H:%M:%S"; dig +noall +answer +authority example.jp MX
11:08:32
example.jp. 6 IN SOA ns1.new-dns.example. hostmaster.lab.example. 2026092101 3600 600 86400 60
lab$ date "+%H:%M:%S"; dig +noall +answer +authority example.jp MX
11:08:45
example.jp. 120 IN MX 10 mail.example.jp.1の dig @新NS で新側に直接聞いてMXが入っていれば、設定は済んでいます。あとは待つだけです。検証では観察のために再送を手で促しました（postqueue -f）が、実際の相手のサーバは自分の間隔で再送してきます。急ぎの相手には、電話で再送を頼むのが確実です。
3. 旧サーバ側に残した設定
「ほとんどの相手からは届くのに、自社サイトのフォームの通知だけ届かない」なら、ここです。
| 場面 | 起きること | すること |
|---|---|---|
| 旧サーバにドメインとメールアドレスの設定が残っている | 旧サーバ上のフォームやプログラムが自分あてに送ったメールが、外へ出ずに旧メールボックスに入る | 旧側のメールボックスを確認。並行期間が終わったら旧側のドメイン設定を外す |
| 旧側に転送設定が残っている | 旧側に届いた分が、意図しないアドレスへ転送され続ける | 転送先を確認して止める |
| MXが無い間に送られ、相手のサーバで保留になっている（1節） | 数日は相手のサーバが再送を続ける。送り主には何も返っていない | MXを直せば自動で届く。急ぐ相手には再送を頼む |
| 旧側のメールボックスを先に消した | 並行期間中に旧側へ届いた分は「宛先不明」で送り主に返っている。再送はされない | 心当たりの相手に再送を頼む |
サーバが自分のドメインあてのメールを外へ出さず、内部で配達してしまう動きは、レンタルサーバーで珍しくありません。どう扱われるかは事業者ごとに違うので、公式ヘルプで確かめます。旧側の設定を外す前には、旧メールボックスの中身を保存します。
→ メールを乗り換えたら過去のメールが消えた、を防ぐ。解約前にやること
4. 受信はできるが、送ったメールが届かない・迷惑メールに入る
こちらはMXではなく、TXTの写し忘れです。
dig +short example.com TXT
dig +short TXT _dmarc.example.com"v=spf1 include:_spf.example.net ~all"| 確認点 | 根拠 |
|---|---|
v=spf1 で始まる行が1つだけある。2つあると結果は permerror | RFC 7208 4.5節 |
新しいメールサービスが指定する include が入っている | 各サービスの公式ヘルプ |
DKIMの公開鍵（セレクタ._domainkey）とDMARC（_dmarc）も、ネームサーバーを変えると消えます。DMARCを reject にしていたドメインでSPFとDKIMのTXTだけ写し忘れると、自分が送るメールが全部拒否されます。 旧側で厳しく設定していた人ほど、ここを先に見てください。
→ SPF・DKIM・DMARCの3行の入れ方 ／ SPFが2行あるときの直し方
最後に、外部のアドレスとの間で送受信のテストをし、受信したメールのヘッダーで SPF / DKIM が pass になっているかを見ます。
5. 確認表
| # | 確認すること | コマンド・方法 | 済 |
|---|---|---|---|
| 1 | 新ネームサーバーが正しいMXを返す | dig @新NS example.com MX | □ |
| 2 | MXの先の名前にA / AAAAがある | dig +short mail.example.com A | □ |
| 3 | 外から見たNSが新しい側になっている | dig +short example.com NS を2つの回線で | □ |
| 4 | 旧サーバのメールボックスに新着がないか見た | 旧側のWebメール | □ |
| 5 | 旧サーバ側に残っているドメイン設定・転送を把握した | 旧側の管理画面 | □ |
| 6 | SPFが1行で、新しい送信元を含む | dig +short example.com TXT | □ |
| 7 | DKIM・DMARCのTXTが引ける | dig +short TXT _dmarc.example.com など | □ |
| 8 | 送受信テストで pass | 受信メールのヘッダー | □ |
うまくいかなかったときの戻し方
MXを足しても半日たって届かない、どの値を入れるべきか確信が持てない、なら戻します。順番はこうです。
- 新側のDNSは消さない。 入れたMXもそのまま残します。すでに新側を覚えたリゾルバが聞きに来るからです
- 旧側のDNSにレコードが残っているかを確かめる。
dig @旧NS example.com MX（旧NSの名前は旧事業者の管理画面か、契約時の案内にあります）。返らなければ、戻しても直りません。1節に戻って新側を直します - ドメイン登録先の管理画面で、ネームサーバーの指定を旧側の名前に戻す
dig +short example.com NSを会社の回線とスマホの回線で打ち、旧側に戻っていくのを見る
戻しても即座には効きません。 上位（.com や .jp）のDNSが配るNSのTTLが長く（.com は172,800秒＝2日）、新側を覚えたリゾルバはそれが切れるまで新側に聞き続けます。だから1が要ります。戻した後の2日間は、新旧どちらに聞かれてもMXが返る状態を保ってください。
戻した直後に「やはり新側で」ともう一度切り替えるのは勧めません。 リゾルバごとに覚えている答えがばらばらになり、どこで何が起きているかを追えなくなります。戻したら、2日は動かしません。
業者に送る文面
DNSの管理画面に自分で入れない（制作会社やサーバ会社が持っている）場合は、次の文面を送ります。責める文は入れません。相手が5分で動けるよう、見た事実と頼むことだけを書きます。【】を置き換えてください。dig の結果を書く2行は、打てなければ消して送って構いません。
件名: 【至急】example.com のメールが届かない件（MXレコードの追加のお願い）
【会社名】【担当者名】様
お世話になっております。【自社名】の【氏名】です。
【日付】のネームサーバー変更の後から、example.com あてのメールが届いていません。
こちらで確認した結果は次のとおりです。
・現在のネームサーバー: 【dig +short example.com NS の結果】
・上記のネームサーバーに直接問い合わせると、MXレコードが返りません
（dig @【新NS】 example.com MX → ANSWER: 0）
・メールは【利用中のメールサービス名】で受けています
お願いしたいこと
1. 新しいDNSに、次のMXレコードを追加してください
【メールサービスが指定するMXの値。不明なら「変更前のDNSにあったMXと同じ値」】
2. あわせて、変更前にあったTXTレコード（SPF・DKIM・DMARC）も写してください
3. 変更前のDNSの全レコードの一覧（ゾーンの内容）をお送りください
4. 対応が本日中に難しい場合は、ネームサーバーの指定を変更前に戻してください。
その際、新しいDNS側のレコードは消さずに残してください
対応の時刻が分かりましたら、ご一報ください。こちらで受信を確認します。3を頼むのは、MX以外にも写し忘れがあるかを自分の目で確かめるためです。前任者に聞く場合は、1〜2の代わりに「メールはどのサービスで受けていたか」「DNSの管理画面はどこの会社のものか」の2点だけを聞きます。
次に同じことを起こさないために
復旧したら、私なら次の2つを決めます。1つは、次からはネームサーバーごと変えず、いまのDNSのままレコードだけ書き換えること。写し忘れという事故の種類そのものが無くなります。もう1つは、DNSをサーバ会社のおまけではなく、DNSだけを預かるサービスか、ドメイン登録先のDNSに置くこと。サーバを替えるたびにDNSが巻き込まれる構造をやめられます。
切り替え全体の順番（TTLを前日までに下げる、旧サーバを2週間残す）は次の記事にあります。
→ サーバを乗り換えたらメールが止まった、を防ぐ。引っ越しはこの順番で動かす
出典（取得日: 2026-09-20）
- RFC 1035 Domain Names - Implementation and Specification（TTL、MX） https://www.rfc-editor.org/rfc/rfc1035.html
- RFC 2181 Clarifications to the DNS Specification（8節、10.3節） https://www.rfc-editor.org/rfc/rfc2181.html
- RFC 2308 Negative Caching of DNS Queries（5節。「無い」という答えのTTLはSOAのMINIMUMとSOAのTTLの小さいほう） https://www.rfc-editor.org/rfc/rfc2308.html
- RFC 5321 Simple Mail Transfer Protocol（5.1節） https://www.rfc-editor.org/rfc/rfc5321.html
- RFC 7208 Sender Policy Framework（4.5節） https://www.rfc-editor.org/rfc/rfc7208.html
- Postfix Configuration Parameters（
maximal_queue_lifetimeの既定値 5d） https://www.postfix.org/postconf.5.html