前提

• 自分名義のドメイン(取得方法は各ドメインレジストラのサイトを参照。自分は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種類だった。

iCloud+の設定ウィザードはこの3つだけを要求し、DMARC(後述、なりすまし対策をさらに強化するレコード)は必須ではなく任意なので、最初は追加しなくても動く。反映には数分〜数十分かかる。全て緑のチェックマークになれば、そのドメインでメールアドレス(自分の場合はme@taikiito.com)を作成できる。

Step 2: 会社のメール環境への到達を確認する

自分の場合、me@taikiito.comから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の手動設定画面で、サーバー情報は以下のようにする。

ポイントはユーザー名欄で、一番上の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側にme@taikiito.comへの自動転送(Forwarding、Gmailの設定 → 「メール転送とPOP/IMAP」から設定できる)を設定し、移行後にGmail宛へ届く新着メールも自動的に新しいアドレスへ流れるようにした。Google Takeoutのバックアップzipは、Backblaze B2とNextcloudの両方に保存。この3点(バックアップ済み・移行件数の整合性確認済み・新着メールの転送設定済み)を確認したうえで、Gmail側の整理に着手した。

整理は、GmailのAPI(他のプログラムからGmailを操作するための窓口)や管理画面からではなく、IMAP(前述の受信用の通信規格)を直接操作する自作スクリプトで、指定日より前の全メール(49,755件)をGmailの「ゴミ箱」フォルダへ移動する処理を実行した。Gmailのゴミ箱は30日後に自動で完全削除される仕組みなので、今のところ即座に完全削除したわけではなく、猶予期間を残した状態にしてある。この記事を書いている時点では、Gmail側のメールはゴミ箱送りまで完了しているが、Googleアカウント自体はまだ削除していない。しばらくme@taikiito.com側の運用が安定するのを見届けてから、次の判断(アカウント自体を消すかどうか)をするつもりでいる。

結果

me@taikiito.comが主メールとして定着し、日常的に使っている。途中でメールを実際に失いかけた一件は、この移行作業の中で一番肝を冷やした部分だったが、Google Takeoutで原本のバックアップを取っておいたことが最終的に救いになった。大量データを移す時は、移行先だけでなく移行元の生データも別途バックアップしておく、というのが今回一番強く実感した教訓だった。

更新履歴 — 2026-09-12: 初版 / 2026-09-13: DNSレコードの実際の設定値・Thunderbirdのサーバー設定項目を追記し、再現可能なレベルに書き直し

ドメイン名はexample.com、自分のアドレスはme@example.comと書く。実際の値は自分のものに読み替えてほしい。

前提

• 自分名義のドメインを持ち、DNS(「example.comは実際にどのサーバーを指すか」をインターネット全体に教える住所録のような仕組み)を自分で編集できる状態
• そのドメインでメールを送受信できている状態(前記事の到達点)。なりすまし対策はp=rejectまで締めてある
• 移行対象のメールは約5万通、容量10GB

きっかけは「検索が効かなくなった」こと

不満はひとつだけだった。メールソフトで検索しても出てこない。「豚汁」と打つ。その語を含むメールは確かにあるのに、ヒットしない。他のキーワードなら出る。壊れていたのは検索機能ではなく、索引(どの単語がどのメールに入っているかの目次)が一部だけ欠けている状態だった。

使っていたのはThunderbirdで、ここは索引を手元のPCの中に自分で作る方式だ。数万通あると索引作りが追いつかず壊れやすい。IMAP(メールサーバー上のメールをそのまま読み書きするための通信規約)ではサーバー側の検索と手元の検索が混在して挙動が安定しない。

索引を作り直す手はある(プロファイルフォルダのglobal-messages-db.sqliteを付随ファイルごと消して再起動すると自動で再構築が始まる)。自分はやらなかった。今回直せても、メールが増えれば同じことが起きる仕組みのままだからだ。検索はメールの価値の大半で、10年分の過去メールが「あるのに取り出せない」なら持っている意味が薄い。

メールだけは自前でホスティングしないと決めた

写真・ファイル・パスワード・カレンダーは自分のサーバーに移している(自分の「サーバー」を持つとはどういうことか)。だからメールもできるはずだと考えて、MailcowとMailuを調べた。どちらもDocker(アプリを必要な部品ごと一つの箱に詰めて動かす仕組み)で動くメールサーバーのOSS一式で、Mailcowは送信・受信・迷惑メール判定・ウイルス検査・Webメールをまとめた18コンテナ構成・メモリ最低4GB推奨のオールインワン、Mailuはより疎結合で軽い個人向け。

立ち上げまでは20分程度、初回の構築全体で3〜4時間という見積りに落ち着いた。残りはほぼ全部DNS側の作業(MXレコード、SPF/DKIM/DMARC、逆引き申請、到達テスト)だ。つまり「立てる」のは難しくない。やめた理由は別のところにある。

1. 家の回線からは原理的にできない。 送信には25番ポート(メールサーバー同士がメールを受け渡しする通信の出入口)が必要だが、ほぼすべてのISP(インターネット接続業者)が家庭向け回線でこれを塞いでいる。解除を申請できる業者もあるが、自分の住まいはサービスアパートで回線の契約者は建物の管理会社なので申請の当事者にすらなれない。多くのクラウド事業者も既定で塞いでいるので、借りる前に開放の可否を確認する必要がある。

2. 届くかどうかの9割は自分の手の外にある。 到達率を決めるのはDNSの認証設定(SPF/DKIM/DMARC)と逆引き、そして送信元IPアドレスの素性だ。前者は自分で正しく書ける。問題は後者で、VPS(レンタルサーバー)のアドレス帯は、過去に誰がどんな送信をしたかの履歴を引きずっている。自分が真面目に運用していても、同じ帯の隣人が迷惑メールを送っていれば巻き添えになる。なお新しいIPを「育てる」作業(初日10通→2日目50通→3日目200通と2〜4週間)が要るのは大量送信の場合で、個人の少量送信なら特別な対応は不要。🔴 自分はここを一度誤解していた。IPの素性が影響するのは自分が送るメールだけで、受信には関係ない。

3. 壊れたことが自分には見えない。 これが決定打だった。自前の写真サーバーが止まったら自分がアクセスして気づくし、困るのも自分だけだ。メールサーバーが止まった時に起きるのは「何も起きない」。

• 自分の受信箱は静かなままで、送った相手にもエラーが返らないことがある。相手のサーバーが黙って隔離・破棄するタイプだとバウンスメール(宛先不明で返ってくるお知らせ)すら出ない。自分はこの「エラーも通知もなく静かに届かない」状態を前記事の時点で経験している(原因は新規ドメインの送信履歴不足で、数日待つと解決した)
• 受信側が止まっていれば、その間に届くはずだったワンタイムコードや認証メールは期限切れになって消える。後から再送されない
• Mailuなどが既定で有効にしているグレイリスティング(初めての送信元のメールを一度わざと断り、再送してきたら受け取る対策)は初回を数分遅延させる。認証コードと相性が悪い(無効化可)
• 一番危ないのはドメインの失効だ。自動更新とカードの有効期限が切れていれば、サーバーが完璧でもアドレスごと死ぬ

4. 少数派であることの意味。 セルフホスト界隈の2025年のアンケート(約4,080人回答、約8割がIT系の職業)では、メールを自前ホストしている人は約14%。同じ調査でファイル共有(Nextcloud)は約30%いる。自前ホストに前向きなIT職の集団の中でさえメールは少数派で、「他の人が普通にやっているから自分にもできるだろう」という見積りはここでは通用しない。

「受信と保管は自前、送信だけ信頼のある業者から中継する」折衷案も検討した。到達率は買い取れるが構成が二重になり壊れる箇所が増える。検索の不満を解決するために構成を複雑にするのは逆方向だと判断して、検討を打ち切った。

考え方が変わった点: 「住所の層」と「倉庫の層」を分ける

自前をやめた直後、別の疑問が出た。「有料サービスに預けるなら、Googleに預けていたのと何が違うのか」。整理するとこうなる。自分をロックインしているのはアドレスであって、メールの保管場所ではない。

• @gmail.comを使っている限り、Googleをやめることはアドレスを捨てることとイコールだ。何百のサービスに登録した連絡先が全部死ぬので実質やめられない。これが代わりのきかない1社への依存
• me@example.comなら、ドメインは自分の所有物だ。業者を替える作業は、DNSのMXレコード(このドメイン宛のメールをどのサーバーが受け取るかの指定)を書き換えて、過去メールをIMAPでコピーするだけ。数時間から数日で終わる。アドレスは1文字も変わらないので登録先への連絡も要らない。これはいつでも取り替えられる部品への依存

データ主権の本質は「依存ゼロ」ではなく「依存を取り替え可能にすること」だ、という整理に行き着いた。この形なら、業者にお金を払うことは主権の放棄ではない。副産物として自分の依存の所在も見直せた。大手の個人向けサービスに本当に縛られていたのは写真とストレージの方で、メールではなかった。メールはドメインを持った時点ですでに自由だったのに、「乗り換えは大変だから」と思い込んでいた。

同じ理屈で、エイリアス層(アドレスを発行する層)とメールボックス層(メールを保管する層)も分けられる。エイリアス専業のサービスを手前に噛ませて受信箱は現状維持、という案はかなり有力だった(addy.ioはOSSで自前ホストもでき年$12、2026年9月時点)。却下したのは実質ひとりで運営されているサービスだったからで、メールの経路に置く部品としてはそこだけ飲めなかった。

比較で見た軸

見た軸は①検索の質 ②標準規格(IMAP/JMAP/CalDAV/CardDAV)への対応 ③カスタムドメインとエイリアスの扱い ④出口の広さ ⑤料金。料金はすべて2026年9月時点に自分が調べた額で、改定されるので契約前に各社の料金ページを見てほしい。

• Gmail / Google Workspace: 検索は最強。ただしデータ主権の観点では**「同じ課題を抱えた有料版」**で、変わるのは主権ではなく管理のしやすさだ。なおGoogleは2017年に個人向けGmailの広告目的の本文スキャンを公式に停止しているので、比較軸を「広告の有無」に置くのは的外れだと途中で気づいた
• 大手の個人向けサービスのカスタムドメイン機能(移行前の構成): 料金は圧倒的に安い。ただし1ドメインに作れるアドレス数に上限があり、キャッチオール(そのドメイン宛の存在しないアドレスも全部受け取る設定)に非対応。IMAPは使えるがメールソフトとの相性に癖がある
• Fastmail(豪州): カスタムドメイン最大100個・アドレス数の実質上限なし、IMAPとJMAP(IMAPの後継としてFastmail自身が標準化を主導した軽量な通信規約)に対応。Individual年€60(60GB)、30日間の無料トライアルあり
• その他: Migaduはドメイン数無制限だが最安プランは送信が1日20通まで。Proton MailとTutaは無料プランがIMAP非対応で普通のメールソフトから使えない。国内事業者は日本語サポートが魅力だが安いプランは送信用IPが他の契約者と共有で、②の「隣人の巻き添え」をそのまま引き受ける

🔴 前提がひとつ間違っていた。Fastmailを「大手の傘下」だと記憶していたが、買収は2010年で2013年に従業員が買い戻して以降は独立系だった。親会社リスクの評価をやり直すことになった。業者の資本関係は記憶で判断しないこと。

決めたこと: Fastmail

年€60を払う価値があるとすれば、それはサーバー側の全文検索だった。手元のPCで索引を作らない方式なら冒頭の問題は原理的に起きない。裏付けもあった。FastmailはIMAPサーバーの主要な開発元のひとつで、検索には全文検索エンジン(Xapian)を使い、日本語・中国語・韓国語の分かち書きに対応するためにそのフォークを自前でメンテナンスしている。日本語は英語のように単語が空白で区切られていないので、ここが検索の成否を分ける。

ただし説明文で判断せず実測で決めた。無料トライアルに申し込み、既存のメールを丸ごと流し込んだ。DNSは一切触らないので既存環境への影響はゼロ。インポートはサーバー側で自走するのでPCを閉じてよかった(前回の移行が自作スクリプト頼みで何度も中断したのとは対照的だった)。保存先のリージョンはEUを選んだ(既定は米国)。5万通強のインポート完了後、「豚汁」で検索した。即座に出た。 唯一の未検証点が消えたので課金を決めた。

🔴 トライアルではカスタムドメインが使えない(有料プラン必須)。他に送信120通/日、サーバー側の振り分けルール作成不可といった制限もある。本番切替は「先に年額を払う」ところから始まる。トライアルでできるのは検索の実測までだと割り切るしかない。

得たのは検索だ。失ったものも書いておく。

• うろ覚えに強い検索ではない。速度はGmail級だが、Gmailの「表記ゆれや曖昧な記憶でも何となく当ててくる」ランキングは無く、書いた通りに素直に探す
• 迷惑メールフィルタはGmailと同格ではない。Gmailは世界最大の受信データで学習していて事実上最強だ。漏れを感じたら自分で学習させ、振り分けルールで詰める手間がかかる
• カレンダーと連絡先は自己完結型だった。この2つの本体は自前のサーバーに置いているので「データは自分で持ったまま画面だけ借りる」ができるか調べた。カレンダーは外部のサーバーを登録して双方向に同期できる(ただし予定のコピーが業者側にも載る)。連絡先には同等の機能が無く、一度だけの取り込みしかできない。結果、この2つの移行は見送った。🔴 この件で自分は2回誤った断定をした。「外部カレンダーは読み取り専用しか無い」と書いたが、設定画面には「アカウントを追加」と「購読」という別々の欄があり、読み取り専用なのは後者だけだった。公式ヘルプの検索結果で機能の有無を断定せず、設定画面を開いて確かめること
• 「航空券やレストランの予約確認メールが自動でカレンダーに入る」機能は失われる。大手の独自のメール解析エンジンに依存した機能なので、メールとカレンダーのどちらか片方を移しても再現されない。標準規格ではないものは移行で残らないという分かりやすい例だった。取り戻す道は、予約確認メールを検知して自分のカレンダーに書き込む仕掛けを自作することだけ。まだ作っていない

切替作業: 順番を間違えると送信が全滅する

🔴 業者の案内通りにやると事故る点が2つあった。 ①**「SPFのTXTレコードを新規追加してください」と指示されるが、既存のSPFがある状態でそれをやるとドメインにSPFが2つ存在して仕様違反(PermError)になる**。認証が落ち、p=rejectなので送信が全滅する。正解は追加ではなく1つのレコードへのマージ(include:を並べる)。②案内された値の末尾が?all(該当しない送信元は判定しない)で、自分の既存設定は-all(完全に拒否)だった。言われた通りにすると防御を弱めるので採用しなかった。

もう1つ自分で踏んだ罠。受け取り先のサーバー名はリージョンによって違う。自分はEUを選んだのに、ヘルプ画面に例示されていた画像は米国リージョンのサーバー名だった。画像の値を写すと動かない。設定画面が自分のアカウント向けに表示している値を正とすること。

送信側の設定(SPF/DKIM)と受信側の設定(MX)は独立に変更できる。この性質を使って、受信を止めずに送信だけ先に検証する順序にした。①課金してカスタムドメインを登録(所有確認用のTXT) → ②SPFを1レコードにマージ(古い業者のinclude:は並行稼働の間は残す) → ③DKIM(メールが改ざんされていないことを証明する電子署名)用のCNAMEを追加 → ④差出人設定 → ⑤ここで送信テスト(受信は旧業者のまま無傷なので失敗しても何も壊れない) → ⑥合格を見てからMXを切替。

送信テストはmail-tester.comのような診断サイトに送って点数を見るのが手軽だった(自分は10/10)。加えて厳しいフィルタを持つ組織宛に実際に1通送って届くか確認すること。この手の相手は黙って捨てるので、「エラーが出なかった」は到達の証拠にならない。

• 🔴 切替直後のテストメールは旧メールボックスに着弾した。送信側のDNSキャッシュが古いMXを掴んでいたためで、30分待って再テストしたら新しい受信箱に入った。旧メールボックスを残しておいたのでメールは消えなかった。切替後は最大1時間ほど旧MXに届くと見込んで、旧メールボックスはしばらく生かしておくこと
• 復旧用メールアドレスに、移行するアドレス自身を指定してはいけない。MX切替後は復旧先が移行先の中に入り、そこに入れない事態では何もできない循環依存になる。2要素認証のバックアップコードも同じ受信箱に置かない
• 旧メールボックスを空にする前に、Message-ID(メール1通ごとの一意な識別子)で全件照合した。総通数の一致は「両方向の差が打ち消し合っているだけ」のことがあるので、集合として包含されているかを見る必要がある(前記事で4,293件を失った経験から来ている)。旧側にしか無かったのは25通だけだった
• 移行後、5万通強が業者のサーバーにしか存在しない状態になっていた。写真やファイルは毎晩クラウドへ送っているのにメールだけ体制の外だったので、IMAPで自分のサーバーへ毎晩写し、既存のバックアップ(バックアップを「消されても戻せる」形にする)に載せた。🔑 肝は追記専用にすること。同期を一方通行にしてローカル側で消さない設定にすれば、サービス側で消してもローカルからは消えない

一番時間がかかったのは「登録アドレスの付け替え」

誰も警告してくれないので強調しておく。技術的な切替は1日で終わる。各サービスに登録してあるメールアドレスを1件ずつ付け替える作業は数週間かかる。

実際に付け替えたのはこういうカテゴリだった。具体名は挙げない(自分がどのサービスを使っているかの一覧は、他人にとってはフィッシングの的だ)。ブラウザやOSのアカウント / クラウド・インフラ事業者とドメイン登録事業者 / 通販・デリバリー / 新聞や有料購読 / 健康・計測系のアプリ / 趣味の会員サービス / 銀行・カード・証券。

やり方は3つ組み合わせた。

1. パスワードマネージャーの項目一覧をチェックリストにする。これが「自分がどこに登録しているか」の唯一の全体像だった。記憶では必ず漏れる
2. 受信箱そのものを台帳として使う。アドレスを変えると「メールアドレスが変更されました」という通知が届くので、新しい受信箱に溜まったその通知が、完了したサービスの記録になる
3. 旧アドレスへの転送を残しておく。これが一番効いた。まだ切り替えていないサービスが、メールを送ってくることで自分から名乗り出てくる

🔴 順番の注意: 復旧経路になっているサービス(ドメイン登録事業者、DNS事業者、クラウドストレージ、パスワード管理、そしてメール業者自身)から先に手を付けると、作業中に自分を締め出す事故が起きうる。これらは最後、かつ新しい受信箱が確実に動いていることを確認してからにした。

そして正直に書くと、この作業はまだ終わっていない。移行から1年近く経っても、旧アドレス宛にしか届かないメールが時々ある。転送を切るタイミングはまだ決めていない。

サービスごとに別アドレスを配る案は、半分だけ採った

ドメインを持っているとサービスごとに別のアドレスを配ることができる。漏れたらどこから漏れたか分かるし、1本ずつ止められる。移行先にはこれを自動でやる機能があり、自前のパスワードマネージャー(Vaultwarden)から呼び出してログイン情報を保存する操作と同時に新しいアドレスを発行できる。実際に動かした。

• 🔑 発行するドメインを自分のドメインに切り替えてから使い始めること。既定では業者のドメインで発行される。それで何十本も発行すると、業者をやめた瞬間に全部死ぬという、まさに避けたかったロックインを自分で作り直すことになる。自分のドメインなら、移行先でキャッチオールを有効にすれば受信を継続できる
• ⚠️ 発行したアドレスは最初「保留」状態で、一度も使われないまま24時間で自動削除される。発行だけして後で使うことはできない

ここで立ち止まった。「迷惑メールはサーバー側のフィルタで止まるのだから、これに意味があるのか」。考え直して、よく挙げられる利点のほとんどは自分には効かないと認めた。迷惑メールの削減→フィルタで解決済み。使い回し攻撃の防止→すべてのパスワードが固有なので追加効果はほぼゼロ。流出元の特定→分かっても打てる手は無効化だけで、フィルタで捨てるのと同じ。フィッシングの判別→リンクを踏まない習慣があれば不要。

残る本物の利点は1つだけ。名寄せへの耐性だ。 単一のアドレスはデータブローカーにとって結合キーになり、A社の流出とB社の流出が機械的に突き合わされてプロファイルが組まれる。迷惑メールフィルタはこれに一切効かない。受信箱は静かなまま、外側で自分の像が育っていく。 困っていないが他人が自分のデータでできることを減らす、という動機で、自前ホスティング全般と同じ理由だ。日々の受信箱の快適さとは無関係なので、使っていて価値を体感できないのは当然だった。

そこで既存サービスの一括移行はやらず、新規登録の時だけ使うことにした。新規はボタン1回でコストがほぼゼロだが、既存の移行は実作業に加えて24時間ルール・ログインIDを変更できないサービス・連絡経路が切れるといった失敗モードを抱えるので、損益が非対称になる。

• 🔴 そもそも移してはいけない層がある。メール業者自身、OSやプラットフォームのアカウント、ドメイン登録事業者、DNS事業者、パスワード管理、認証基盤、クラウドストレージ、銀行・証券・カード。復旧経路にとって「1本ずつ切れる」は「1本ずつ壊れる」に反転する
• 📌 増やしすぎると出口が狭くなる。業者をやめる時、移行先でキャッチオールが必須になる。数十本なら問題ないが、数百本に膨らませると取り替え可能性を自分で削ることになる。なおキャッチオール自体は無効(拒否)にした。有効にするとinfo@やadmin@といった辞書総当たりの迷惑メールを全部受けてしまい、存在しないアドレスなので個別に止める手段がない
• ⭐ 一番しっくり来た用途は公共WiFiの登録画面だった。アドレスをマーケティングリストに流す前提のところが多く、24時間の自動削除がここでは利点になる。⚠️ ただし「メールの確認リンクを踏んでください」型だと、まだ繋がっていないのでそのメールが読めない。繋ぐ前にモバイル回線で発行しておくしかない

今の構成と、やらなかったこと

正本=メールサービス側 / バックアップ=自分のサーバー上の追記専用コピー→クラウド(暗号化) / クライアント=公式アプリのみ。デスクトップのメールソフトは撤去した。移行先の安定性を実測で確認できて見張り役が不要になり、ローカルコピーはPC1台の中にしかなくバックアップの本数に数えられなかったからだ。なお公式アプリもオフライン用にメールをキャッシュするが、これはバックアップに数えない。サーバーに無いメールを溜め込める古いメールソフトと違い、単なるサーバーの写しだ。

やらなかったこと。メールの自前ホスティング — この記事の半分を使って却下した。副産物として、サーバーを選ぶ時の「25番ポートが開放できること」「メール専用のIPを分けられること」という制約が消え、他の用途だけで選べるようになった。既存サービスのアドレスをサービス別エイリアスに移すこと — 上記の通り撤回した。カレンダーと連絡先の移行 — 「データは自分で持ったまま、一番手前の画面だけ借りる」組み合わせが存在しなかったので見送った。不満が出たら画面だけ替えればいい(倉庫が自分のものなら、アプリは捨てられる=取り返しがつく)。

残っている単一障害点はドメインの更新忘れだ。メールボックスの業者は取り替えられるが、ドメインを失うとアドレスごと失う。自動更新と登録してあるカードの有効期限は、年に一度は目で見ておくことにした。

更新履歴 — 2026-10-05: 初版