会社のメールをレンタルサーバーからGoogle Workspace・Microsoft 365へ移す｜切り替え日の段取りと、移した後に止まりやすいもの（複合機・問い合わせフォーム・業務システムの送信）

会社のメールをレンタルサーバーから Google Workspace か Microsoft 365 に移す作業は、移し先に利用者と共有アドレスを用意して過去のメールをコピーし、ドメインの MX レコードを書き換え、旧サーバーに遅れて届いた分を拾ってから、レンタルサーバーの側でそのドメインのメールを使わない設定にする、という順で進めます。MX レコードを書き換えてから変更が行き渡るまで、最長で72時間ほどかかると Google と Microsoft の双方が説明しているため（Google Workspace 管理者ヘルプ「Google Workspace の MX レコードを設定する」、Microsoft Learn「他の種類の IMAP メールボックスを Microsoft 365 または Office 365 に移行する」）、その間は旧サーバーの契約とメールボックスを残しておきます。

移したあとに止まりやすいのは、メールを受け取る側より送る側です。Web サイトの問い合わせフォームがレンタルサーバーから送る通知、複合機のスキャン to メール、業務システムや予約サイトの自動送信は、送り方の設定と、送信元を宣言する SPF のレコードを直さないと、届かなかったり迷惑メールに入ったりします。Microsoft は、Exchange Online の SMTP AUTH をユーザー名とパスワード（基本認証）で使う送信を、2026年12月末に既存の組織でも既定で無効にすると告知しています（Exchange Team Blog、英語）。転送と共有アドレスも、移し先の既定の設定のままでは止まることがあります。

この記事では、切り替え日の前・当日・後にすることと、止まりやすい所の確かめ方を、Google Workspace 管理者ヘルプ、Microsoft Learn、エックスサーバーとさくらのレンタルサーバのマニュアル（いずれも2026年9月29日に確認）をもとに書きます。製品の料金はこの記事では扱いません。書き手の Aurant Technologies は、Google と Microsoft のどちらの販売代理店でもなく、どちらかの製品を勧める立場をとらずに、移す作業の手順の側から書いています。

先に数える：アドレス、共有アドレスと転送、過去のメールの置き場

切り替えの日を決める前に、今のレンタルサーバーで動いているメールを書き出します。移し先で作り直すものと、移行のツールでは移らないものを、ここで見つけておくためです。

受け方の欄は、過去のメールの移し方を決めます。POP はメールをパソコンなどの端末に取り出して読む受け方で、1つのアドレスを何人かや何台かの端末で POP で読むには、メールソフトで「サーバー上にメールを残す」設定が要る、とさくらインターネットは説明しています（さくらのサポート情報「メールソフト（メーラー）の設定内容を知りたい」）。残す設定をしていない POP のアドレスは、過去のメールがサーバーではなくパソコンにあるので、サーバーから読み出す IMAP の移行では移りません。移し方は「過去のメールを移す」の節で扱います。

もう一つ確かめるのが、ドメインの DNS をどこで管理しているかです。MX レコードの書き換えは、DNS を管理している会社の画面で行います。さくらのレンタルサーバでゾーンを編集できるのは、さくらインターネットで取得・管理しているドメインか、さくらのネームサーバーを使っているドメインに限られ（さくらのサポート情報「Google Workspace を利用したい」）、エックスサーバーの DNS レコードの設定を使うには、ネームサーバーをエックスサーバー指定のものにしておく必要があります（エックスサーバーのサポートページ「Webサイトはエックスサーバー、メールはGoogle Workspaceで利用する際の設定方法を教えてください。」）。ドメインを取った会社や Web サイトの制作会社が DNS を管理していることもあるので、書き換える人と日を先に決めます。

IMAP で過去のメールをコピーするには、旧サーバーの各アドレスのパスワードが要ります（Google Workspace 管理者ヘルプ「IMAP アカウントからメールをインポートする」）。Microsoft 365 の IMAP 移行の手順も、パスワードが分からないアドレスは、分かるパスワードにリセットして使うよう案内しています（Microsoft Learn）。書き出しが終わるまで、レンタルサーバーのメールアカウントや転送の設定は消さずにおきます。Web サイトを同じサーバーに残すなら、サーバーは解約せず、メールの設定だけを外します（外す時期は「切り替え日の段取り」の節）。

