Xserver解約前の確認リスト｜メール移行とDBバックアップ実録

2026/5/16

Xserver解約前に確認したこと

Xserverを6月末に解約する予定で、WordPress 6サイトをHetzner VPSへ移行してきました。

WordPress本体の移行はすでに完了していました。でも、「ファイルとDBが移れば終わり」ではありませんでした。メール受信の設定、GmailからのSMTP送信、メール配信サービスの認証、DBのバックアップ。これらがまだXserverに依存したままになっていたんです。

解約後に「メールが届かない」「送信できない」という状態になってから気づくのでは遅いですよね。この記事では、私がXserver解約前に行ったメール移行とバックアップ作業を、実際にやった順番で整理します。

Cloudflare Email Routingでメール転送を設定した

最初に取り組んだのが受信メールの移行です。

対象は3ドメインのinfo@アドレスでした。

info@bizinets.biz
info@bizinets.co.jp
info@jogtime.jp

これらがXserverのメールサーバーに設定されていたため、解約するとメールが届かなくなります。

Cloudflare Email Routingを選んだ理由

VPSにメールサーバーを立てる選択肢もありました。ただ、メールサーバーの運用は管理コストが継続的にかかります。スパム対策やサーバー障害時の対応など、自前で持つには手間がかかりすぎると判断しました。

Cloudflare Email Routingは受信メールをGmailに転送する仕組みで、Cloudflare側の案内に沿ってMXレコードや必要なTXTレコードを設定するだけで動きます。無料で使えて管理も最小限で済みます。

設定の流れ

Cloudflareのダッシュボードで各ドメインの「Email」→「Email Routing」を開くと、設定ウィザードが始まります。

まず最初に直面したのが、既存のMXレコードの問題でした。Xserver時代のMXレコードとSPFレコードが残っていて、そのままでは新しい設定を追加できません。画面上に「Conflicting records」として表示されるので、Deleteで削除してから進みます。

削除後に「Add records and enable」ボタンをクリックすると、Cloudflare Email Routingに必要なMXレコードやTXTレコードが追加され、Email Routingが有効になります。

転送ルールは各ドメインのRouting rulesタブから設定します。Custom addressに「info」を入力して、転送先のGmailアドレスを指定するだけです。

判断基準：旧MXが残っている → 先に削除してから新しいレコードを追加する（順番を守らないと設定が競合する）

bizinets.bizはすでに承認済みだった

2つ目のドメイン以降は、転送先のGmailアドレスがすでに「承認済み」として登録されています。bizinets.bizで確認メールを承認していたので、bizinets.co.jpとjogtime.jpは転送ルールを作るだけで済みました。

GmailのSMTP設定がXserverのままだった問題

受信メールをCloudflareで解決した後、送信側に盲点がありました。

Gmailからinfo@bizinets.bizで返信できるように設定していたのですが、設定画面を確認したところ、SMTPサーバーがsv745.xserver.jpのままになっていたんです。

これはXserver解約後に送信ができなくなることを意味します。気づかないまま解約していたら、メールを送っても相手に届かない状態がしばらく続いたかもしれません。

Googleアプリパスワードを発行する

GmailのSMTP設定を変更するには、通常のGoogleパスワードは使えません。アプリパスワードという16桁の専用パスワードが必要です。

アプリパスワードを発行するには、Googleの2段階認証が有効になっている必要があります。今回は2段階認証が未設定だったので、先に設定しました。

設定の流れはこうです。

Googleアカウント（myaccount.google.com）にログイン
セキュリティ → 2段階認証プロセスを有効化（パスキーで設定）
myaccount.google.com/apppasswords にアクセス
アプリ名を入力して「作成」→ 16桁のパスワードが表示される

この16桁のパスワードはこの画面でしか確認できません。必ずメモしてから画面を閉じてください。

GmailのSMTP設定を変更する

Gmailの設定画面で「アカウントとインポート」→ info@bizinets.bizの「情報を編集」を開きます。

SMTPサーバーをXserverのものからGoogleのものに書き換えます。

SMTPサーバー：smtp.gmail.com
ポート：587
ユーザー名：Gmailのアドレス（SMTP認証に使うGmailアカウントのアドレスを入力します。差出人として表示したいinfo@アドレスではありません。）
パスワード：先ほどのアプリパスワード16桁

