メールをGmailから自分のドメイン(iCloud+カスタムドメイン)に移す
Gmailを卒業し、自分のドメインのメールアドレス(iCloud+カスタムドメイン機能)に一本化した記録。DNSレコードの実際の設定値、Thunderbirdの3層アカウント構造でハマった話、復旧作業中に4,293件のメールを誤って喪失し原本から復元した話まで、正直に書く。
- 公開日：
- 2026-09-12
- 最終更新日：
- 2026-09-13
長年使っていたGmailをやめて、自分のドメインのメールアドレスに主メールを一本化した記録。土台はiCloud+の「カスタムメールドメイン」機能で、既にiPhoneのバックアップ用にiCloud+を契約していたため追加コストはかからなかった。作業自体は数日がかりで、途中で本当にメールを失いかけた場面もあった。この記事はその過程を、うまくいかなかった所も含めて正直に書く。
前提
- 自分名義のドメイン(取得方法は各ドメインレジストラのサイトを参照。自分はCloudflare Registrarを使った)
- iCloud+の契約(月額サブスクリプション。iPhoneのバックアップ用など、何らかの理由ですでに契約していれば追加コストはかからない)
- ドメインのDNS(「
taikiito.comというドメインは実際にはどのサーバーを指すか」をインターネット全体に教えるための住所録のような仕組み)を自分で編集できる状態(Cloudflareなど)
何をしたかったか
Gmailは便利だが、Googleに完全に預けているアカウントでもある。自分名義のドメインを取得したことで、自分のドメインでメールを受け取れる状態が整った。iCloud+はもともとiPhoneのバックアップ用に契約していたので、カスタムドメインのメールボックスを足しても容量を共有するだけで実質タダ。これなら移行のコストに見合うと判断した。
何に移すか: iCloud+ vs Fastmailで迷った話
自前ドメインでメールを使う場合、有名な選択肢としてFastmailがある。料金以外の軸(標準プロトコル対応、Apple以外の端末での使い勝手、エイリアスの上限、送信ドメインとしての評判、データの持ち出しやすさ)で比較検討した。
比較の途中で、自分の思い込みが一つ崩れた。iCloud MailはApple製品専用だとばかり思っていたが、実際には標準のIMAP/SMTP(メールの受信・送信をやり取りするための業界共通の通信規格。この2つに対応していれば、どのメールソフトからでも接続できる)にアプリ専用パスワードでアクセスすれば、Thunderbirdのような普通のメールクライアント(メールを読み書きするためのアプリ)からも使える。「ロックインされて出られなくなる」という一番の懸念はほぼ杞憂だった。すでに契約しているiCloud+の容量を共有できて実質無料な点も踏まえ、Fastmailへの乗り換えは見送り、iCloud+のカスタムドメイン機能を使うことにした。
Step 1: iCloud+でカスタムドメインを設定する
iPhoneの「設定」アプリ → 自分の名前(Apple ID) → iCloud → 「メール」→「カスタムメールドメイン」から設定を開始する(Mac版System Settingsからも同じ設定にたどり着ける)。ドメイン名(例: taikiito.com)を入力すると、iCloud側が必要なDNSレコードを画面に表示してくれるので、それを自分のドメインのDNS管理画面(Cloudflareなど)にそのまま追加する。実際に追加したレコードは以下の3種類だった。
| 種類 | 内容 |
|---|---|
| MX | mx01.mail.icloud.com / mx02.mail.icloud.com(メールの受け取り先を指定) |
| SPF (TXTレコード) | v=spf1 include:icloud.com ~all(このドメインからのメールはiCloud経由が正当だと示す) |
| DKIM (CNAMEレコード) | sig1._domainkey → sig1.dkim.taikiito.com.at.icloudmailadmin.com(メールが改ざんされていないことを証明する電子署名の仕組み) |
iCloud+の設定ウィザードはこの3つだけを要求し、DMARC(後述、なりすまし対策をさらに強化するレコード)は必須ではなく任意なので、最初は追加しなくても動く。反映には数分〜数十分かかる。全て緑のチェックマークになれば、そのドメインでメールアドレス(自分の場合は[email protected])を作成できる。
Step 2: 会社のメール環境への到達を確認する
自分の場合、[email protected]からGmailへは問題なく届いたが、会社のメール(Microsoft 365ベース)にはエラーも通知もなく、静かに届かないという問題が起きた。SPF/DKIMを見直しても直らなかったため、DMARC(TXTレコード)を追加した。
_dmarc.taikiito.com TXT "v=DMARC1; p=none; rua=mailto:<自分のメールアドレス>"
p=noneはまず様子見のモード(ポリシー違反があっても何もしない、レポートだけ受け取る)。これでも解決しなかったが、SPF/DKIM/DMARCの設定自体には問題が無いことが確認できたので、原因は取得したばかりのドメインが「送信履歴の無い新規ドメイン」として会社側のメールフィルタに警戒されていることだと判断し、時間経過で解決するのを待つ方針にした。実際、数日後には特に追加の変更をしないまま届くようになった。新しく取ったドメインでメールを送る場合、最初の数日〜1週間は主要な送信先に届かないことがあると見込んでおくとよい。
Step 3: なりすまし対策を強化する(SPF/DMARCの締め上げ)
ドメインの送信環境が安定してきたら、なりすまし対策を強める。最終的には以下の設定にした。
_dmarc.taikiito.com TXT "v=DMARC1; p=reject; rua=mailto:<自分のメールアドレス>"
p=none(様子見) → p=quarantine(怪しいメールを迷惑メール行き) → p=reject(なりすましメールを完全拒否)の順に段階を踏むのが一般的だが、自分の場合は送信経路がiCloudのみでSPF/DKIMがすでに正常に機能していたため、リスク評価をした上で段階を飛ばしてp=rejectまで一気に進めた。SPFも~all(該当しない送信元は「疑わしい」扱い)から-all(該当しない送信元は「完全に拒否」)へ強化した。
注意: p=rejectにすると、このドメインからのメールを送るときに使う経路(自分の場合はiCloudのみ)以外からは一切メールが届かなくなる。今後、別のメールサービスを追加で使う場合は、SPFレコードに新しい送信元をinclude:で追加し忘れないこと。
Step 4: Gmailからの引っ越しで3つハマったこと
1. Thunderbirdの「3層構造」に気づかず認証が通らなかった
WindowsでThunderbirdを使って移行作業をしようとしたところ、何度設定してもIMAP/SMTPの認証が通らなかった。原因は、iCloudのアカウント構造が3層になっていたこと。
- 表向きのApple IDサインイン用メールアドレス
- 実際のIMAP/SMTP認証に使う、真のiCloudアカウントアドレス(
@icloud.com形式) - 送受信に使う見た目のアドレス(カスタムドメインのエイリアス)
Thunderbirdの手動設定画面で、サーバー情報は以下のようにする。
| 項目 | 値 |
|---|---|
| 受信サーバー(IMAP) | imap.mail.me.com、ポート993、SSL/TLS |
| 送信サーバー(SMTP) | smtp.mail.me.com、ポート587、STARTTLS |
| ユーザー名 | 真のiCloudアカウントアドレス(@icloud.com形式)をフルで入力 |
| パスワード | Apple IDの「Appleパスワード」ではなく、Apple ID管理画面で発行する「App用パスワード」 |
ポイントはユーザー名欄で、一番上のApple IDのアドレスでも、送受信に使うカスタムドメインのアドレスでもなく、中間層の真のiCloudアカウントアドレスをフルで入力する必要がある。これはApple公式の設定手順のどこにも明記されておらず、自力で突き止めるまで何度も認証エラーに悩まされた。
2. 「完了」と判断したが、実は直近1〜2ヶ月分が抜けていた
Gmailの全メール(46,544件)をThunderbird経由でiCloud側へ移す自作スクリプトを作り、実行した。進捗ログを見ながら待ち、件数がおおよそ一致したことを確認して「移行完了」と判断した。
ところが後日、送信済みメールを見返していて、直近のメールが見当たらないことに気づいた。調べると、スクリプトは古いメールから新しいメールへ順番に処理する作りで、確認した時点では全体の約8割(37,362件/46,544件)までしか進んでおらず、直近1〜2ヶ月分がまだ移行されていない状態で「完了」と誤判断していたことが分かった。「件数がざっくり合っている」だけでは、移行完了の確認として不十分だったという教訓。
3. 復旧作業中に4,293件を誤って喪失、Google Takeoutの原本から復元
上記の見落としを受けて調査していたところ、さらに深刻な問題が見つかった。iCloud側で重複メールを整理する作業をしていた際、4,293件のメールを誤って消してしまっていた。加えて、作業の混乱の中でThunderbirdのローカルインポートフォルダ自体も誤って削除してしまい、復元の頼みの綱を一つ失った。
幸い、Gmailの公式エクスポート機能(Google Takeout、写真移行の記事で使ったのと同じ機能)で取得していた元データ(zipファイル、Gmailの全メールをmbox形式(メールをまとめて1つのファイルに保存する一般的な形式)で含む)がゴミ箱に残っていた。これは「Thunderbirdの中間コピー」ではなく「Gmail公式のエクスポート原本」なので、むしろ最も確実な復旧元だった。
Message-ID(メール1通ごとの一意な識別子、ヘッダーに必ず含まれる)単位で「Takeoutの原本」と「今iCloud側にあるメール」を突き合わせる復旧スクリプトを書き、欠落していたメールを復元した。最終的に、iCloudの1通あたりのサイズ上限を超えている(添付ファイルが大きい)ため原理的に復元不可能な2〜3件を除いて、ほぼ完全に復旧できた。
このとき得た一番の教訓: 大量データの移行を「件数がだいたい合っている」だけで完了と判断しない。Message-IDで突き合わせる方式が、確実に検証する唯一の方法だった。そしてGoogle Takeoutのような「移行元の公式エクスポート」は、移行作業が終わるまで絶対に消さないこと。
Step 5: 移行後の後片付け
Gmail側に[email protected]への自動転送(Forwarding、Gmailの設定 → 「メール転送とPOP/IMAP」から設定できる)を設定し、移行後にGmail宛へ届く新着メールも自動的に新しいアドレスへ流れるようにした。Google Takeoutのバックアップzipは、Backblaze B2とNextcloudの両方に保存。この3点(バックアップ済み・移行件数の整合性確認済み・新着メールの転送設定済み)を確認したうえで、Gmail側の整理に着手した。
整理は、GmailのAPI(他のプログラムからGmailを操作するための窓口)や管理画面からではなく、IMAP(前述の受信用の通信規格)を直接操作する自作スクリプトで、指定日より前の全メール(49,755件)をGmailの「ゴミ箱」フォルダへ移動する処理を実行した。Gmailのゴミ箱は30日後に自動で完全削除される仕組みなので、今のところ即座に完全削除したわけではなく、猶予期間を残した状態にしてある。この記事を書いている時点では、Gmail側のメールはゴミ箱送りまで完了しているが、Googleアカウント自体はまだ削除していない。しばらく[email protected]側の運用が安定するのを見届けてから、次の判断(アカウント自体を消すかどうか)をするつもりでいる。
結果
[email protected]が主メールとして定着し、日常的に使っている。途中でメールを実際に失いかけた一件は、この移行作業の中で一番肝を冷やした部分だったが、Google Takeoutで原本のバックアップを取っておいたことが最終的に救いになった。大量データを移す時は、移行先だけでなく移行元の生データも別途バックアップしておく、というのが今回一番強く実感した教訓だった。
更新履歴 — 2026-09-12: 初版 / 2026-09-13: DNSレコードの実際の設定値・Thunderbirdのサーバー設定項目を追記し、再現可能なレベルに書き直し