メールを送る側の機器とシステムを洗い出す

今のサーバーの設定を知る人が社内にいないときに、ログインせずに外から、会社のドメインでメールを送っている仕組みを調べた例は、導入事例「Google Workspace 導入の事前調査」で紹介しています。

受け取る側は MX レコードを書き換えれば移し先に切り替わりますが、送る側は切り替わりません。自社のアドレスを差出人にしてメールを送っている機器やシステムを、次の3種類に分けて、一つずつ送り方を確かめます。

複合機・スキャナ

Microsoft 365 へ移す場合は、2026年12月末に Exchange Online の SMTP AUTH が既定で無効になる点も、複合機の設定に関わります。送信元の数え方と、送り方の割り振りは「Exchange Online の SMTP AUTH は2026年12月末に既定で無効になる」で解説しています。

複合機がレンタルサーバーの SMTP サーバーに、メールアカウントとパスワードで認証して送っている場合は、旧サーバーのアカウントを消した時点で送れなくなります。切り替えの前に、移し先が案内する送り方のどれかに設定し直します。

Google Workspace は、デバイスやアプリからの送り方として、SMTP リレー（推奨）、Gmail の SMTP サーバー（smtp.gmail.com）、組織の中の宛先にだけ送れる制限付きの SMTP サーバーの3つを挙げています。ユーザー名とパスワードでログインする安全性の低いアプリや機器は、2025年5月1日から Google Workspace のアカウントで使えなくなっており、機器が OAuth に対応していなければ、アプリ パスワードを作るか、IP アドレスで認証する SMTP リレーを使います（Google Workspace 管理者ヘルプ「プリンタ、スキャナ、アプリからのメール送信」「安全性の低いアプリへのアクセスを管理する」）。

Microsoft 365 の側は、SMTP AUTH で認証して送るクライアント SMTP 送信、受信コネクタを使う SMTP リレー、組織の中の宛先にだけ届く直接送信などを示しています。SMTP AUTH は2020年1月以降に作られた組織では無効になっていて、使うメールボックスごとに有効にします。Microsoft Entra ID のセキュリティの既定値を有効にしている組織では使えません。サーバー名・ポート・認証の違いは、下の一覧にまとめました（Microsoft Learn「Microsoft 365 または Office 365 を使用してメールを送信するように多機能デバイスまたはアプリケーションをセットアップする方法」「Exchange Online で SMTP AUTH を有効または無効にする」）。

基本認証での SMTP AUTH には期限があります。Microsoft の Exchange Team Blog（2026年1月27日、英語）によれば、2026年12月までは今の動作のままで、2026年12月末に既存の組織でも既定で無効になり（管理者は必要なら有効にできる）、2026年12月より後に作られる組織では既定で使えず、最終的な廃止の日は2027年後半に発表されます（Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline）。これから Microsoft 365 を契約して複合機を SMTP AUTH で設定するなら、機器が OAuth に対応しているか、SMTP リレーに切り替えられるかを、機器の提供元に確かめておきます。Microsoft は代わりの方法として、社内宛てにだけ送るなら High Volume Email、社外にも送るなら Azure Communication Services のメールを挙げています（Microsoft Learn）。

Web サイトの問い合わせフォーム

レンタルサーバーで動いている Web サイトのフォームは、サーバーのプログラムからメールを送ります。さくらインターネットは、MX レコードを他社のサーバーに向けたあとも、サーバーの内部から送ったメール（ウェブメール、メールの転送、CGI や PHP での送信など）はサーバーの中で処理され、同じサーバー内のメールボックスに届くと説明しています。例に挙げているのは、Web サーバーはさくらのレンタルサーバ、メールは Google Workspace や Office365、フォームの送信先が同じドメイン、という組み合わせです。これを避けるには、サーバーコントロールパネルのドメイン設定で「選択したドメインはメールでは利用しない」にします（さくらのサポート情報「MXレコードを設定したが、メールフォームからメールが届かない」）。

エックスサーバーは、外部のメールサーバーを使うドメインについて、サーバーに設定したメールアカウント、メーリングリスト、メールマガジンをすべて削除するよう案内しており、Google Workspace を使う場合のマニュアルでも、DNS レコードを設定したらメール機能を無効にするよう求めています（エックスサーバー マニュアル「外部メールサーバーをお使いいただく場合」「Google Workspace(旧G Suite)をお使いいただく場合」）。ほかの会社のレンタルサーバーでも、外部のメールサービスを使うときの設定がマニュアルにあるかを確かめます。