保存後、経由サーバーの表示が「smtp.gmail.com」に変わっていれば完了です。

判断基準：経由サーバーに社外ドメインが残っている → Xserver解約前に必ずsmtp.gmail.comに変更する

Benchmark EmailのSPF・DKIM・DMARCをCloudflareに設定した

メルマガや配信メールをBenchmark Emailで送っている場合、送信ドメイン認証のDNS設定も確認が必要です。

この設定はXserverのMXレコードとは別の話です。受信メールの移行が完了していても、配信認証は独立して確認する必要があります。Cloudflareで管理するDNSに追加する作業なので、まとめて確認しました。

bizinets.bizは既存設定を確認

Benchmark Emailの管理画面で、bizinets.bizのDNSレコード設定を確認しました。

SPF（CNAME）・DKIM（CNAME）・DMARCのレコードが表示されます。「設定を確認する」ボタンをクリックしたところ、bizinets.bizはすでに全レコードにチェックマークがついていました。

jogtime.jpは新規でドメインを追加

jogtime.jpはBenchmark Emailに登録していなかったので、新規でドメインを追加しました。

追加するとSPF（CNAME）・DKIM（CNAME）のホスト名と値が表示されます。CloudflareのDNS設定でこれらをCNAMEレコードとして追加します。Proxy statusは必ずDNS onlyにします。

DMARCはTXTレコードで_dmarcというホスト名に追加します。Benchmark Emailが提示する値をそのまま使えます。

追加後にBenchmark Emailで「設定を確認する」をクリックして、全レコードにチェックマークが付けば完了です。

判断基準：メール配信サービスを使っているドメインがある → 解約前にSPF・DKIM・DMARCの認証状況を必ず確認する

なお、Cloudflare Email Routingの受信設定とBenchmark Emailの配信認証は別物です。受信転送が完了しても、配信認証は別途Cloudflare DNSに追加して確認する必要があります。

VPS上のWordPressファイルをFileZillaで確認した

バックアップを取る前に、VPS上のWordPressファイル構造を確認しました。

これまでXserverへのFTP接続にFileZillaを使っていたので、同じツールをVPSへのSFTP接続に使うことにしました。

FileZillaでVPSにSFTP接続する

FileZillaのサイトマネージャーで新しいサイトを作成します。

プロトコル：SFTP - SSH File Transfer Protocol
ホスト：VPSのIPアドレス
ポート：22
ログオンタイプ：通常
ユーザー：root
パスワード：VPSのrootパスワード

接続すると/var/www/以下にWordPressのフォルダが並んでいるのが確認できました。各サイトごとにディレクトリが分かれていて、XserverのpublichtmlやFTP構造とは異なりますが、ファイルの中身はWordPressと同じです。

今回は初回確認としてパスワード認証で接続しました。常用する場合は、鍵認証や接続ユーザーの分離も検討した方が安全です。

FileZillaで直接ファイルを確認できるようになったことで、「何がどこにあるか」が把握できました。バックアップ対象の確認にもなりましたし、今後ファイルの修正が必要なときにも使えます。

判断基準：VPSへのSFTPが初回 → パスワード認証で接続を先に確認してから、鍵認証に切り替えるか判断する

mysqldumpで6サイト分のDBバックアップを取得した

VPSへの接続が確認できたところで、DBバックアップを取りました。

WordPressのデータベースには記事・設定・テーマのカスタマイズ情報が入っています。ファイルだけ移行できてもDBがなければWordPressは動きません。記事本文はGoogleドライブにも残っていますが、WordPressとして復旧するにはDB・テーマ設定・メディアファイルなどが必要です。

mysqldumpで一括取得する

PowerShellからSSH接続して、以下の手順で進めました。

まずバックアップ保存先を作成します。

以下は私の環境での例です。DB名や保存先パスは、自分の環境に合わせて変更してください。

mkdir -p /root/backup/db

次に6サイト分を順番にダンプします。

mysqldump -u root wp_bizinets_biz > /root/backup/db/bizinets_biz.sql
mysqldump -u root wp_bizinets_co_jp > /root/backup/db/bizinets_co_jp.sql
mysqldump -u root wp_bizinets_jogtime > /root/backup/db/jogtime_jp.sql
mysqldump -u root wp_shibukidai > /root/backup/db/shibukidai_com.sql
mysqldump -u root wp_karadanonioi > /root/backup/db/karadanonioi_info.sql
mysqldump -u root wp_4buki > /root/backup/db/4buki_net.sql

