独自ドメインの設定やDNSレコードの変更を前にして、「設定を間違えてホームページが表示されなくなったらどうしよう」「メールが届かなくなって取引先に迷惑をかけたらどうしよう」と不安に思っている担当者の方も多いのではないでしょうか。
会社の看板である独自ドメインをGoogle Workspaceに紐付け、Gmailで自社アドレスの送受信を始めるプロセスは、専門的な技術用語が多く、ハードルが高く感じられるかもしれません。
しかし、設定の目的と、それぞれの変更がどこに影響するのかを理解し、事前に準備しておけば、専任のIT担当者がいない中小企業でも、影響を確認しながらリスクを抑えて作業を進めやすくなります。
この記事では、Google Workspaceの独自ドメイン設定について、作業全体の流れからDNSレコードの具体的な変更方法、SPF・DKIM・DMARCなどのメール認証、設定後の動作確認までを分かりやすく解説します。
- Google Workspaceで独自ドメインを利用するための基本的な流れ
- ドメイン所有権確認とMXレコード変更の違い
- DNS変更前に確認・記録しておくべき項目
- Google Workspace向けMXレコードの設定方法
- SPF・DKIM・DMARCの役割と設定時の注意点
- Webフォームや外部サービスも含めたメール送信元の確認方法
- 設定後に実施したいメールの送受信テスト
独自ドメイン設定が導入全体のどこに当たるかは、「Google Workspaceの導入手順」で先に確認できます。
結論からいうと、Google Workspaceの独自ドメイン設定では、いきなりDNSを書き換えるのではなく、「変更前の状態を記録する → ドメイン所有権を確認する → メールの受信先を準備する → MXレコードを変更する → メール認証を整える → 動作確認する」という流れで進めることが重要です。
特に、ドメイン所有権確認用のTXTレコードと、実際のメール配送先を変更するMXレコードは役割が異なります。
何のための設定なのかを理解しながら、一つずつ進めていきましょう。
独自ドメインをGoogle Workspaceで使うための全体手順と基本概念
設定を始める前に、まずは「なぜドメインとGoogle Workspaceをつなぐ設定が必要なのか」という仕組みと、これから行う作業の全体像を整理します。
独自ドメインメールが届く仕組み
独自ドメインメールが送受信される裏側では、主に「ドメイン」「DNS」「メールサーバー」の3つが連携しています。
ドメイン
インターネット上で自社を識別するための住所や看板にあたるものです。
例えば、会社のWebサイトやメールアドレスで使用する example.co.jp のような文字列がドメインです。
DNS（Domain Name System）
ドメイン名と、実際の接続先となるサーバーなどの情報を結びつける仕組みです。
イメージとしては、インターネット上の「案内板」や「電話帳」のような役割があります。
メールサーバー
メールの送受信処理を行うシステムです。
Google Workspaceへ移行する場合は、現在利用しているメール環境から、Google WorkspaceのGmailを利用する環境へ切り替えていきます。
メールが送信されると、送信側のメールサーバーはDNSを確認し、
このドメイン宛てのメールを、どのメールサーバーへ届ければよいのか
を判断します。
Google Workspaceで独自ドメインメールを利用するには、このDNS上の情報を適切に設定する必要があります。
「ドメイン所有権の証明」と「メール配送先の変更」の違い
Google Workspaceで独自ドメインを利用する際の基本的な流れは、次の6つに整理できます。
- DNS情報の事前記録
- ドメイン所有権の確認
- 受信先となるアカウントや共同窓口の準備
- MXレコードによるメール配送先の切り替え
- SPF・DKIM・DMARCなどのメール認証設定
- 動作確認・テスト送受信
ここで特に重要なのが、「ドメイン所有権の証明」と「メール配送先の変更」の違いです。
ドメイン所有権の証明
自社がそのドメインを管理していることをGoogleへ証明するプロセスです。
一般的には、Googleから指定された確認用TXTレコードをDNSへ追加します。
メール配送先の変更（MXレコード設定）
そのドメイン宛てのメールを、どのメールサーバーへ配送するのかを変更する設定です。
Google Workspaceへ切り替える場合は、Googleが指定するMXレコードを設定します。
Google指定の確認用TXTレコードを正しく追加するだけであれば、既存のWebサイトやメールには影響しません。
一方、MXレコードを変更すると実際のメール配送先が変わります。
この2つは別の作業として理解しておきましょう。
また、SPF・DKIM・DMARCなどのメール認証についても、すべてを一度に設定する必要はありません。
自社のメール送信環境を確認しながらSPFを整え、Gmailを有効化した後にDKIMを設定し、SPF・DKIMの認証状況を確認したうえでDMARCを段階的に導入していきます。
フェーズ1：DNS設定を変更できる環境を確認する
実際のDNS変更に取りかかる前に、自社のDNSを誰が管理しているのかを確認し、現在の設定状態を記録しておきます。
利用中のドメイン管理サービスとDNSの操作権限を確認する
まずは、自社の独自ドメインをどこで契約し、DNSをどこで管理しているのか確認します。
例えば、
- お名前.com
- ムームードメイン
- レンタルサーバー会社
- DNS専用サービス
などで管理されている場合があります。
ドメインを購入したサービスと、実際にDNSを管理しているサービスが異なる場合もあります。
そのため、単に「ドメインをどこで取得したか」だけでなく、現在DNSレコードを編集できる管理画面がどこにあるのかを確認してください。
Webサイトの制作や保守を外部の制作会社へ委託している場合は、DNSの管理も外部事業者が行っている可能性があります。
その場合は、自社で無理に変更せず、
- 誰へ依頼するのか
- どの情報を渡すのか
- いつ変更するのか
を事前に整理しておきましょう。
変更前のDNSレコード情報を記録する
DNSを変更する前に、現在登録されているDNSレコードを記録しておきます。
DNSにはメール関連の設定だけでなく、
- Webサイト
- サブドメイン
- 外部サービス
- メール
- ドメイン認証
などに利用される複数のレコードが登録されています。
関係のないAレコードやCNAMEレコードなどを誤って削除すると、Webサイトや他のサービスへ影響する可能性があります。
変更前に、可能な範囲で次の情報を記録してください。
- レコードの種類（A、CNAME、MX、TXTなど）
- ホスト名・名前
- 設定値
- TTL
- MXレコードの場合は優先度
管理サービスにエクスポート機能がある場合は利用し、ない場合は設定画面のスクリーンショットなどでも構いません。
変更前の状態を記録しておくことで、問題が発生した場合に、以前の設定を確認するための重要な判断材料になります。
ただし、DNSはキャッシュされる仕組みがあるため、設定を以前の値へ戻した場合でも、すべての利用環境へ即座に反映されるとは限りません。
その点も考慮して変更作業を計画しましょう。
フェーズ2：Googleにドメインの管理権を証明する
準備ができたら、Google Workspaceでドメイン所有権の確認を行います。
確認用TXTレコードとは？
Google Workspaceでは、自社がそのドメインを管理していることを確認するため、DNSへ確認用のTXTレコードを追加します。
TXTレコードは、DNSに文字列を登録するためのレコードです。
Google Workspaceのセットアップ画面では、次のような形式の確認用トークンが発行されます。
google-site-verification=...
実際の値は自社の環境ごとに異なるため、必ずGoogle Workspaceの管理画面に表示された値を使用してください。
Google指定の確認用TXTレコードを正しく追加するだけであれば、既存のWebサイトやメールには影響しません。
Googleの確認用TXTレコードをDNSへ追加する
基本的な流れは次のとおりです。
1. Google Workspaceの管理コンソールへログインする
管理者アカウントでGoogle Workspaceの管理コンソールへログインし、ドメイン確認のセットアップ画面を開きます。
2. Googleが提示する確認用TXTレコードをコピーする
画面に表示される、自社専用の確認用トークンをコピーします。
3. DNS管理画面へTXTレコードを追加する
利用しているDNSサービスの管理画面を開き、新しいTXTレコードを追加します。
一般的には、次の項目を設定します。
- ホスト名：
@または空欄など - レコードタイプ：TXT
- 値：Googleから発行された確認用トークン
- TTL：DNS事業者のデフォルト値
ホスト名の入力方法はDNSサービスによって異なります。
@ を入力するサービスもあれば、空欄にするサービス、ドメイン名を入力するサービスもあります。
必ず利用しているDNSサービス側の入力ルールも確認してください。
4. Google側で所有権確認を実行する
TXTレコードを保存したら、Google Workspace側へ戻って所有権確認を実行します。
Googleによる確認は通常比較的短時間で完了しますが、DNSの反映状況や利用しているDNSサービスによって、確認できるようになるまで時間がかかる場合があります。
すぐに確認できない場合は、入力内容を確認したうえで、時間を置いて再度確認してみましょう。
フェーズ3：メール配送先を変更する前に受信先を準備する
ドメイン所有権の確認が完了しても、すぐにMXレコードを変更するのは避けましょう。
その前に、Google Workspace側でメールを受け取るための環境を準備します。
切り替え対象となるメールアドレスを確認する
現在利用しているメールアドレスを洗い出し、Google Workspace側でどのように受信するのかを整理します。
例えば、
- 社員ごとのメールアドレス
info@sales@support@- メーリングリスト
- システム通知用アドレス
などです。
受信方法については、用途に応じて、
- Google Workspaceユーザー
- Googleグループ
- メールエイリアス
などを使い分けます。
メール切り替え前に必要な利用者アカウントは、「Google Workspaceのアカウント作成手順」に沿って準備します。
受信先が存在しない場合はメールが配信されない可能性がある
MXレコードをGoogle Workspace向けに変更した後は、自社ドメイン宛てのメールがGoogle側へ配送されるようになります。
その際、Google Workspace側に対応する受信先が存在しない場合、メールが配信されず、送信元へ宛先不明などのエラーが返る可能性があります。
そのためMXレコードを変更する前に、
- 利用する社員のユーザーアカウント
info@などの共同窓口- 必要なエイリアス
- その他、現在利用しているメールアドレス
について、Google Workspace側に受信先が準備されているか確認してください。
フェーズ4：MXレコードを変更してメール配送先をGoogleへ切り替える
受信先の準備が完了したら、メール配送先をGoogle Workspaceへ変更します。
Google Workspace用のMXレコードを設定する
MX（Mail Exchange）レコードは、そのドメイン宛てのメールをどのメールサーバーへ配送するのか指定するDNSレコードです。
標準的にGoogle Workspaceへメール環境を完全移行する場合は、Google公式の手順に従って既存のメールサーバー向けMXレコードを整理し、Googleが指定するMXレコードを設定します。
2026年8月26日時点で、Googleが案内している新規設定用の主な値は次のとおりです。
| 項目 | 設定内容 |
|---|---|
| ホスト名 | @ または空欄など |
| レコードタイプ | MX |
| 優先度 | 1 |
| 値 | smtp.google.com |
| TTL | DNS事業者のデフォルト値 |
DNSサービスによっては、MXの値へ末尾の.を付ける必要がある場合があります。
また、ホスト名の入力方法もサービスによって異なります。
実際の設定作業を行う直前に、必ずGoogle公式の最新MXレコード情報と、利用しているDNSサービスの入力方法を確認してください。
なお、Google Workspaceと旧メールサービスを併用する特殊な配送構成を利用する場合は、単純に既存MXレコードを削除する構成とは異なる場合があります。
一般的な完全移行ではなく、複数のメール環境を併用する場合は、現在のメール構成を確認したうえで設定してください。
MX切り替えの前後で行う確認や過去メールの扱いは、「Google Workspaceへのメール移行手順」で詳しく解説しています。
Google Workspace側でGmailの有効化を完了する
MXレコードを設定したら、Google Workspace管理コンソールのセットアップ案内に従って、Gmailの有効化を完了します。
管理画面の名称や表示位置は変更される場合があるため、実際の画面に表示される案内に従ってください。
MXレコードが認識されるまで最大72時間かかる場合がある
Googleでは、新しいMXレコードが認識されるまで最大72時間かかる場合があると案内しています。
DNSのキャッシュ状況などによっては、一時的に、
- 一部のメールが旧メール環境へ届く
- 一部のメールが新しいGmailへ届く
といった状態が発生する場合があります。
新しいMXレコードが認識され、送受信テストで切り替えを確認できるまでは、旧メール環境についても確認できる状態を維持しておくと安心です。
フェーズ5：SPF・DKIM・DMARCでメール認証を設定する
独自ドメインからメールを送信する場合は、メール認証についても確認します。
代表的な仕組みが、
- SPF
- DKIM
- DMARC
です。
Googleのメール送信者要件は送信量などによって異なりますが、これらを適切に設定することは、なりすまし対策やメールの信頼性を高めるうえで重要です。
SPF｜自社ドメインから送信するすべてのサービスを確認する
SPF（Sender Policy Framework）は、
このドメインからメールを送信してよいサーバーやサービスはどれか
をDNS上で指定する仕組みです。
Google Workspaceだけからメールを送信する会社であれば比較的シンプルですが、実際の企業環境では、
- Webサイトの問い合わせフォーム
- メールマガジン配信サービス
- CRM
- 勤怠管理サービス
- 会計システム
- 複合機
- その他のクラウドサービス
などが、自社ドメインを送信元としてメールを送っている場合があります。
そのため、SPFを変更する前に、自社ドメインを使ってメールを送信しているサービスをすべて洗い出すことが重要です。
SPFレコードは複数作らず1つに統合する
同じドメインに対して、SPFレコードを複数作成しないよう注意してください。
例えば、
Google Workspace用のSPF
Webフォーム用のSPF
メール配信サービス用のSPF
を別々のTXTレコードとして登録するのではなく、各サービスが公式に案内している送信元情報を確認し、1つのSPFレコードへまとめます。
外部サービスを追加する場合は、そのサービスの公式マニュアルに記載されたSPF設定値を確認してください。
また、SPFにはDNS lookupが最大10回までという技術的な制限があります。
多数の外部サービスを指定する場合は、この上限を超えていないかにも注意が必要です。
DKIM｜送信元ドメインとメールの完全性を検証する
DKIM（DomainKeys Identified Mail）は、送信メールへ電子署名を付け、受信側が送信元ドメインやメールの完全性を確認できるようにする仕組みです。
Google Workspaceでは、管理コンソールからDKIMキーを取得し、指定された公開鍵情報をTXTレコードとしてDNSへ登録します。
その後、Google Workspace側でDKIM認証を開始します。
ただし、タイミングには注意が必要です。
Google Workspaceでは、組織でGmailを有効にした後、管理コンソールでDKIMキーを取得できるようになるまで24〜72時間待つ必要がある場合があります。
また、DKIMキーをDNSへ追加した後も、DKIM認証が機能し始めるまで最大48時間かかる場合があります。
そのため、設定直後に結果だけを見て失敗と判断せず、Google公式の案内とDNSの反映状況を確認しながら進めましょう。
DMARC｜認証状況を確認しながら段階的に導入する
DMARCは、SPFやDKIMによる認証結果と、メールのFromアドレスに使用されているドメインとの整合性を確認し、認証に合格しないメールを受信側でどのように扱うかの方針を示す仕組みです。
DMARCを設定する前に、SPFとDKIMを整え、自社の正規メールが適切に認証されていることを確認しておきましょう。
Googleでは、SPFまたはDKIMを設定した後、DMARCを設定するまで48時間待つよう案内しています。
DMARCは、最初から強い拒否設定を使用するのではなく、段階的に導入します。
ステップ1：p=none で認証状況を確認する
まずは監視用の p=none から始めます。
p=none は、DMARCポリシーとして隔離や拒否を要求せず、認証状況を確認するために利用できます。
ただし、p=none を設定していても、受信側の迷惑メール判定など、DMARC以外の理由によってメールが迷惑メールへ分類されたり拒否されたりする可能性はあります。
ステップ2：DMARCレポートを確認する
DMARCでは、受信側メールサーバーから集計レポートを受け取ることができます。
このレポートを確認することで、
- 正規の送信サービスが認証できているか
- 想定していない送信元が存在しないか
- SPFやDKIMの設定漏れがないか
などを確認できます。
DMARCレポートは通常の業務メールと分けて管理できるよう、専用のメールボックスやGoogleグループなどを利用する方法も検討しましょう。
ステップ3：必要に応じてポリシーを強化する
正規の送信元が適切に認証されていることを確認したら、必要に応じて、
p=none
から、
p=quarantine
さらに、
p=reject
へ段階的に強化します。
十分に確認せず強いポリシーへ変更すると、正規メールまで影響を受ける可能性があります。
DMARCレポートや実際の送信状況を確認しながら進めましょう。
Gmailのメール送信者要件も確認する
Googleでは、個人向けGmailアカウント宛てにメールを送信する送信者へ、メール認証などの要件を設けています。
現在は、
- 個人向けGmailアカウントへ送るすべての送信者：SPFまたはDKIM
- 個人向けGmailアカウント宛てに1日5,000通を超えるメールを送信する送信者：SPF・DKIM・DMARC
などが要件となっています。
Googleは、送信量にかかわらずSPF・DKIM・DMARCの3つを設定することを推奨しています。
送信者要件は変更される可能性があるため、公開時や設定作業時にはGoogleの最新ガイドラインを確認してください。
メール認証の設定後は、「Google Workspaceの初期セキュリティ設定」も確認し、アカウント側の安全対策を整えましょう。
フェーズ6：設定後にメールの送受信をテストする
DNSやメール認証の設定ができたら、実際にメールが正常に送受信できるか確認します。
外部メールアドレスとの送受信を確認する
まずは基本的な送受信テストを行います。
受信テスト
Google Workspaceとは別のメール環境から、自社のGoogle Workspaceアドレスへメールを送信します。
Gmailへ正常に届くか確認してください。
送信テスト
Google WorkspaceのGmailから外部メールアドレスへ送信します。
確認する項目は、
- メールが正常に届いているか
- 迷惑メールへ分類されていないか
- 返信が正常にできるか
- SPFやDKIMの認証結果
などです。
必要に応じてメールヘッダーの Authentication-Results を確認し、SPFやDKIMが pass になっているか確認します。
Webサイトの問い合わせフォームも確認する
Google WorkspaceのGmailだけが正常に動いていても、他のシステムからのメールが止まっている可能性があります。
Webサイトにお問い合わせフォームがある場合は、実際にテスト送信してください。
確認する内容は、
- 社内への問い合わせ通知が届くか
- 問い合わせをした人への自動返信が届くか
- 迷惑メールへ分類されていないか
- SPF・DKIM・DMARCの認証で問題が発生していないか
などです。
複合機や業務システムも確認する
自社ドメインを利用してメールを送信しているシステムがある場合は、それぞれ動作確認します。
例えば、
- 複合機からのスキャンメール
- 勤怠管理システム
- 会計システム
- CRM
- メールマガジン配信サービス
- その他のクラウドサービス
などです。
Google Workspaceへの切り替えを機に、これまで見落としていたメール送信元が見つかるケースもあります。
SPFなどの設定漏れがないかも含めて確認しましょう。
問題が発生した場合は通信経路を分けて確認する
メールが正常に動かない場合は、一度にすべてを変更するのではなく、どこで問題が起きているのかを整理します。
例えば、
外部からの受信だけできない
MXレコード、Google Workspace側の受信先、Gmail有効化などを確認します。
Google Workspaceからは送信できるが、Webフォームだけ送信できない
Webフォーム側のメール設定やSPFなどを確認します。
特定の送信サービスだけ認証に失敗する
そのサービスのSPF・DKIM設定や、DMARCとの整合性などを確認します。
特定のアドレスだけ受信できない
Google Workspace側にユーザー、グループ、エイリアスなどの受信先が存在するか確認します。
このように問題を経路ごとに分けることで、原因を整理しやすくなります。
変更前に切り戻し手順と担当者を決めておく
DNS設定を変更する前に、
- どのような問題が発生したら切り戻しを検討するのか
- 変更前の値は何だったのか
- 誰が設定を戻すのか
- 戻した後に何を確認するのか
を整理しておきましょう。
ただし、DNSはキャッシュされるため、設定を元へ戻しても即座に全環境へ反映されるとは限りません。
そのため、「元へ戻せばすぐ復旧する」と考えず、変更後の監視や確認まで含めて計画しておくことが重要です。
作業日時についても特定の曜日や時間帯に固定せず、変更後に担当者が送受信を監視でき、問題が発生した場合に復旧対応を行える時間帯を選びましょう。
【筆者経験】設定変更前の「状態記録」と「トラブルへの備え」
筆者がシステム開発や運用プロセスの改善に関わってきた経験でも、設定変更前の状態を記録し、検証項目と切り戻し手順を事前に整理してから作業することを重視してきました。
また、問題が発生した場合も、
- DNS
- Google Workspace側
- Webフォームなどの送信元
- 外部サービス
といった通信経路を分けて確認することで、原因を整理しやすくなります。
Google Workspaceの独自ドメイン設定でも、変更前の状態・確認項目・復旧手順を事前に整理しておくことは、設定変更時の重要なリスク低減策になります。
まとめ｜設定の目的と影響範囲を理解し、リスクを抑えて進めましょう
Google Workspaceの独自ドメイン設定は、単純にDNSへ値をコピーするだけの作業ではありません。
それぞれの設定が何を変更するものなのかを理解し、自社の現在の環境を確認しながら進めることが重要です。
今回のポイントをまとめます。
- 準備
DNSを誰が管理しているか確認し、変更前の設定状態を記録する - ドメイン所有権確認
自社がドメインを管理していることを、Google指定の確認用TXTレコードで証明する - 受信先準備
MXレコードを変更する前に、ユーザー・Googleグループ・エイリアスなど必要な受信先を準備する - MXレコード変更
Google公式の最新設定値を確認してメール配送先をGoogle Workspaceへ切り替える - SPF
自社ドメインから送信するすべてのサービスを整理し、1つのSPFレコードへ統合する - DKIM
Gmail有効化後、Google WorkspaceからDKIMキーを取得してDNSへ登録する - DMARC
SPF・DKIMの認証状況を確認し、p=noneから段階的に導入する - 動作確認
Gmailだけでなく、Webフォーム、複合機、業務システムなども確認する
設定値や管理画面は変更される可能性があります。
特にMXレコードやメール送信者要件などは、設定作業を行う直前にGoogle公式情報を再確認するようにしてください。
次のステップ：まずは現在のDNSレコード情報を記録する
独自ドメイン設定を始める前に、まず確認したいのは現在のDNS設定です。
利用しているDNS管理サービスへアクセスし、
- 現在登録されているレコード
- レコードの種類
- ホスト名
- 値
- TTL
- 優先度
などを記録しておきましょう。
変更前の状態を記録しておくことで、問題が発生した場合に元の設定を確認するための重要な判断材料になります。
そのうえで、Google Workspaceの管理画面から確認用TXTレコードを取得し、ドメイン所有権の確認へ進みましょう。