この設定は、旧サーバーに遅れて届いたメールのコピーが終わってから行い、それまではフォームの通知が旧サーバーに届いていないかを見ます（「切り替え日の段取り」の節）。フォームがお客様に送る自動返信は社外に出ていくメールなので、レンタルサーバーから送り続ける限り、SPF のレコードにはレンタルサーバーの送信元を残します。フォームの送信を、サーバーのプログラムからではなく移し先の SMTP で送るように変える場合は、複合機と同じく、移し先の送り方の中から選びます。

業務システム・予約サイト

Microsoft 365 へ移した後に、会議室予約やカレンダー同期、CRM連携のアプリが EWS という方式で Exchange Online につないでいる場合は、2026年10月から順次止まります。止まる業務の洗い出しは「Exchange Online の EWS 廃止（2026年10月から順次、2027年4月1日に完全停止）で、止まる業務の道具を洗い出す」で解説しています。

社外のサービスが自社のアドレスを差出人にして送っている場合は、2通りに分かれます。サービスが自社のメールアカウントで SMTP にログインして送っているなら、複合機と同じく設定し直します。サービス自身のサーバーから送っているなら、そのサーバーを SPF に入れ、DKIM の署名ができるかを提供元に確かめます。Google は、サードパーティのサービスから送るメールが SPF と DKIM のチェックに合格していることを、DMARC を設定する前に提供元と確かめるよう求めています（Google Workspace 管理者ヘルプ「DMARC を設定する」）。

移し先ごとの公式の移行の手段と、既定の設定の違い

Google Workspace と Microsoft 365 は、どちらも IMAP で旧サーバーからメールをコピーする手段を用意していますが、移るものの範囲や、共有アドレス・転送の既定の設定が違います。移し先を決めたら、次の表で違いを確かめます。

共有アドレスは、読む人と返信する人の数で持ち方を決めます。Google Workspace のエイリアスは1人につき30個まで付けられますが、1つのエイリアスを複数の人で共有することはできず、Google は複数の人が使うアドレスには Gmail の委任を勧めています（Google Workspace 管理者ヘルプ「予備のメールアドレス（メール エイリアス）を追加または削除する」）。届いたメールを担当に割り当てて処理するなら、グループを共同トレイとして使えます（Google Workspace ラーニング センター「グループを共同トレイとして使用する」）。Microsoft 365 の共有メールボックスは、それ自体にライセンスは要りませんが、使う人には Exchange Online のライセンスが要り、共有メールボックスのアカウントでは直接サインインしません（Microsoft Learn「Microsoft 365 の共有メールボックスについて」）。レンタルサーバーのメーリングリストは、Google グループか Microsoft 365 の配布グループで作り直し、社外から受けるかどうかを設定します。

Microsoft 365 は、メールの付くプラン（Business Basic・Business Standard・Business Premium など）で契約します。Microsoft 365 Apps for business にはメールが含まれません（Microsoft Learn「Microsoft 365 の共有メールボックスについて」）。パソコンの Office の入れ替えと一緒に決める場合の考え方は、「Office 2021のサポート終了（2026年10月13日）で、会社のパソコンをどうするか」で整理しています。

この記事は、全員のメールを同じ日に切り替える前提で書いています。一部の人だけ先に試したい場合について、さくらのレンタルサーバのマニュアルは、今の環境を残したまま、さくらのメールアドレスから Google が指定する転送先のアドレスへ転送して使う方法を案内しています（さくらのサポート情報「Google Workspace を利用したい」）。

切り替え日の段取り：TTL、MX、旧サーバーを残す期間

切り替えは、次の順で進めます。当日の作業は短く、多くは前日までに済ませておけます。

前日まで

移し先にドメインを追加して所有権を確かめ、利用者のメールボックスと共有アドレスを作っておきます。Microsoft は、MX レコードを書き換える前にユーザーとメールボックスを用意しておけば、以前のメールの提供元から移ってもメールが途切れずに届くと説明しています（Microsoft Learn「DNS レコードを追加してドメインを接続する」「Microsoft 365 にカスタム ドメインを追加する」）。Google Workspace のデータ インポート ツールも、すでにある利用者のアカウントにしかメールを取り込めません（Google Workspace 管理者ヘルプ「データ インポート ツールを使用したメールのインポートについて」）。