コマンドが成功すると何も表示されず次のプロンプトが返ってきます。エラーが出た場合はDB名が間違っている可能性があるのでmysql -u root -e "SHOW DATABASES;"でDB名を確認します。

取得結果の確認

ls -lh /root/backup/db/

実際の取得結果はこうなりました。

-rw-r--r-- 1 root root 333K May 14 12:49 4buki_net.sql
-rw-r--r-- 1 root root  16M May 14 12:49 bizinets_biz.sql
-rw-r--r-- 1 root root 7.6M May 14 12:49 bizinets_co_jp.sql
-rw-r--r-- 1 root root  12M May 14 12:49 jogtime_jp.sql
-rw-r--r-- 1 root root 9.3M May 14 12:50 karadanonioi_info.sql
-rw-r--r-- 1 root root 1.8M May 14 12:49 shibukidai_com.sql

合計46MBほどでした。テキストデータなので圧縮なしでもこのくらいのサイズに収まります。

FileZillaでGoogleドライブにダウンロード

VPS上の/root/backup/db/を確認したら、FileZillaを使って6つの.sqlファイルをローカルのGoogleドライブフォルダにドラッグ&ドロップでダウンロードしました。

これでVPSが消えても、このSQLファイルがあれば別のサーバーにWordPressを復元できます。

判断基準：VPSが急に止まる可能性がある → まずDBダンプを取得してクラウドストレージに保存する（テーマ・メディアは後でよい）

Xserver解約前にやっておくべき確認リスト

今回の作業をチェックリストにまとめます。

Xserver解約前に確認すべき項目はこうなります。

メール受信の確認

旧MXレコード・SPFレコードがCloudflareに残っていないか
Cloudflare Email Routingが有効（Enabled）になっているか
各ドメインのinfo@メールが転送先Gmailに届くか（テスト送信で確認）

メール送信の確認

GmailのSMTP設定でXserverドメインが経由サーバーになっていないか
smtp.gmail.comに変更済みか

配信認証の確認

Benchmark Emailなどのメール配信サービスのSPF・DKIM・DMARCが認証済みか
使用中の全ドメインで確認済みか

バックアップの確認

VPSにSFTP接続できるか
DBダンプを6サイト分取得済みか
Google Driveなど別の場所に保存済みか

これを1つずつ確認してから解約手続きに進むと、解約後のトラブルを防げます。

この後どうなったか

この記事を書いている時点では、Xserver解約はまだ完了していません。6月末の解約に向けて、メール・バックアップの作業が完了した段階です。

次のフェーズとして残っているのは、mekara-uroko.xyzの静的HTMLをCloudflare Pagesへ移行することと、テーマファイル・メディアファイルのバックアップです。DBは取得済みなので、最低限の保護はできている状態です。実際に解約した後の状態は、また別の記事で記録します。

まとめ

今回の作業で気づいたのは、「WordPressを移行しただけでは解約できない」という事実です。

メール受信・SMTP送信・配信認証・DBバックアップ。これらはそれぞれ独立した依存先になっていて、1つでも見落とすと解約後に困ります。特にGmailのSMTP設定がXserverのままになっていたのは、自分でも気づいていませんでした。

今日できる一歩としては、まずGmailのアカウントとインポート設定を開いて、差出人アドレスの「経由サーバー」を確認することをおすすめします。XserverやレンタルサーバーのドメインがSMTPとして残っている場合は、解約前に変更が必要です。

今回の作業は、単なる設定変更ではありませんでした。

Xserver解約という判断の裏側には、

「どの契約が重複しているのか」

「どの依存先を先に外すべきか」

「何をバックアップしておけば復旧できるのか」

という整理が必要でした。

この判断軸は、bizinets.bizの記事で詳しく整理しています。

→ 固定費を下げる前に、重複している仕組みを見直す判断設計

bizinets.biz

記事を読んで「もっと知りたい」と思ったあなたへ

bizinets.biz では、ビジネスの仕組みづくりを体系的に学べるコンテンツを用意しています。まずは一度、覗いてみてください。

bizinets.biz へ行く →