メールボックス移行とDNS切り替えの安全な手順

メールボックスを新しい事業者へ移行する方法（DNS切り替えガイド）

メールボックスを別のメール事業者へ移す際、円滑な切り替えと48時間の停止を分けるのはDNS戦略です。TTLの設定ミスやSPFの include 漏れは、恒久エラーによる返送や事業上の損失につながります。

必要なのは工夫ではなく、正確な順序で行う技術作業です。伝播時間を考慮し、SPF、DKIM、DMARCの認証設定を統合し、メール損失のリスクを抑えながら新しい事業者へ経路を切り替える方法を説明します。

メールデータ自体の移行については、IMAP同期ガイドをご覧ください。

メールボックス移行時にDNSがすぐ伝播しない理由

DNSは分散キャッシュシステムです。レコードを変更すると、通信事業者のDNSサーバー、Googleの 8.8.8.8、ローカルルーターなど、各再帰リゾルバーがTime-To-Live (TTL) に従って更新するのを待つ必要があります。

TTLが標準的な86,400秒（24時間）のままだと、切り替え後も一日にわたり経路が分かれることがあります。一部は新しいメールボックスに、残りは古い方に届きます。

長く残るキャッシュとネガティブキャッシュ

メールボックス移行では、次の二つの見えにくい要因が問題になります。

• 長く残るキャッシュ：TTLを下げても、世界のリゾルバーの約1から5%は60分未満の値を無視します。切り替え後約一時間は、旧事業者への残存トラフィックを想定してください。
• ネガティブキャッシュ（SOA）：新しいDKIMセレクターを早く確認するなど、レコードの作成前に問い合わせると、NXDOMAIN応答がSOAレコードの最小TTLに従って、多くの場合1時間キャッシュされます。正しいレコードを公開しても、しばらく見えないことがあります。

フェーズ1：48時間前からの準備

まだMXレコードには触れません。まず変更を受け入れられるよう環境を準備します。

手順1：TTLを下げる（48時間前）

MX、SPF (TXT)、DMARCレコードを見つけ、TTLを300秒（5分）に下げます。

これにより伝播時間を短縮できます。24時間のTTLより早く更新するリゾルバーが増えますが、世界中のキャッシュが5分で切り替わる保証はありません。

手順2：SPFを統合する（24時間前）

SPF (RFC 7208) は、ドメインを使って送信できるIPを認可します。移行中は両方の事業者を同時に認可します。

注意点：SPFのDNS参照は10回までです。Google WorkspaceとTrekMailなど二つの事業者をまとめると、上限を超えることがあります。

対処法：IP変更を継続的に反映できる対応機能がある場合に限り、レコードをフラット化します。単に入れ子の include: を直接の ip4: に置き換えると、IPが変更された際に古い値が残ります。

移行期間用レコードの例：

TrekMailでAmazon SESやSendGridなど持ち込みSMTPを使う場合は、代わりにそのSPFレコードを含めます。

手順3：DKIMを事前公開する

DKIMは google._domainkey などのセレクターを使います。新しい事業者で鍵を作る際は固有のセレクター、たとえば tm1._domainkey を使います。セレクター名を再利用してはいけません。新しいセレクターは旧事業者と競合せず、数日前から公開できます。

手順4：DMARCを一時的に緩和する

DMARCポリシーが p=reject または p=quarantine なら、24時間以上前に p=none へ変更します。切り替え直後に設定が不完全だと、認証に失敗することがあります。p=none ではRUAレポートに失敗を記録しつつ、DMARCポリシーだけを理由に拒否しませんが、配信自体を保証するものではありません。設定方法はGoogleのDMARC設定ガイドで確認できます。

フェーズ2：切り替えの実行

TTLを下げ、認証設定も統合しました。新しいホストへメール経路を移します。

手順1：権威応答と再帰応答を比較する

外部を確認する前に、権威ネームサーバーで新しいレコードが見えることを確認します。

手順2：MXレコードを更新する

可能なら新しいMXを追加して確認してから古いものを削除するか、変更を一括で行います。TrekMailの場合：

TTLは300秒のままにし、まだ戻しません。

手順3：ローカルキャッシュを消去して確認する

Windowsでは ipconfig /flushdns、macOSでは sudo dscacheutil -flushcache を使ってローカルDNSキャッシュを消去します。もう一度 dig を実行します。この操作で消えるのは端末のキャッシュだけなので、新しいMXが見えるかどうかは問い合わせ先リゾルバーにも左右されます。

フェーズ3：切り替え後の安定化

テナント帰属エラーに注意する（550 5.7.64）

Microsoft 365や同様のサービスへの移行でよくある問題です。移行先の内部ディレクトリでドメイン設定が完了していないと、「Relay Access Denied」で拒否されることがあります。MXを変更する前に、新しい事業者の画面でドメインが「Verified」または「Healthy」になっていることを確認します。

DMARCレポートを監視する（72時間）

RUAレポートを三日間確認します。

• 成功：新しい事業者のIPからのメールがSPFとDKIMに合格しています。
• 失敗：請求システムやマーケティングサービスなど正当な送信元が認証に失敗しています。SPFまたはDKIMを速やかに修正します。

後片付け（72時間後）

トラフィックが安定したら、次を行います。

1. 旧事業者からの送信が止まったことを確認し、SPFから旧事業者の include: を削除します。
2. 以前に署名されたメールを検証できる安全な期間を置いてから、古いDKIM CNAME/TXTレコードを削除します。
3. TTLを3,600s（1時間）または86,400s（24時間）に戻します。
4. 正当な送信元の認証をレポートで確認してから、DMARCを p=quarantine または p=reject にします。

メールボックス移行チェックリストの一覧

TrekMailでメールボックス移行を簡単に

DNSの手動管理ではミスが起きやすく、TXTレコードの構文ミス一つでSPFポリシー全体が無効になることもあります。

小規模事業者向け

TrekMailはリアルタイムのDNS状態チェックを提供します。管理画面から権威ネームサーバーへ問い合わせ、MX、SPF、DKIMレコードを必要な基準と照合します。検出できる構文エラーは表示され、返送が起きる前に修正できます。

独自ドメインでメールを設定する方法もご覧ください。

代理店向け

50+のドメインを管理するには標準化が欠かせません。TrekMailでは全顧客テナントに統一したDNSテンプレートを適用できます。StarterとAgencyではマネージドSMTPがIPレピュテーションと配信ヘッダーを扱うため、複雑なSPFフラット化や独自のIPウォームアップ計画は通常不要です。

代理店向けの複数ドメイン対応メールホスティングをご覧ください。

すべての有料プランには14日間の無料試用があり、カード登録が必要です。Nanoプランにはカードは不要です。

まとめ

新しい事業者へメールボックスを移す際、問題が起きやすいのはDNS切り替えです。早めにTTLを下げ、認証レコードを統合し、メンテナンス時間内にMXを変更して、DMARCレポートを72時間監視します。これが基本手順です。

DNSを手作業で調整したくない場合は、TrekMailを無料で試し、管理画面でレコードを検証できます。