MX レコードの TTL（ほかのメールサーバーが、その値を覚えておく時間）も短くしておきます。Microsoft は、移行を始める前に、MX レコードの TTL をどれも3,600秒（1時間）以下にしておくよう勧めています（Microsoft Learn の IMAP 移行の手順）。エックスサーバーとさくらのレンタルサーバの Google Workspace 用のマニュアルも、MX レコードの TTL を3600にしています。

過去のメールのコピーは、このあいだに始めます。移行のツールに入れる旧サーバーの名前は、独自ドメインではなく、レンタルサーバーが暗号化した接続のときに指定している名前にします。エックスサーバーはサーバーのホスト名（sv***.xserver.jp）を、さくらのレンタルサーバは初期ドメイン（〇〇.sakura.ne.jp）を、SSL/TLS で接続するときのサーバーとしています（エックスサーバーのサポートページにあるメールソフトに設定するサーバー名についての回答、さくらのサポート情報「メールソフト（メーラー）の設定内容を知りたい」）。Google Workspace のデータ インポート ツールが対象にしているのは、信頼できる TLS 証明書があり、Google から接続できる IMAP サーバーです（Google Workspace 管理者ヘルプ「IMAP サーバーから Google Workspace に移行する」）。

SPF のレコードに移し先を足すのも、切り替えの前です。Google は、SPF が機能し始めるまでに最長48時間ほどかかることがあるとしています（Google Workspace 管理者ヘルプ「SPF を設定する」）。レンタルサーバーの分は消さずに、1つのレコードにまとめます（次の節）。利用者には、切り替えの日、新しいメールボックスへのサインインの仕方、旧サーバーのメールをいつまで見られるかを前もって伝えます（Microsoft も、移行の前・最中・後にすることを利用者に知らせるよう勧めています。Microsoft Learn）。

当日

DNS を管理している画面で、旧サーバーを指す MX レコードを消し、移し先の MX レコードを入れます。Google Workspace の値は smtp.google.com（優先度1）で、ほかの MX レコードはすべて削除します。入れたあと、管理コンソールでそのドメインの Gmail を有効にします（Google Workspace 管理者ヘルプ「Google Workspace の MX レコードを設定する」）。エックスサーバーのマニュアルは、ドメインを追加したときに自動で作られた、ドメイン名を指す MX レコードを削除するよう書いています（エックスサーバー マニュアル「Google Workspace(旧G Suite)をお使いいただく場合」）。Microsoft 365 の値は、管理センターの［DNS レコードの追加］の画面に出るものを使い、旧サーバーの MX レコードは削除するか、優先度を Microsoft 365 より低くします（Microsoft Learn）。

書き換えたら、社外のアドレス（個人の Gmail など）との送受信、共有アドレスへの社外からのメール、複合機・フォーム・業務システムからの送信を、一つずつ試します。インターネットに公開されている MX レコードは、Google の管理者ツールボックスの Check MX や Dig で確かめられます。

72時間まで

MX の変更が行き渡るまでの間は、送り手のメールサーバーが古い値を覚えていて、旧サーバーにもメールが届きます。Microsoft は、変更が認識されるまで最長72時間かかりうるとして、移行のバッチ（1日に1回同期する）を少なくとも72時間動かしてから削除するよう案内しています（Microsoft Learn の同じ手順）。Google Workspace のデータ インポート ツールでは、最初のコピーのあとに旧サーバーに届いた分を、差分のインポートでコピーします（Google Workspace 管理者ヘルプ「IMAP アカウントからメールをインポートする」）。

Gmail には、POP で他社のアカウントのメールを取り込む［他のアカウントのメールを確認］という機能がありますが、2026年の第1四半期から新しく使う人には提供されず、すでに使っている人も2027年1月までとされています。会社のアカウントでは、管理者がデータの移行を手伝えると Gmail ヘルプも案内しています（Gmail ヘルプ「Gmail の Gmailify と POP の今後の変更について」）。遅れて届いた分は、管理者の移行のツールで拾います。この間は旧サーバーのウェブメールも開いて、フォームの通知などが旧サーバーに届いていないかを見ます。

