この記事の目的：メールサービス移行を「MXを変更するだけ」の作業にせず、現在の送信元・受信先・認証・既存データを把握した上で、戻せる状態を保って切り替えます。
最初に現在のDNSを保存する
変更前にA、AAAA、CNAME、MX、TXT等の現在値を記録します。メールとWebサイトが同じDNSゾーンで管理されている場合、メール移行作業でWeb用レコードまで誤って変更しないよう対象を明確にします。
MXは新しい受信先を示す
MXレコードを変更すると、そのドメイン宛メールの配送先が変わります。新しいメールサービス側でユーザー、ドメイン確認、必要なライセンス等を準備してから切り替えます。優先度や複数MXの指定はサービスの公式手順に従います。
SPFは「今メールを送っているサービス」を洗い出してから変更する
通常の社員メール以外に、Webフォーム、請求システム、CRM、メール配信サービス等が同じドメインを使って送信している場合があります。新サービスだけを考えてSPFを書き換えると、既存システムのメールが認証失敗することがあります。
同一ドメインに複数のSPFポリシーが存在すると評価エラーになる可能性があります。既存値を確認し、一つのポリシーとして設計します。
DKIMはサービス側とDNS側の両方を確認する
DKIMでは、メールサービス側で署名を有効化し、公開鍵情報をDNSへ設定する流れが一般的です。DNSレコードを入れただけ、または管理画面で有効化しただけで終わらず、実際の送信メールにDKIM署名が付き検証に成功するか確認します。
DMARCはSPF/DKIMの結果を踏まえて設定する
DMARCはSPFやDKIMとの整合性を利用します。移行直後から強い拒否ポリシーへ変更する前に、正規送信元がすべて認証できているか確認します。既存DMARCを削除して移行するのではなく、現状を把握して調整します。
TTLは切替計画に関係する
DNS変更は世界中へ一斉に即時反映されるわけではなく、キャッシュの影響を受けます。切替前後にTTLをどう扱うかは、利用DNSサービスと運用条件に合わせて計画します。
旧サービスをすぐ停止しない
DNS切替後も、キャッシュや旧環境に残るメール、移行漏れの確認が必要になる場合があります。新環境で送受信、外部宛、外部からの受信、Webフォーム送信、スマートフォン等を確認してから旧サービス停止を判断します。
切替後の確認
- 外部ドメインから新アドレスへ受信できる
- 新環境からGmail等の外部宛へ送信できる
- SPF/DKIM/DMARC結果が想定どおり
- Webフォーム等の自動送信も正常
- 旧メールデータ・連絡先等の移行漏れがない