会社のメールをGoogle Workspaceへ移行した手順｜MX・SPF・DKIMと送信設定の落とし穴

うちの会社のメールは、長いあいだレンタルサーバーのメール機能で動いていました。会社のドメインのアドレスで届くメールを、サーバー会社が受け取っていた形です。

2026年10月7日から8日にかけて、その受け取り先をGoogle Workspaceに切り替えました。

私はエンジニアではありません。社内にもいません。この記事は、そういう会社の社長が、メールの引っ越しでやったことと、途中で気づいたことの記録です。

先に答えを書きます

やったことを、順番に表にしました。

やったこと	なぜ	設定した場所
Googleの所有権確認用のTXTレコードを追加	このドメインの持ち主だとGoogleに示すため	サーバー会社のDNS
会社のアドレスを別名（エイリアス）として追加	会社のアドレス宛てのメールを、今の受信箱で受け取るため	Workspaceの管理画面
MXレコードをGoogleに変更し、「ローカル配送」をOFF	メールの届け先をGoogleに切り替えるため	サーバー会社のDNSとメール設定
SPFレコードにGoogleを追加（サーバー会社の分と併記）	Googleから送ったメールを、正しい送信元として扱ってもらうため	サーバー会社のDNS
DKIM（2048ビット）を作成し、DNSに追加して「認証を開始」	送ったメールに電子署名を付けるため	Workspaceの管理画面とサーバー会社のDNS

表の5つのうち、4つはサーバー会社の管理画面にあるDNSという設定です。戻し方は、後半に書きます。

作業は2日で終わりました。いちばん大きかったのは、作業の前に分かったことと、作業のあとに気づいたことでした。 前者は普段のGmailの正体、後者は送信の設定です。

切り替える前の、うちのメールの状態

会社のアドレスのメールは、ConoHa WINGというレンタルサーバーのメール機能で受け取っていました。

切り替えの方法として、最初は「Gmailから転送する」形を考えていました。ところが、調べていくうちに前提が変わりました。

調べたら、普段のGmailがWorkspaceそのものだった

普段使っているGmailのアカウントを確かめたところ、2013年に作ったGoogle Workspaceの管理者アカウントと、同じアカウントでした。受信箱も同じです。

昔、もともと使っていたGmailのアカウントが、Workspaceのアカウントになっていたようです。私はそれを把握していませんでした。

メールの履歴も、ラベルも、ドライブのファイルも、そのまま同じ場所にありました。

ということは、会社のアドレスを自分のアカウントの別名として足せば、今の受信箱でそのまま受け取れます。当初考えていた転送の作業は、要らなくなりました。

MX・SPF・DKIMを平たく言うと

作業の中に、聞き慣れない言葉が3つ出てきます。Googleの公式ヘルプをもとに、平たく書くとこうなります。

言葉	ひとことで言うと
MXレコード	メールの届け先。送る側のコンピューターが、この会社宛てのメールをどこへ届けるかを調べるときに見る設定です
SPFレコード	送信元として許可するサーバーの一覧。ここに載っていないサーバーから届いたメールは、怪しいと扱われやすくなります
DKIM	メールに付ける電子署名。受け取った側が、なりすましでないかを確かめられます

どれも、サーバー会社の管理画面にある「DNS」という設定に書き込みます。DNSは、ドメインについての案内板のようなものです。

GoogleのMXの値は、Google Workspace の MX レコードを設定するに、smtp.google.com、優先度1と書かれています。同じページには、新しい設定がインターネット全体に行き渡るまで、最長で72時間ほどかかることがあるとも書かれています。

SPFはSPF を設定する、DKIMはDKIM を設定するに手順があります。DKIMのページでは、DNSが対応していれば2048ビットの鍵を選ぶよう案内されています。

やった手順

実際にやった順番です。

サーバー会社のDNSに、Googleのドメイン所有権確認用のTXTレコードを追加した
Workspaceの管理画面で、会社のアドレスを別名（エイリアス）として追加した
MXレコードをGoogle（smtp.google.com、優先度1）に変更した。あわせて、サーバー会社側のメールの「ローカル配送」をOFFにした
SPFレコードにGoogleを追加した。サーバー会社の分は消さずに、併記した
DKIM（2048ビット）をWorkspaceで作成し、DNSに追加してから「認証を開始」を押した

「ローカル配送」は、サーバー会社の中でメールを受け取るための設定です。