そのあと

差分のコピーが終わり、新しいメールがすべて移し先に届いていることを確かめたら、移行のツールの同期を止め、レンタルサーバー側で、このドメインのメールを使わない設定にします。エックスサーバーではメールアカウントを削除することになり、旧サーバーのメールボックスには入れなくなるので、残したいメールが移し先にあるかを先に確かめます。設定したら、フォームから同じドメイン宛てに送って、移し先に届くことを確かめます。

パソコンやスマートフォン、複合機に残った旧サーバーの設定も消します。さくらインターネットは、サーバーから削除したアドレスの設定が端末に残って接続のエラーが続くと、接続元の IP アドレスからのメールの送受信が一定時間制限されることがあると説明しています（さくらのサポート情報「特定の時間に一定時間メールの送受信ができない」）。DKIM と DMARC は、次の節の順で設定します。

SPF・DKIM・DMARC を設定し直す

Gmail は、2024年2月1日から、個人の Gmail アカウントにメールを送るすべての送信者に SPF か DKIM の設定を求め、1日に5,000件を超えて送る送信者には SPF・DKIM・DMARC のすべてを求めています。認証されていないメールは、迷惑メールに分類されたり、拒否されたりすることがあります（Gmail ヘルプ「メール送信者のガイドライン」）。移行でメールを送るサーバーが変わるので、3つとも設定し直します。

SPF のレコードはドメインごとに1件にまとめる

SPF のレコードには、自社のドメインのメールを送るサーバーをすべて書きます。Google は、ウェブサーバーや「お問い合わせ」フォームのように自動でメールを送るサービスも送信元に含めるよう求めています（Google Workspace 管理者ヘルプ「SPF を設定する」）。Microsoft は、ドメインに SPF のレコードがすでにあれば新しく作らず、以前の提供元の値を消さずに Microsoft 365 の値を足して、1つのレコードにするよう案内しています（Microsoft Learn「DNS レコードを追加してドメインを接続する」）。1つのドメインに SPF のレコードが2つあると、正しく動きません（Microsoft Learn「Microsoft 365 ドメインの有効なメール ソースを識別するように SPF を設定する」、さくらのサポート情報「SPFレコードを設定したい」）。

レンタルサーバーには、既定の SPF レコードがあります。エックスサーバーは、ドメインを追加したときに、サーバーのホスト名や include:spf.sender.xserver.jp を含む SPF レコードを自動で入れ、Gmail を送信に使う場合のために include:_spf.google.com を足す「Gmail許可」の設定を用意しています（エックスサーバー マニュアル「SPF設定」）。さくらのレンタルサーバのレコードは v=spf1 a:www***.sakura.ne.jp mx ~all の形で、ほかのサービスを加えるときは同じ1行に半角スペースで区切って書くよう案内しています（さくらのサポート情報）。足す値は、Google Workspace が include:_spf.google.com、Microsoft 365 が include:spf.protection.outlook.com です（Google Workspace 管理者ヘルプ、Microsoft Learn）。

フォームや業務システムの送信をやめたサーバーは、あとで SPF から外します。ほかのドメインやサーバーへの参照が10回を超えると SPF の確認は失敗するので（Google Workspace 管理者ヘルプ、Microsoft Learn）、使わなくなった送信元は残しません。

DKIM は移し先の画面で設定する

Google Workspace では、管理コンソールの［アプリ］→［Google Workspace］→［Gmail］→［メールの認証］で鍵を作り、表示された TXT レコード（名前は google._domainkey）を DNS に足してから、［認証を開始］を押します。組織で Gmail を有効にしてから24〜72時間待たないと鍵を作れないことがあり、鍵を足してから機能するまで最長48時間ほどかかります。鍵の長さは、DNS の管理画面が対応していれば2048ビットを選びます（Google Workspace 管理者ヘルプ「DKIM を設定する」）。

Microsoft 365 では、自社のドメインで送るメールは、設定するまでそのドメインの DKIM で署名されません。Defender ポータルなどに表示される2件の CNAME レコード（selector1._domainkey と selector2._domainkey）を DNS に足し、Defender ポータルで署名を有効にします（Microsoft Learn「カスタム ドメインで DKIM をメールに使用する方法」）。

