Amazon WorkMail が2027年3月31日で終わる｜社内メールを WorkMail で使っている会社が、Microsoft 365・Google Workspace へ移す段取り

Amazon WorkMail は、2027年3月31日でサポートが終わります。AWS の管理者ガイドは、その日のあと、WorkMail のコンソールにも WorkMail の資源にも入れなくなる、と書いています。新規の顧客の受付は2026年4月30日に止まっていて、それ以前に登録した顧客は、終了日まで使い続けられます（Amazon WorkMail end of support、2026年10月5日に確認）。

独自ドメインの社内メールを WorkMail で運用している会社の残りは、確認日から177日です。やることは2つで、メールの置き場を別のサービスに移すことと、メールを取り出して手元に残すことです。AWS は、移行先の例として Kopano Cloud・Zoho Mail・Zoom Mail を挙げ、ほかの市販サービスへ移ってもよい、とも書いています。この記事は、Microsoft 365・Google Workspace へ移す場合の段取りを、WorkMail 側の事情に沿って書きます。

レンタルサーバーのメールから移す場合の段取りは、別の記事に書きました。MX の切り替えと、SPF・DKIM・DMARC の付け替えは同じです。WorkMail で違うのは、メールを取り出す手段が IMAP と export の API に限られること、AWS のコンソールに入れる期限があること、複合機やアプリの送信先が WorkMail の SMTP であることです。そこを中心に書きます。

WorkMail はいつ終わるのか：終了日と、そのあと

AWS の日本語のお知らせ（2026年3月31日付）は、WorkMail を、廃止されるサービスの一覧に載せています。管理者ガイドの更新履歴にも、同じ日に終了の通知が加わっています。発表から終了までは、ちょうど1年（365日）です。確認日は、発表から188日目にあたり、終了までは177日が残っています。

終了後は、コンソールにも資源にも入れなくなります。メールを取り出す方法は、あとで書く export も IMAP も、WorkMail が動いていて初めて使えます。移行の作業は、終了日の前に終える必要があります（当社の読み取り）。日本時間で終了日の何時までかは、確かめた範囲の AWS の文書には書かれていません。当日ではなく、前の月に終える前提で組みます。

WorkMail の使い方の確認と、移行の計画を一緒に立てたい場合は、当社のMicrosoft 365・Google Workspace活用支援で受けています。

自社が WorkMail を使っているかを確かめる

数年前に作った人が辞め、管理画面を誰も見ていない場合は、WorkMail が本当に使われているかから確かめます。見る場所は3つです。

いちばん手軽なのは DNS です。AWS のドメイン確認の手順は、MX の値が、優先度10の inbound-smtp.us-east-1.amazonaws.com、inbound-smtp.us-west-2.amazonaws.com、inbound-smtp.eu-west-1.amazonaws.com のどれかになっているかを、nslookup か dig +short （ドメイン） mx で確かめる、と書いています。

コンソールで気をつけるのは、リージョンです。WorkMail のエンドポイントの一覧に載っているリージョンは、米国東部（バージニア北部）、米国西部（オレゴン）、欧州（アイルランド）の3つです（AWS の一覧）。コンソールは画面上部のバーでリージョンを切り替えて見るので、東京リージョンだけを見て「WorkMail は無い」とは言えません。

手がかりはほかにもあります。独自ドメインを WorkMail に足すと、Amazon SES にそのドメインの送信許可のポリシーが自動で加わる、と管理者ガイドにあります（ドメインの追加）。SES のコンソールに、見覚えのないドメインが並んでいれば、確かめる手がかりの1つになります。

WorkMail の中身を数える：移行先で作り直すものの一覧

使っていると分かったら、組織の中身を、移行先の何に当たるかで並べます。メールボックスの数だけでなく、別名・グループ・共有の権限・会議室も、移行先で作り直す対象です。

この表の「数える・確かめること」を埋めたものが、移行の見積もりの元になります。WorkMail の別名は1人100個まで、Google Workspace は追加料金なしで1人30個までと、上限が違うので、別名を多く持つユーザーがいれば、先に分かるようにしておきます。

