初期MXTTLが悪いためにメールが返送されていませんか？
先週の金曜日の夜、メールサーバーを変更しました。 Office 365から別のHosted Exchange Solution（Intermedia.net）に移動しました。
DNSにGodaddyを使用し、サーバー移行の準備が整い、クライアントの準備が整った後、MXレコードを編集しました。 Godaddyは高速なので、1時間ほどで、whatsmydns.comで、新しい適切なMXレコードが適切に伝播されていることがわかりました。
月曜日の朝にキューに入れます。メールが届いていますが、バウンスバックについて聞き始めています。同じ火曜日の詳細。火曜日の夜にDNSエントリを目で確認したところ、髪の毛が抜けていました。新しいMXレコードのTTLは1週間です。そうです。1/ 2に変更します）今日、1つのボトルネックmessagelabs/symantec）が更新され、適切なサーバーを指すようになりましたが、残念ながら、Postiniなどの大規模な外部送信者が古いサーバーからメッセージをバウンスしています。
その最初の1週間はTTLのせいですか？Postiniはその最初のTTLが昨日短縮されたにもかかわらず、それを認識しますか？それはかなり無力に見えるので私は気が狂います。クライアントの1人のIT担当者に、チケットを開くためにPostiniに連絡してもらいました。これは、ユーザーからのメールが返送されているためですが、その前に進むには時間がかかる可能性があります。感謝祭であることが唯一の希望です。週末。金曜日の夜は、最初の不良TTLから公式の1週間になります。月曜日に「うまくいく」ことを期待できますか？他に何を確認すればよいかわかりません。ドメインは新しいO365から削除されます。 MXレコードはうまく伝播されているようです。桟橋から飛び降りようとしています。
古いサーバーを指すMXレコードのTTLが期限切れになっていることがわかるまで、古いサーバーをシャットダウンしないでください。TTL is/was 1 week then古いサーバーを1週間実行したままにして、そのMXレコードがキャッシュされている可能性のあるクライアントからの電子メールをキャッチします。
メールカットオーバーを実装するときは、計画段階で常にMXレコードを確認し、それに応じて調整してください。個人的には、MXレコードのTTLを1時間以上または1時間未満に設定する正当な理由はありません。
MXレコードの新しいTTLは、MXレコードの古いTTLとは関係ありません。したがって、古いMXレコードの場合TTLは1週間（または何でも）だったので、そのキャッシュを持っているクライアントはその期間それを保持します（残りのTTLがキャッシュにある場合）。変更したという事実は関係ありません。これらのクライアントは、キャッシュで有効期限が切れるまで、再度検索することはないからです。
あなたのシナリオはもっともらしいです。
DNSは「伝播」しません。むしろ、レコードは他のDNSサーバーによってキャッシュされます TTLの期間中です。そのため、一部のサイトでは、その古いレコードを1週間もキャッシュしている可能性があります。 （そしてbrokenDNSサーバーはそれをさらに長くキャッシュするかもしれませんが、幸いなことにそれらはほとんどありません。）