作業はAI（Claude）に手伝ってもらいながら進めました。サーバー会社の管理画面の一部の確認ボタンは、自分で押しました。

届いたかの確認と、戻し方

切り替えたあと、外部のアドレスから会社のアドレスにメールを送って、受信できることを確かめました。

戻し方も決めてから進めています。MXを元の値に戻し、ローカル配送をONにすれば、元の形に戻ります。

そのため、サーバー会社側のメールアドレスは、まだ消していません。 安定するまでは、戻れる状態を残しておくことにしました。

落とし穴は「送信」の設定でした

受け取りの設定が終わってから、1つ気づいたことがあります。

Gmailには「他のアドレスから送信」という設定があります。会社のアドレスを差出人にしてメールを送るための設定です。

うちの場合、この送信が、サーバー会社のメールの仕組み（SMTP）を通って出ていく設定になっていました。

受け取り先をGoogleに変えても、送信の経路は変わっていなかったわけです。整理すると、こうなっていました。

	経路	状態
受け取り	MXレコード	Googleに切り替え済み
送信	Gmailの「他のアドレスから送信」	サーバー会社のSMTP経由のまま

受け取りの設定だけを見ていると、送信も一緒に移ったように思えてしまいます。実際には、2つは別々の設定でした。この状態でサーバー会社側のメールアドレスを消すと、会社のアドレスの名前でメールを送れなくなります。

サーバー会社側のアドレスを消すのは、送信の経路を切り替えてからです。受け取りと送信は、別々に確かめる必要がありました。

SPFにサーバー会社の分も併記してあるのは、この点にも関わります。送信がサーバー会社を通っている間は、サーバー会社のサーバーも送信元の一覧に載っている必要があります。

なお、Gmailのメール送信者のガイドラインでは、すべての送信者にSPFかDKIMの設定を求めています。1日に5,000件以上送る送信者には、SPFとDKIMに加えてDMARCという設定も求められています。

もう一つ気づいたこと：支払いが止まると影響が大きい

今回の切り替えで、個人で使ってきたGmailの全部の履歴が、Workspaceの契約の上に乗った形になりました。

ということは、支払いが止まったときの影響が大きいということです。会社のメールだけでなく、これまでの履歴も同じ契約の上にあります。

そこで、支払い方法としてカードが登録されていることを確かめました。Workspaceは無料の試用期間が終わると有料になります。

料金はユーザー数とプランで変わります。最新の金額はGoogle Workspace の料金ページで確認できます。2026年10月時点では、14日間の無料試用があると書かれていました。

あわせて、契約していたMicrosoft 365は、継続請求をオフにしました。2026年12月に失効する予定です。

やる前に確認すること

同じような切り替えを考えている会社向けに、うちで実際に確かめたことをまとめます。どれも、DNSの値を書き換える前に確かめられることです。

今のアカウントの状態：普段使っているGmailが、すでにWorkspaceのアカウントになっていないか。うちはなっていて、転送が要らなくなりました
送信の経路：Gmailの「他のアドレスから送信」が、どこを通って送る設定になっているか。サーバー会社のアドレスを消す前に見ておく必要があります
戻し方：MXとローカル配送を、どの画面でどう戻すか。元の値を控えておきます
支払い：試用期間のあとに有料になること。支払い方法が登録されているか
DNSを触れる人：サーバー会社の管理画面に入れて、DNSの設定を変えられる人が誰か。うちは、一部の確認ボタンを自分で押しました

まとめ

会社のメールの受け取り先を、レンタルサーバーからGoogle Workspaceに切り替えた。作業は2026年10月7日から8日
調べたら、普段のGmailが2013年に作ったWorkspaceの管理者アカウントと同じだった。転送の作業は要らなくなった
手順は、所有権確認のTXT、別名の追加、MXの変更とローカル配送のOFF、SPFへの追加、DKIMの作成と認証の5つ
外部から送って受信を確かめた。MXを戻してローカル配送をONにすれば元に戻るので、サーバー会社側のアドレスは残している
落とし穴は送信だった。「他のアドレスから送信」がサーバー会社のSMTP経由のままだった
個人の履歴もWorkspaceの契約の上に乗ったので、支払い方法の登録を確かめた

会社のメールをレンタルサーバーからGoogle Workspaceに移した記録｜手順は5つ、落とし穴は送信設定でした