DMARC は p=none から始める

DMARC は、SPF と DKIM の確認に通らなかったメールを受け手がどう扱うか（そのまま届ける・迷惑メールにする・拒否する）を宣言し、結果のレポートを受け取る仕組みです。Google は、SPF や DKIM を設定してから48時間あけて DMARC を設定し、最初はポリシーを none にして、レポートを受けるグループか専用のメールボックスを用意するよう勧めています（Google Workspace 管理者ヘルプ「DMARC を設定する」）。Microsoft も、none から始めて quarantine、reject へ段階的に進めるよう案内しています（Microsoft Learn「Microsoft 365 で電子メールを検証するように DMARC を設定する」）。

移行の直後は、このレポートが送る側の書き出しの漏れを見つける手がかりになります。Google は、DMARC のレポートを、ドメインから送られたメールの認証の問題を見つけるのに役立つものとしています（同上）。書き出していなかったシステムが自社のドメインで送っていれば、認証に通らない送信元としてレポートに出てくるので、SPF と DKIM に足してからポリシーを強めます。

過去のメールを移す：サーバーにあるものと、パソコンにしかないもの

過去のメールは、置き場によって移し方が分かれます。書き出した受け方の欄をもとに、アドレスごとにどちらかを決めます。

サーバーにあるメール

Google Workspace のデータ インポート ツールは、1回のインポートで IMAP のユーザーを100人まで扱え、20人を超えるときは CSV ファイルでまとめて指定します。移るのはメール（下書きと送信済みを含む）と、フォルダに当たるラベルで、本文と添付ファイルの合計が25MBを超えるメールと、Gmail が止める種類の添付ファイルは移りません。日付を指定して、その日以降のメールだけをコピーすることもできます（Google Workspace 管理者ヘルプ「データ インポート ツールを使用したメールのインポートについて」「IMAP アカウントからメールをインポートする」）。Google Workspace の保存容量は、ドライブ・フォト・Gmail で共有されます（Google Workspace 管理者ヘルプ「SMTP リレーで送信するメールを Google 経由にルーティングする」）。何年分を移すかは、この容量と合わせて決めます。

Microsoft 365 の IMAP 移行が対象にするのは、受信トレイなどのメールのフォルダにある項目です。連絡先、予定表、タスクは対象外です。件数は1つのメールボックスあたり500,000件が上限で、新しいメールから順に移り、35MBを超えるメールは移せません（Microsoft Learn「IMAP メールボックスの Microsoft 365 または Office 365 への移行について知っておくべきこと」）。Business Basic・Business Standard・Business Premium のメールボックスは100GBで送受信が止まるので（Microsoft Learn「Exchange Online の制限」）、旧サーバーの使用量と比べておきます。

パソコンにしかないメール

POP で受けてサーバーから消してきたメールと、パソコンから送ったメールは、パソコンのメールソフトのデータにしかありません。Outlook のデータファイル（.pst）なら、Google Workspace では Google Workspace Migration for Microsoft Outlook（GWMMO）で、メール・予定表・連絡先を取り込めます。GWMMO は Outlook を使っている Windows のパソコンに入れて動かすもので、管理者が PST ファイルを移す方法として、Google は1〜20人の規模に GWMMO を挙げています（Google Workspace ラーニング センター「GWMMO をダウンロードしてインストールする」、Google Workspace 管理者ヘルプ「Google Workspace 移行サービスの一覧」）。取り込んだメールの添付ファイルを検索できるようにするには、取り込みの24時間以上前にスマート機能を有効にしておきます（Google Workspace ラーニング センター「ログインして Google Workspace を設定する」）。

Microsoft 365 では、従来の Outlook の［ファイル］→［開く/エクスポート］→［インポート/エクスポート］で .pst を選び、Microsoft 365 のメールボックスへ取り込みます。新しい Outlook では、.pst のメールを開くことはできますが、メール・連絡先・予定表のインポートはまだできません（Microsoft サポート「Outlook .pst ファイルからメール、連絡先、予定表をインポートする」）。Office の入れ替えと同じ時期に進めるときの Outlook の設定し直しは、Office 2021 のサポート終了についての記事でも扱っています。