移行先を決める：AWS が挙げる3社と、Microsoft 365・Google Workspace

AWS の管理者ガイドは、移行先の例として Kopano Cloud・Zoho Mail・Zoom Mail を挙げ、これ以外の市販サービスも使える、と書いています。Microsoft 365 と Google Workspace は、AWS の例には入っていませんが、IMAP のメールを受け入れる公式の移行手順が、それぞれにあります。公式ページにある条件を並べると、次の図のとおりです。Google は、IMAP の取り込みを、1〜100人ならデータ インポート ツール、101人以上なら GWMME で行う、と案内しています。

メールだけを並べても、決まりにくいものです。同じ会社が日ごろ使う文書・表計算・会議・ファイル共有が、どちらに寄っているかを先に見ます（当社の整理）。メールの移行にかかる手間は、どちらを選んでも、ユーザー・別名・グループ・共有アドレスを作る作業が中心になります（当社の整理）。

段取りを逆算する：誰がどの画面で何をするか

WorkMail の移行は、AWS の管理者、DNS の管理者、移行先の管理者、機器とアプリの担当の4人が関わります。同じ人が兼ねていることもありますが、担当ごとに行を分けて書き出すと、抜けが見えます。

日程は、終了日から逆算します。次の月の割り方は、当社の整理で、10月から11月に確かめて数え、12月に試し、1月から2月に切り替え、3月に閉じます。2026年12月末には、Exchange Online の SMTP AUTH の基本認証が、既存の組織でも既定で無効になる予定です（当社の別の記事）。複合機の送信設定を直すなら、Microsoft 365 に移す場合は、その前に決めておきます。

メールを出す：IMAP でコピーし、export は保管に使う

WorkMail からメールを出す経路は2つあります。移行ツールが IMAP で読みに行く方法と、WorkMail の API で S3 に書き出す export です。条件が違うので、並べます。

コピーには IMAP を使い、export は保管用に取り出す、という分け方を勧めます（当社の整理）。理由は3つです。Microsoft も Google も、IMAP からの移行の公式の手順を持っています。export は、プログラムが書けることと、S3・KMS・IAM の準備が要ります。export の zip を、Microsoft 365・Google Workspace の取り込みがそのまま読めるかは、確かめられていません。保管用として取り、1つ開いて中身を見るところまでを、終了日の前に済ませます。

IMAP でコピーするには、ユーザーごとのパスワードが要ります。WorkMail の IMAP は、IMAPS・ポート993・認証は PLAIN で、サーバー名はリージョンごとに imap.mail.（リージョン名）.awsapps.com です（AWS のユーザーガイド）。パスワードが分からなければ、リセットします。ディレクトリが AD Connector なら Active Directory 側、IAM Identity Center と連携していれば Identity Center 側で行う、と AWS は書いています（パスワードのリセット）。Microsoft は、新しいパスワードを知らないユーザーは、移行中と移行後に前のメールボックスを開けなくなる、と書いているので、リセットする日は、利用者に伝えておきます。

予定表と連絡先は、どちらの経路でも移りきりません。IMAP で移るのはメールだけで、export には予定表の項目は入りますが、連絡先は入りません。使っている人が、Outlook から .pst に書き出し（Microsoft のヘルプ）、Microsoft 365 では Outlook で取り込みます（Microsoft のヘルプ）。Google Workspace では、1〜20人なら GWMMO、それ以外は、使う人が予定表を .ics、連絡先を .vcf か CSV で読み込みます（Google の一覧表）。Outlook に WorkMail のアカウントを入れている人が対象です（当社の整理）。予定表と連絡先を実際に使っている人が、何人いるかを、先に数えます。

切り替えの日：MX と、WorkMail が作らせた DNS レコード

