みなさん、こんにちは。AWS CLI が好きなテクニカルサポート課の市野です。
さて、新年度が始まりましたが、現地時間の 2026年3月31日に、いくつかのサービスの新規受付終了やサービス終了のアナウンスがありました。
対象となったサービスの一覧は以下の AWS の最新情報や AWS Lifecycle Changes ページでご確認が可能です。
私は個人として運用している独自ドメインのメール送受信に Amazon WorkMail を利用していたので、サービス終了には弱ったなという感じです。
21世紀の今、メールサーバーを運用するのもしんどいので、マネージドで使えるサービスでありがたかったんですけどね。まずは今までありがとうございます。
免責事項:
本文中にいくつかのサードパーティ製品の例が出てきますが、筆者として全てを評価した上での推奨ではありません。
手順やリスク評価、あるいは製品の評価については読者のみなさまでご判断いただけますようお願いいたします。
移行を考えてみる
昔ほどメールがコミュニケーションの主流ではなくなったとはいえ、止まってしまうと困るので移行を考えてみます。
公式の案内では、StartMailboxExportJob API を活用した Amazon S3 バケットへのエクスポートという手段が用意されています。
また、Amazon WorkMail end of support のページでは代替製品としていくつかのサードパーティ製品への移行の推奨や、移行を容易にするツールの提供もされていることの案内が掲出されています。
Alternative solutions
Amazon WorkMail recommends customers migrate to third-party solutions such as Kopano Cloud, Zoho Mail, and Zoom Mail, each providing Amazon WorkMail-comparable capabilities and tooling for easy migration. You can also migrate to other in-market third-party solutions.
上記の代替製品に挙げられているうちの Zoho Mail では、カレンダーデータも含めた移行ができ、ステップバイステップでの移行ガイドも用意されています。
私としてはどうするか
個人利用だったこともあり、カレンダー機能も使っておらず、私一人だけのユーザーのみ存在し、家族用のなんらかの申込のためだけにグループをいくつか設定していただけなので、基本的に重要なのは送受信したメールだけでした。
メールサーバーとしての移行と考えると、IMAP サーバー間で同期させて、DNS を切り替えれば良いってことだな、と思いいくつか探していたら imapsync という OSS が存在することを確認しました。
今回は、この OSS を使用して移行してみることとします。
手順の概要
大まかにまとめてみると以下のような手順となりそうです。
- 代替先のメールサービスを用意する
- imapsync を利用してメールボックスを同期させる
- 代替先のメールサービスで受信メールやフォルダの同期状況を確認する
- DNS を切り替える
- 代替先のメールサービス側から送信テストを行う
- DNS 切り替え中に Amazon WorkMail 側に受信していたメールがあれば、再度 imapsync による同期を実行する
- DNS 切り替えが完全に完了した時点で、Amazon WorkMail の組織を削除する
悩ましいのは送信のテストになりそうです。
昨今のメールセキュリティにおける DNS 設定で SPF 認証や DKIM の考慮がほぼ必須となっていますが、このため外部宛のメール送信が迷惑メール扱いになったり、リジェクトされる可能性が高そうです。
そのため DNS 切り替え前にできることといえば、SMTP 接続と認証が通ることの確認程度に止まりそうです。
やってみる
移行先の選定
コストメリットや私が最低限行えれば良いことの観点でさくらインターネットさんのさくらのメールボックスとしました。
他社様のサービスなので、導入手続きや契約、環境準備はちょっと割愛させていただいて、問題なく準備できている前提で進めます。
imapsync の導入
私の環境は macOS なので、Homebrew でのインストールが可能でした。
brew install imapsync
imapsync による同期
コマンドの構文としては以下のような形式となります。
WORKMAIL_HOST="imap.mail.us-east-1.awsapps.com"
WORKMAIL_USER="user@example.com"
WORKMAIL_PASSWORD='PasswordForWorkMailUser'
SAKURA_HOST="www9999.sakura.ne.jp"
SAKURA_USER="user@foobar.sakura.ne.jp"
SAKURA_PASSWORD='PasswordForSakuraMailBoxUser'
imapsync \
--host1 "${WORKMAIL_HOST}" \
--user1 "${WORKMAIL_USER}" \
--password1 "${WORKMAIL_PASSWORD}" \
--ssl1 \
--host2 "${SAKURA_HOST}" \
--user2 "${SAKURA_USER}" \
--password2 "${SAKURA_PASSWORD}" \
--tls2
注意事項
IMAP サーバーへの接続時、--password1、--password2 のように指定していますが、本来は、外部ファイルに接続情報を記載しておき、--passfile1、--passfile2 のように読み込むことを推奨します。
ハマりどころ
前述のように移行元と移行先のサーバー認証情報を定義して imapsync コマンドを実行すれば良いのですが、出力されるメッセージが少々読みにくく、双方のサーバーに正しく接続できているのかが判別しにくい印象です。
そこで以下のように個別で接続先の認証情報の妥当性を確認しておくと良さそうです。
Amazon WorkMail 側
openssl s_client -connect "${WORKMAIL_HOST}":993
〜中略〜
Start Time: 1775294025
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
* OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ENABLE IDLE LITERAL+ AUTH=PLAIN] Amazon WorkMail IMAP Proxy
# この後 a LOGIN WORKMAIL_USER WORKMAIL_PASSWORD の要領で入力し Enter を実行する
# 入力後、以下のように表示されればログインが成立しており、接続先ホストや認証情報が正しいことを確認可能
a OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ENABLE IDLE ID SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS BINARY MOVE STATUS=SIZE SAVEDATE LITERAL+ QUOTA] Logged in
代替サービス側（表示はさくらインターネットの例）
openssl s_client -connect "${SAKURA_HOST}":143 -starttls imap
〜中略〜
Start Time: 1775294315
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
---
. OK CAPABILITY completed
# 同様に a LOGIN SAKURA_USER SAKURA_PASSWORD の要領で入力し Enter を実行する
# 入力後、以下のように表示されればログインが成立しており、接続先ホストや認証情報が正しいことを確認可能
a OK LOGIN Ok.
特に、さくらインターネットではメールボックスの「初期ドメイン」とサーバー情報から閲覧できる「ホスト名」が接続先として似たような概念なので混同して正しく接続できていない状態に気づくのに時間がかかりました。
また、SAKURA_USER と記載している部分は文脈上、初期ドメインと読み取れる記載していますが、導入サービスの設定状況に依存しますので、実際の値に適宜ご変更ください。
同期の実行
--dry オプションが用意されているので、まずはドライランを実施してみることが推奨されています。
また、実行ログは LOG_imapsync/2026_04_04_10_59_22_761_test1_test2.txt のような形式で出力されるため、ドライランの実行後に妥当性を確認できます。
imapsync ではデフォルトでは Message-Id: と Received: を識別ヘッダーとして利用し、重複の問題を回避しつつ増分を同期することができるとあります。
そのため中断があっても問題が起こらないとなっていますが、nohup でバックグラウンドで実行しておくのもいいかもしれません。
あとは DNS の切り替え
MX レコードに加え SPF 認証用の TXT レコード、DKIM 用の TXT レコード、DMARC 用の TXT レコードなどをもれなく変更します。
また、DNS 切り替え前に TTL を短くしておくことも重要と考えられます。
おわりに
Amazon WorkMail は AWS が提供する ビジネスアプリケーションの中でいい具合に AWS が管理してくれるマネージドサービスとして個人的に好きなサービスでした。
サービス終了は残念ですが 2027年3月31日 までの約 1 年間の移行準備期間が用意されています。
慌てず移行計画を立てていただき、トラブルなく移行を進めていただければ、と思いますが、移行についてのご質問があればサポートセンターからお問い合わせください。
また、移行に関して技術的なご支援が必要な場合、担当営業までご相談ください。
このエントリがどなたかのお役に立てば幸いです。
ではまた。
市野 和明 (記事一覧)
マネージドサービス部・テクニカルサポート課
お客様から寄せられたご質問や技術検証を通じて得られた気づきを投稿していきます。
情シスだった前職までの経験で、UI がコロコロ変わる AWS においては GUI で手順を残していると画面構成が変わってしまって後々まごつくことが多かった経験から、極力変わりにくい AWS CLI での記事が多めです。
X（Twitter）：@kazzpapa3（AWS Community Builder）