Outlook 以外のメールソフトで POP を使ってきた場合は、そのソフトの提供元の手順で、データの書き出しや、移し先のアカウントへの取り込みができるかを確かめてから、移すかどうかを決めます。移さないメールは、パソコンのデータファイルを保管する場所と期間を決めて残します。

切り替え後1週間の確認：届かない・迷惑メールに入る・送れない

切り替えのあとの1週間は、次の3つの症状を目安に確かめます。社内の問い合わせ窓口を1つに決めて、症状とアドレスを集めると、原因を切り分けやすくなります。

届かない

社外から届かないときは、まず公開されている MX レコードが移し先の値になっているかを、Google の管理者ツールボックスで確かめます。info@ などの共有アドレスに社外から届かないときは、移し先の既定の設定を疑います。Google Workspace の組織全体の設定では「グループ オーナーは組織外からのメールの受信を許可できる」が既定でオフなので、管理コンソールでこれをオンにしたうえで、グループの［投稿できるユーザー］を［ウェブ上のすべてのユーザー］にします（Google Workspace 管理者ヘルプ「グループを使用するための組織全体のポリシーを設定する」「グループ設定に関する一般的な問題を解決する」）。Microsoft 365 の配布グループは、既定では組織の中からのメールしか受け付けず、社外からのメールは拒否されるので、社外から受けるアドレスでは設定を変えます（Microsoft Learn「Exchange Online で配布グループを作成して管理する」）。

旧サーバーで設定していた転送は、移し先で作り直さない限り止まったままです。Microsoft 365 では、社外への自動転送は送信スパム フィルター ポリシーで制御され、新しい組織では既定で止まっていて、転送しようとしたメールは配信不能として送り手に戻ります。Microsoft は、ポリシーを［自動 – システム制御］のままにせず［オン］か［オフ］を明示するよう勧め、転送先のドメインはリモート ドメインで絞れるとしています（Microsoft Learn「クラウド メールボックスからの自動外部メール転送を制御する」）。Google Workspace では、管理コンソールの自動転送の設定は既定で許可されており、利用者は Gmail の設定で転送先を1つ登録し、転送先に届く確認のリンクで承認します（Google Workspace 管理者ヘルプ「ユーザーが Gmail のメールを自動転送できるようにする」）。社内の何人かで読むための転送なら、グループや共有メールボックスに置き換えます。

迷惑メールに入る

取引先から「迷惑メールに入っていた」と言われたら、そのメールか、自分の個人の Gmail などに送った同じ経路のメールのヘッダーを開き、Authentication-Results の spf・dkim・dmarc の結果を見ます。Gmail ではメールの［メッセージのソースを表示］でヘッダーを開けます（Gmail ヘルプ「詳細ヘッダーからメールの経路を確認する」）。SPF の結果が softfail や fail なら、そのメールを送ったサーバーが SPF のレコードに入っていないことが考えられます（Google Workspace 管理者ヘルプ「SPF に関する問題のトラブルシューティング」）。フォームの自動返信や業務システムの通知も、同じように1通ずつ確かめます。

送れない

複合機や業務システムから送れないときは、上の一覧のとおりにサーバー名・ポート・暗号化・認証が設定されているかを見直します。Microsoft 365 のクライアント SMTP 送信は、ポート465では使えず、TLS 1.2 以上に対応していない機器でも使えません。使うメールボックスで SMTP AUTH が有効になっているか、セキュリティの既定値で無効になっていないかも確かめます（Microsoft Learn の多機能デバイスの手順、SMTP AUTH の有効化の手順）。Google Workspace で smtp.gmail.com を使う場合、2段階認証プロセスを有効にしたアカウントでは、機器にアプリ パスワードを設定しないと認証で失敗します（Google Workspace 管理者ヘルプ）。

送信ドメイン認証やメールを送る機器の扱いなど、移したあとの運用で見直す点は、当社の「Microsoft 365・Google Workspace 運用のセルフチェック」（12問、登録不要）でも確かめられます。

切り替えの日程づくりやフォーム・複合機の送り方など1件だけの相談は Aurant Technologies の移行と設定のスポット相談で、移行を含めた導入の全体はGoogle Workspace 導入支援・Microsoft 365 導入支援で、費用が決まる要素はMicrosoft 365・Google Workspace活用支援のページで扱っています。