2つのプラットフォームを並行して稼働させます。
よくある欠落は、コピーが不完全なままMXを切り替えた場合や、複合機、ウェブサイト、CRMが古い認証情報で送信を続けている場合に生じます。
MXはDNSレコードであり、自社ドメイン宛てのメールをどこに配送すべきかを送信側のサーバーに示します。メール（メールサービス）を切り替えるということは、まずこの配送先を変更することです。それ以外のもの（アカウント、履歴、端末）は、その周辺で準備します。
SMTPプロトコルは、短時間の障害には十分に耐えられます。一時的なエラーを受け取った送信側のサーバーは、メッセージをキューに保持し、後で再送を試みます。したがって、サーバーに一時的に接続できなくても、メールが失われることはありません。一方、恒久的なエラー（存在しないメールボックス、拒否されたメッセージ）が発生すると、メッセージは送信者に返送され、そのメッセージが自然に届くことはありません。切り替えの主なリスクは障害ではなく、エイリアスやメーリングリストが作り直されていないために、新しいプラットフォームが受信者を拒否してしまうことです。
TTL（有効期間）は、DNSリゾルバーが応答をどれだけの時間キャッシュに保持できるかを定めるものです。その間、一部の送信者は引き続き古いプラットフォームに配送します。これは正常なことであり、そのために古いプラットフォームは移行期間中も受信できる状態にしておく必要があります。
2週間前。 メールボックス、エイリアス、メーリングリスト、共有メールボックス、そしてメールを送信するすべてのアプリケーションの棚卸し。切り替え当日に速やかに反映されるよう、MXのDNSのTTLを短い値（多くの場合300秒）に下げる。移行先アカウントの作成。履歴の1回目のコピー。
TTLを早めに下げるのは、古い値を読み込んだリゾルバーがその有効期限まで値を保持するためです。短いTTLは、古いキャッシュが期限切れになって初めて有効になります。一方、1回目のコピーは最も時間がかかります。早めに開始すれば、問題のあるメールボックスを見つけるための時間を確保できます。
数日前。 サンプルの確認。メッセージ数、フォルダーまたはラベル、予定、連絡先。サンプルの確認で問題があれば方法を修正。モバイル端末とOutlook向けの手順書の準備。新しいプラットフォームでSPF、DKIM、DMARCがすでに有効な状態で、移行先からGmailおよびOutlook.comへの送信テスト。これらのレコードは、MXより前に公開できます。
具体的には、移行期間中は両方のプラットフォームを許可する1つのSPFレコード（SPFレコードを2つに分けると検証が失敗します）、古い鍵と並べて独自のセレクターのもとで公開した新しいプラットフォームのDKIM鍵、そして見直し済みのDMARCポリシーです。DMARCは、メッセージが送信者のドメインの名義でSPFまたはDKIMによって認証されていることを求めます。ポリシーが厳格で、移行先がまだ許可されていない場合、相手先は自社のメッセージを拒否します。
前日。 2回目のコピー。1回目のコピー以降に届いたものだけをコピーする。エイリアスとメーリングリストの変更を凍結する。
当日。 MXの切り替え。ただちに外部から確認する。外部の個人メールボックスから送ったメールが、TTLの期間内に新しいプラットフォームに届く必要がある。キューの監視。送信を行うアプリケーションの再設定。社内ヘルプデスクの担当者を決め、重要なフローが失敗した場合にMXを元に戻す権限を与えておく。
autodiscoverレコードがある場合は、同時に変更してください。Outlookはこのレコードを照会して自分のサーバーを見つけます。古いプラットフォームを指したままのセカンダリMXも削除してください。プライマリMXに接続できない送信者は、次のMXを試すからです。
その後の数日間。 古いプラットフォームは読み取り専用とする。差異（不足しているフォルダー、共有メールボックス）の報告。必要に応じて対象を絞った3回目のコピー。その後、従業員が2か所から返信しないよう、古いプラットフォームからの送信を停止する。
この最後の点には技術的な理由があります。古いプラットフォームは、引き続き自社ドメインを自らの管理下にあるものとみなします。古いプラットフォームから同僚に送られたメッセージは、MXを参照せずにその中でローカルに配送されます。同僚がそのメッセージを新しいメールボックスで目にすることはありません。
| リスク | 起こること | 対策 |
|---|---|---|
| MXの切り替えが早すぎる | 新着メールは届くが、履歴が欠けている | サンプルの確認と2回目のコピーの後に切り替える |
| エイリアスやメーリングリストの見落とし | 移行先がこれらのメッセージを恒久的に拒否する | 棚卸し、前日のエイリアス凍結、共用アドレスのテスト |
| SPF、DKIM、DMARCの不備 | 相手先で自社のメッセージが拒否されるか、迷惑メールに振り分けられる | 切り替え当日より前に公開し、実際のメッセージで確認する |
| 古いアカウントで送信するアプリケーション | 請求書、アラート、スキャンが送信されなくなる | アプリケーションの一覧を作成し、当日に新しいSMTPサーバーを設定する |
| 古いプラットフォームで送信が可能なまま | 社内メッセージが古いシステムに残る | サンプルの確認が済み次第、送信を停止する |
| 切り戻しの準備不足 | MXは元に戻るが、その間に受信したメッセージは移行先に残る | それらのメッセージの回収を含む計画を文書化する |
説明のために、従業員40名の事務所を考えてみましょう。この事務所は、金曜日ではなく木曜日の終業時に切り替えることを選びます。翌日にはチームが出社して差異に対応でき、社内ヘルプデスクも丸1営業日を使えるからです。受付にある、メールにスキャンを送る複合機は、その日の夜のうちに再設定します。2つの共有メールボックスでフォルダーの不足が報告された場合は、対象を絞ったコピーで補完します。このシナリオでは、メッセージは1通も失われませんが、何人かの従業員は電話でアカウントを設定し直す必要があります。これが、事前に告知しておくべき目に見える部分です。
従業員は、Outlookまたはモバイル端末でサーバーを切り替えます。大容量のメールボックスの初回読み込みには時間がかかります。プロファイルを適切に作り直さないと、電話にすでにキャッシュされているメッセージが重複することがあります。サーバー設定をその場しのぎで変更するのではなく、「アカウントを削除して作り直す」手順を用意してください。
Outlookについても理由は同じです。プロファイルには、古いサーバーに結びついたローカルキャッシュが残っています。新しいプロファイルはクリーンな状態から始まりますが、変更した古いプロファイルでは2つの環境が混在します。モバイル端末では、使用するプロトコル（移行先に応じてExchange ActiveSyncまたはIMAP）がプラットフォームとともに変わることがあり、これもアカウントを作り直すべき理由の1つです。
サーバー側のルール、一元管理された署名、委任の権限は、設定し直すことになります。このことを告知してください。これはメールの中断ではありません。管理作業です。
この転送には明示的な設定が必要です。まだメールボックスをホスティングしていると認識している古いプラットフォームを、自らの中で配送するのではなく新しいプラットフォームに中継するよう設定しなければなりません。それができない場合は、対象を絞った補完コピーで同じ役割を果たせます。
それぞれの移行元に固有の事項は、Microsoft 365からの移行とGoogle Workspaceからの移行で説明しています。
どのフローも古いプラットフォームを使用しておらず、報告された差異が処理されたことを確認するまでの期間です。これは、メールボックスの数、送信を行うアプリケーション、PCの再設定のペースによって異なります。閉鎖が早すぎると修正ができなくなり、遅すぎると従業員が2つのシステムで作業を続けることになります。
準備ができていれば、途切れません。TTLの期間中、一部の送信者は引き続き古いプラットフォームに配送し、それ以外は新しいプラットフォームに配送します。両方が受信し、次のコピーで両者を統合します。メールが失われるのは拒否された場合だけであり、だからこそエイリアスとメーリングリストが重要になります。
一般的には不要です。アドレスは変わらないからです。ただし、自社のメッセージを厳格にフィルタリングしている取引先や、自社に特別なルールを割り当てている取引先、そして鍵が変わる場合には、暗号化されたメールをやり取りしている相手先には知らせてください。
はい。古いプラットフォームがまだ稼働していれば、古いMXに戻すことで可能です。その場合、その間に新しいプラットフォームが受信したメッセージは、再コピーするか、閲覧可能な状態に保つ必要があります。切り戻し計画には、誰が判断するのか、どれだけの時間で行うのか、それらのメッセージをどのように回収するのかを定めておきます。
運用事業者が何を保証しているのかを確認してください。メッセージの到着なのか、履歴の移行なのか、あるいはその両方なのか。これらは異なる約束です。あわせて、文書化された切り戻し計画と、それを発動する権限を持つ担当者についても確認してください。
メッセージの到着に関する保証は、切り替えの当日とその後の数日間を対象とします。履歴に関する保証は、コピーとその確認を対象とします。事業者が一方だけを守り、もう一方を守らないこともありえます。見積もりには、どちらを引き受けるのか、そしてそれをどのように確認するのかを明記すべきです。
Klyticでは、メール（メールサービス）の移行を準備するためのアドバイスや提案は無料で、メールが1通も失われることはありません。Klyticが実施する移行は、見積もりに基づいて行われます。サブスクリプションについては料金のページをご覧ください。サブスクリプションは別途請求されます。コストの費目の詳細はMicrosoft 365の移行にかかるコストに、確認項目の一覧はチェックリストにあります。移行先を比較するには、欧州のビジネスメールを選ぶをご覧ください。
このページは1つの方法を説明するものです。実際の進め方は、お客様のフロー、容量、そして移行元のプラットフォームによって異なります。
