メール配信サービスの乗り換え — 認証設定の移行手順と「消すタイミング」
最終更新: 2026-08-07
配信サービスやメールサーバーの乗り換えで起きる事故は、だいたい2種類に集約されます。「旧レコードを早く消しすぎて、移行期間中のメールが認証に落ちる」か、「解約後に消し忘れて、セキュリティホールとして残り続ける」か。つまり、勝負は設定の技術ではなくタイミングの設計です。
移行の全体像 — 「並行期間」を作る
一夜での切り替えは避け、新旧が同時に有効な並行期間を設けます。
STEP1：移行前（新サービス契約〜送信開始前）
- 新サービスのSPFを既存レコードに追記する（旧サービスの
include:は残したまま。1本のレコード内に新旧が並ぶ状態にします →統合の書き方） - 追記後のルックアップ数を確認する（新旧併記で10回制限を超えやすいタイミングです →10回制限の対策）
- 新サービスのカスタムDKIMを設定する（セレクタが旧サービスと別なので、共存できます。旧DKIMには触りません）
- 新サービスからテスト送信し、
Authentication-ResultsでSPF・DKIM・DMARCの合格を確認する（→ヘッダーの見方）
STEP2：切り替え（送信の移行）
- 配信を新サービスへ切り替える。可能なら段階的に（少量→全量）。特に送信量が多い場合、新しい送信環境の評判はゼロから育つため、急な全量移行は迷惑メール判定のリスクがあります（ウォームアップ）
- DMARCレポートで、新経路の認証合格と配信状況を確認する
STEP3：移行後（旧サービスの後始末）
- 旧サービスからの送信が完全に止まったことを確認する（レポート上で旧サービスのIPが消えるのが目安）
- 切り替え完了から2〜4週間後に、旧サービスのDNSレコードを削除する：SPFの
include:、DKIMのCNAME/TXT。すぐ消さないのは、遅延・再送メールや、忘れていた予約配信が残っている可能性があるためです - 台帳を更新する（→送信システム台帳）
なぜ「消し忘れ」が危険なのか
解約したのにレコードを残すことは、退去したテナントに合鍵を渡したままにするのと同じです。
- 旧SPFの
include:は、そのサービス経由で今も自社ドメイン名のメールを送れる状態を意味します - 委任先が失効したDKIMのCNAMEは、第三者による取得・悪用の余地になり得ます
- 使わない
include:は、SPFのルックアップ枠も無駄に消費します
「解約手続きのチェックリストにDNS削除を入れる」——この一行のルールが、将来の事故を防ぎます。
移行チェックリスト（コピー用）
- [ ] 新SPFを既存レコードに追記した（新規レコードを作っていない）
- [ ] ルックアップ数が10回以内であることを確認した
- [ ] 新サービスのカスタムDKIM（自社ドメイン署名）を有効にした
- [ ] テスト送信で3つのpassとアライメントを確認した
- [ ] 段階的に配信量を移した（ウォームアップ）
- [ ] DMARCレポートで旧経路の送信停止を確認した
- [ ] 2〜4週間後、旧SPF・DKIMレコードを削除した
- [ ] 送信システム台帳を更新した
よくある質問
Q. DMARCレコードは移行で変更が必要ですか？
A. 原則不要です。DMARCはドメインの方針宣言なので、送信サービスが替わっても1本のままです。移行中はレポートの監視頻度だけ上げてください。
Q. 差出人アドレス（From）も新サービスで変えるべきですか？
A. 変えないのが原則です。差出人ドメインを変えると、積み上げた評判がリセットされ、到達率が一時的に下がります。やむを得ず変える場合は、移行とは別のプロジェクトとして段階計画を立ててください。
Q. 旧サービスのDKIM秘密鍵は、新サービスへ持ち込めますか？
A. 持ち込まず、新サービスで新しい鍵（新セレクタ）を発行してください。鍵の使い回しはセキュリティ上の悪手です（→DKIM鍵の運用）。