自分のドメインのメールをどこに置くか、一周して決め直した

検索が効かなくなったのをきっかけに、自分のドメインのメールの置き場所を考え直した記録。Mailcow/Mailuでの自前ホスティングを本気で検討して却下した理由、「住所の層」と「倉庫の層」を分ける考え方、切替で送信が全滅しかけたDNSの罠、数週間かかった登録アドレスの付け替えまで書いた。

• 公開日：: 2026-10-05
• タグ：: メール Fastmail 自前ホスティング Mailcow DNS SPF

メールをGmailから自分のドメインに移すの続き。あの時点の構成は「ドメインは自分の所有、メールボックスは大手の個人向けサービスのカスタムドメイン機能、読み書きはデスクトップのメールソフト」だった。これを一周考え直して、有料のメールサービス(Fastmail)に移した。途中で自前ホスティングを本気で検討して却下しているので、その理由を一番厚く書く。

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

前提

• 自分名義のドメインを持ち、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社への依存
• [email protected]なら、ドメインは自分の所有物だ。業者を替える作業は、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: 初版