メールの届き先を移すのは、MX の切り替えです。切り替えの前に MX の TTL を短くしておくところから、手順は他のサーバーから移す場合と同じです。違うのは、DNS が Route 53 にあることが多い点です。Google の MX の手順には、Amazon（AWS）Route 53 向けの案内が載っています（Google）。Microsoft は、以前のメールプロバイダーを指す MX を消すか、優先度を Microsoft 365 より下げる、と書いています（Learn）。

DNS の変更が行き渡るまでの時間は、AWS が最長48時間、Google が最長72時間と書いています。Microsoft の IMAP 移行のページは、移行を始める前に、MX の TTL を1時間（3,600秒）以内にしておくことを案内しています（Learn）。旧 WorkMail は、行き渡るまでは止めません。

WorkMail に独自ドメインを足すと、管理画面は、ドメインごとに複数の DNS レコードを並べます。切り替えのときは、MX だけを置き換えるのでは足りません。残ったレコードが、移行先の送信の認証や、Outlook の接続先を邪魔することがあるので、一覧にして、1本ずつ行き先を決めます。

SPF・DKIM・DMARC の付け替えの考え方は、レンタルサーバーから移す記事に書いたとおりです。WorkMail の場合は、WorkMail の SPF と DKIM が Amazon SES の仕組みで作られているので、SES から別のシステム（問い合わせフォームなど）が同じドメインで送っていないかを、消す前に確かめます（当社の整理）。

移したあとに止まりやすいもの：送る側と共有の側

受け取る側は、MX を切り替えれば移ります。止まりやすいのは、送る側と、共有の側です。次の問いで、担当に聞く範囲を決めます。

複合機とアプリの送信は、移行先ごとに送り方が違います。Google の手順は、SMTP リレー（smtp-relay.gmail.com、ポート25・465・587）を推奨としていて、Gmail の SMTP サーバーを使う場合は、アプリパスワードで認証します。ユーザー名とパスワードだけでログインさせるアプリや機器は、2025年5月1日から、Google Workspace のアカウントでは使えません（Google のヘルプ）。Microsoft には、クライアント SMTP 送信・SMTP リレー・直接送信・High Volume Email の4つがあり、クライアント SMTP 送信の基本認証は、廃止が予定されています（Learn）。機器が OAuth に対応しているかを、先に確かめます。

WorkMail にメールフローのルールがある場合は、本文を Lambda で見たり書き換えたりしていないかを確かめます。外へ出すメールを、SMTP ゲートウェイ経由にしているルールもあります（SMTP ゲートウェイ）。これらは WorkMail の仕組みなので、移行先で同じことをしたければ、別に作ります。impersonation role を使ったアプリは、EWS でメールを読んでいるので、移行先でも EWS が使えるかを確かめます。Exchange Online の EWS の終了は、別の記事に書きました。

切り替えの後の1週間は、届かないメール、迷惑メールに入るメール、送れない機器の3つを見ます。見方は、レンタルサーバーから移す記事の最後の節にあります。

WorkMail を閉じる：取り出せたことを確かめてから、組織を消す

移行が終わったら、取り出せたことを確かめてから、WorkMail の組織を消します。AWS は、組織の削除は取り消せず、削除したあとは、メールボックスのデータを戻せない、と書いています（組織の削除）。保管用に取った export の zip と、IMAP でコピーしたメールの件数を、消す前に確かめます。

削除のときは、ディレクトリを残すか消すかを選びます。WorkMail が作ったディレクトリを残すと、WorkMail・WorkDocs・WorkSpaces のどれからも使われていなければ、課金が続く、と書かれています。どちらを選ぶかは、削除の前に決めておきます。終了日のあとに、組織やディレクトリの課金がどう扱われるかは、確かめた範囲の AWS の文書には書かれていません。

使っているかの確かめ方から、中身の数え方、移行先の選び方、切り替えの段取りまで、Aurant Technologies のMicrosoft 365・Google Workspace活用支援で受けています。メールボックスの移行や、複合機・アプリの設定替えが絡む場合は、移行と設定のスポット相談で扱っています。