Google Workspaceへメールを切り替えるときは、Google管理コンソールが対象ドメインへ示す現行値を使います。インターネット上には従来の複数MXを使う手順も残っていますが、現在の新規設定向け案内とは値の構成が異なります。動作中の従来構成を、古いという理由だけで変更する必要もありません。
最初にドメイン所有権を確認し、利用者と受信先を作ります。送信認証を準備してからMXを切り替えるのが安全な順番です。Google Workspace以外にWebフォームや配信サービスが送信する場合は、それらもSPF・DKIM・DMARCの対象へ含めます。
最初にドメイン所有権とDNSの編集先を確認する
Google Workspaceでは、指定されたTXTなどのレコードをDNSへ追加し、ドメインを所有していることを確認します。レコード値は管理コンソールのセットアップ画面から取得します。他社の記事に載っている確認コードを転記しても、自社ドメインの確認には使えません。
次に、現在のネームサーバーを外部から確認します。ドメイン購入会社とDNS提供会社が異なる場合は、実際の権威DNSを管理する画面へレコードを追加します。現在のMX・TXT・A・CNAMEを保存し、変更前へ戻せる状態にします。
Google Workspaceの設定だけを理由に、ネームサーバー全体やWebサイト用のAレコードを変更しません。メールの受信先はMX、所有権や認証はTXTやCNAMEなど、指定されたレコード単位で変更します。入力方法はDNS事業者によって異なるため、名前欄の@や末尾の点の扱いを確認します。
MX変更前に利用者・エイリアス・グループを作る
MXを先にGoogleへ向けると、新しく届いたメールはGoogle側へ配送されます。該当する利用者やエイリアスがなければ、宛先不明で拒否される可能性があります。現在のメールアドレスを棚卸しし、個人・共用・転送・メーリングリストを分けて新環境へ用意します。
退職者のアドレスやcatch-allをそのまま再現するかは、業務とセキュリティの観点で判断します。不要な宛先を増やさず、必要な過去アドレスには担当者と終了日を設定します。Googleグループで受ける場合は、外部送信者から投稿できるかも確認します。
利用者へライセンスを割り当てただけで、旧サーバーのメールが移るわけではありません。過去メールの移行と、パソコンやスマートフォンの設定は別工程です。旧環境を解約する前に、対象期間と必要なフォルダーを確認します。
MX値はGoogleの現行公式案内と管理画面を正にする
Google WorkspaceのMX公式案内では、現在の新規設定向けMXと、2023年より前から使われる従来MXの両方を説明しています。動作中の従来MXは変更不要とされています。新規導入では、管理コンソールと現行案内が示す値・優先値をそのまま使います。
古いメールサービスのMXを予備として混在させないようにします。Googleと旧環境が同じ宛先を一貫して扱う構成でなければ、メールがどちらへ入るか分かりにくくなります。切り替え前に現在値を保存し、計画した時刻に公式値へ置き換えます。
DNSへMXを登録したあと、Google管理コンソールで対象ドメインのGmailを有効にします。DNSへ値が見えても、管理コンソール側の手続きが終わっていないことがあります。外部からMXを取得し、Google側の診断結果と合わせて確認します。
SPFはGoogle以外の送信経路も一つにまとめる
Google Workspaceだけから送信するドメインなら、Google公式のSPF案内が示す値を使えます。しかし、会社サイトのフォーム・複合機・請求サービス・メール配信サービスが同じドメインで送るなら、Googleだけを登録しても足りません。
同じドメインへv=spf1で始まるレコードをサービスごとに複数作らず、正規の送信元を一つのSPF方針へ統合します。追加前に、既存SPFがないかを外部DNSで確認します。includeなどDNS参照を増やしすぎると評価上限へ達するため、使っていない送信サービスを削除します。
WebフォームのFromへ訪問者のアドレスを使うと、認証と表示ドメインが整合しません。フォーム通知は自社ドメインの認証済みアドレスから送り、訪問者のアドレスはReply-Toへ設定する方法を検討します。実装はフォーム製品の公式手順に従います。
DKIMはDNS登録後に管理コンソールで署名を開始する
DKIMでは、Google管理コンソールで対象ドメインの鍵を生成します。表示されたセレクターと公開鍵をDNSへ追加し、外部から取得できることを確認します。その後、管理コンソールからメール署名を開始します。
GoogleのDKIM設定手順には、鍵の生成・DNSへの追加・認証開始・確認が別の工程として示されています。DNSへTXTを追加しただけでは、Google側の署名開始が終わっていない可能性があります。反映待ちの案内が出た場合は、繰り返し別の鍵を作らず公式の待機条件を確認します。
外部アドレスへテストメールを送り、原本ヘッダーでDKIMがpassになっていることを確認します。Google Workspace以外の送信サービスは、そのサービス自身のDKIM設定が必要です。同じドメインでもセレクターを分けて複数の公開鍵を持てます。
DMARCはSPFとDKIMの確認後に段階導入する
DMARCは、表示上のFromドメインと、SPFまたはDKIMで認証されたドメインの整合を確認します。Google Workspaceだけでなく、Webフォームや外部配信サービスも正規送信として整合する必要があります。まず各経路からテストメールを送り、認証結果を記録します。
Google推奨のDMARC導入手順では、SPFとDKIMを先に設定し、監視方針でレポートを確認してから段階的に隔離や拒否へ進めます。正規送信の漏れがあるまま強制すると、自社メールが迷惑メールや拒否の対象になります。
DMARCレポートの受信先は専用にし、誰が確認するかを決めます。XMLの集計レポートを通常の受信箱で目視するだけでは継続しにくいため、信頼できる解析方法を選びます。未知の送信元が正規サービスか、なりすましかを台帳と照合します。
本番切り替えは経路ごとに送受信を確認する
本番では次の順番で進めます。
- 現在のDNS、利用者、全送信元、旧メール環境を記録する
- Google側へ利用者・エイリアス・グループを作る
- SPFとDKIMを設定し、各送信経路で認証結果を確認する
- 管理コンソールが示す現行MXへ切り替え、Gmailを有効にする
- 外部からの受信、外部への送信、グループ、フォーム通知を試す
- 新旧ログを確認し、DMARCを監視方針から段階導入する
テストはGoogle Workspace同士だけで終えません。異なる受信サービスからGoogleへ送り、Googleから複数の外部サービスへ送ります。件名へ時刻と経路を入れ、受信箱・迷惑メール・管理ログを確認します。
Webサイトが旧レンタルサーバーに残る場合は、フォーム通知の送信元とSMTP経路を特に確認します。MXをGoogleへ向けても、Webサーバーの送信方法は自動で変わりません。旧サーバーから同じドメインで送るなら、その経路を認証するか、Googleの認証済み送信へ切り替えます。
旧環境は過去メールと未着がないことを確認して終了する
DNSのキャッシュが残る間は、旧環境へ配送が試みられる可能性を考慮します。新旧両方の配送ログとメールボックスを一定期間確認します。ただし、古いMXを公式構成に混ぜたまま監視期間を延ばす方法ではなく、切り替え計画とDNSの状態を基準にします。
旧環境に残る過去メールは、必要な範囲を移行または保存します。Google Workspaceへのデータ移行が完了したか、利用者ごとに件数や代表メールを確認します。端末の旧SMTP設定と保存済みパスワードも削除します。
運用資料には、Google管理者・ドメイン確認方法・現行MXの参照先・全送信元・SPF・DKIMセレクター・DMARC方針・変更日を残します。固定値のコピーだけでなく、次回確認する管理コンソールと公式URLを記載すれば、仕様変更時に古い手順を使い続けずに済みます。
