お名前.comでGoogle WorkspaceのMXを設定する手順|SPF・DKIM・DMARCまで

この記事の手順どおりに設定すると、お名前.comで取得した自社ドメインのメールを、Google Workspace(Gmail)で送受信できるようになります。作業時間の目安は30〜60分で、これに加えてDNSの反映待ち(数分〜最大72時間)が発生します。MXレコードだけでなくSPF・DKIM・DMARCまで一気に設定するのは、送ったメールが取引先側で迷惑メールと判定されたり、自社ドメインがなりすましメールに悪用されたりするのを防ぐためです。

作業の全体像

設定は次の5つを順番に進めます。使う画面は、お名前.com Naviの「DNSレコード設定」と、Google Workspaceの管理コンソールの2つだけで、特別なソフトは必要ありません。

1. MXレコードの設定: 自社ドメイン宛てのメールをGoogleのサーバで受け取るための、いわば「郵便物の届け先変更」です。
2. SPFレコードの設定: 「このドメインのメールはGoogleのサーバから送る」と宣言し、送信元のなりすましを防ぎます。
3. DKIMの設定: 送信メールに電子署名を付け、途中で改ざんされていないことを受信側が検証できるようにします。
4. DMARCの設定: SPF・DKIMの認証に失敗したメールの扱い方を受信側に指示し、認証結果のレポートを受け取れるようにします。
5. 設定の検証: テストメールを送り、配送と認証がすべて通っていることを確認します。

2〜4番目のSPF・DKIM・DMARCは「送信ドメイン認証」と呼ばれる仕組みで、未設定のままだと、正当なメールでも受信側の迷惑メール判定で不利になることがあります。なりすまし対策としての詳しい仕組みや意義は「中小企業のメールセキュリティ対策」で解説しているので、ここでは「MXと3つの認証は必ずセットで設定する」ことだけ押さえておけば十分です。

事前準備

作業を始める前に、次の3点を確認してください。

• お名前.comのログイン情報: 対象ドメインのDNSレコードを編集できるアカウントで、お名前.com Naviにログインできることを確認します。IDやパスワードが分からない場合は、先に再発行手続きを済ませておきます。
• Google Workspaceの申込と管理コンソール: 管理者アカウントで管理コンソールにログインできる状態にしておきます。まだ申込前の場合は、導入判断からデータ移行までの導入5ステップをまとめた「Google Workspace導入ガイド」を先に確認し、申込(14日間の無料試用から開始できます)を済ませてください。
• 切替タイミングの計画(現在メールを使用中の場合): MXレコードを書き換えると、以降の新着メールはGoogle側に届き始めます。切替中は旧メールサーバを解約せずに残し、過去メールの移行が終わるまで併存させてください。作業自体も、メールの少ない時間帯(週末や終業後)に行うのが安全です。

手順1: MXレコードの設定

MXレコードは、自社ドメイン宛てのメールをどのサーバで受け取るかを決めるDNSレコードです。ここを書き換えた時点で、メールの配送先がGoogleに切り替わります。

1. お名前.com Naviにログインし、「ネームサーバーの設定」→「DNSレコード設定」を開いて、対象のドメインを選択します。
2. 次の内容でMXレコードを1件追加します。

3. 旧メールサーバのMXレコードが登録されている場合は、切替のタイミングで削除します。新旧のMXが混在すると配送が不安定になります。
4. 画面の案内に従って設定内容を確認し、確定します。

現在のGoogle Workspaceは、smtp.google.com(優先度1)を1件だけ登録する「単一レコード方式」が標準です。インターネット上の古い解説には、aspmx.l.google.comなど複数のMXレコードを登録する方式が載っていますが、これは以前の方式で、現行の案内とは異なります。正しい値は管理コンソールのセットアップ画面に表示されるものなので、本記事と表示が異なる場合は必ず管理コンソールの案内に従ってください。

手順2: SPFレコードの設定

SPFは、「このドメインのメールを送信してよいサーバ」をDNSで宣言する仕組みです。同じ「DNSレコード設定」画面で、次のTXTレコードを追加します。

ここでの最大の注意点は、SPFレコードは1つのドメインに1件だけというルールです。すでに「v=spf1」で始まるTXTレコードが登録されている場合は、新しいレコードを追加するのではなく、既存のレコードに統合してください。SPFレコードが2件あると受信側の認証はエラーになり、かえって迷惑メール判定されやすくなります。

たとえばお名前.comのメール転送サービスなどを併用していて、すでにSPFレコードがある場合は、その既存の記述にinclude:_spf.google.comを追記して1件にまとめる形になります。統合の書き方は併用しているサービス側の案内もあわせて確認し、判断に迷う場合は、転送の利用をやめてGoogle側に一本化することも含めて検討してください。

手順3: DKIMの設定

DKIMは、送信メールに電子署名を付けて改ざんを検知できるようにする仕組みです。ほかの手順と違い、先に管理コンソールで鍵を生成してから、お名前.com側にレコードを登録する2段階の作業になります。

1. 管理コンソールのGmail設定からメール認証(DKIM)の画面を開き、鍵の長さに2048ビットを選んで新しいレコードを生成します。画面の場所が分からない場合は、管理コンソール内の検索機能や案内に従ってください。
2. 生成すると、ホスト名(google._domainkey)と、TXTレコードに登録する値が表示されます。この画面は閉じずに残しておくと、後の作業が楽になります。
3. お名前.comの「DNSレコード設定」で、ホスト名にgoogle._domainkey、TYPEにTXTを指定し、表示された値をそのまま登録します。値が長いですが、途中に改行や空白を加えずに貼り付けてください。
4. DNSへの反映を待ってから、管理コンソールに戻って「認証を開始」します。

鍵の生成直後に認証を開始すると、レコードがまだDNSに反映されておらず失敗することがあります。失敗しても設定が壊れるわけではないので、数時間ほど置いてから再実行してください。

手順4: DMARCの設定

DMARCは、SPF・DKIMの認証に失敗したメールを受信側がどう扱うべきかを宣言し、認証結果のレポートを受け取るための仕組みです。「DNSレコード設定」で次のTXTレコードを追加します。

「rua=mailto:」の後ろは、レポート受信用の専用アドレス(例: dmarc-reports@自社ドメイン のグループアドレス)にするのがおすすめです。レポートは件数が多くなりがちで、個人の受信箱宛では埋もれて運用が続かなくなるためです。なお、自社ドメイン以外のアドレスで受け取る場合は、受け取り側での追加の承認設定が必要になります。

ポイントは、最初は必ずp=none(監視のみ)で始めることです。p=noneは「認証に失敗しても配送には手を付けず、結果をレポートで知らせてほしい」という設定で、届いたレポートを見ながら、複合機や業務システムなどGoogle以外から自社ドメイン名義で送っているメールが漏れていないかを確認します。正当なメールがすべて認証を通ることを確かめたうえで、隔離(quarantine)、拒否(reject)へと段階的に強化するのが安全な進め方です。いきなりp=rejectにすると、設定漏れのある正当なメールが相手に届かなくなるおそれがあります。

手順5: 設定の検証

すべてのレコードを登録したら、DNSの反映(数分〜最大72時間)を待って動作を確認します。確認は「レコードの反映」「メールの送受信」「認証結果」の3段階で行います。

1. MXレコードの反映確認: ターミナル(コマンドプロンプト)で次のコマンドを実行し、smtp.google.comが返ってくれば反映済みです。「自社ドメイン」は実際のドメイン名に置き換えてください。Windowsでdigが使えない場合は、nslookupコマンドでも同様の確認ができます。

dig MX 自社ドメイン +short

2. 送受信テスト: 外部のアドレス(個人のGmailなど)と自社ドメインのアドレスの間で双方向にテストメールを送り、どちらも届くことを確認します。
3. 認証結果の確認: 受信した側のGmailでテストメールを開き、メニューから「メッセージのソースを表示」を選びます。画面上部に表示される認証結果(Authentication-Results)で、SPF・DKIM・DMARCの3つがすべて「pass」になっていれば設定完了です。

いずれかがpassにならない場合は、まず該当レコードの値の写し間違いと、DNS反映待ちの不足を疑ってください。この2つで大半は解決します。

よくある失敗と回避策

• 旧MXと新MXが混在して配送が不安定になる: 旧サーバのMXを残したままsmtp.google.comを追加すると、メールが新旧どちらに届くか安定しません。MXレコードはsmtp.google.comの1件だけにし、旧サーバは「MXからは外すが、移行完了までは契約を残す」形にしてください。
• SPFレコードが2件あって認証に失敗する: 既存のレコードを確認せずに新規追加すると起きる典型例です。追加前に既存のTXTレコードを一覧で確認し、v=spf1で始まるレコードがすでにあれば1件に統合します。
• DKIMの登録直後に「認証を開始」して失敗する: DNSに反映される前に開始すると失敗します。登録から時間を置いて再実行すれば通るので、あわてて鍵を作り直す必要はありません。
• DMARCをいきなりp=rejectにして正当なメールが不達になる: 複合機の通知メールなど、認証設定が漏れている送信元が残っていると、そのメールが相手に届かなくなります。p=noneで始め、レポートで送信元の実態を把握してから段階的に強化してください。

よくある質問

設定はどれくらいで反映されますか?

TXTレコード(SPF・DKIM・DMARC)は数分〜48時間、MXレコードはGoogleの案内で最大72時間が目安です。反映までの時間は、各レコードに設定されたTTL(DNSキャッシュの有効期間)に左右されます。反映が完了するまでは新旧の設定が混在して見えることがあるため、切替はメールの少ない時間帯に行い、72時間は様子を見る前提で計画してください。

設定を間違えるとどうなりますか?

MXレコードの間違いは「メールが受け取れない」という直接の業務影響につながります。SPF・DKIM・DMARCの間違いは、送ったメールが迷惑メール判定される・不達になるという形で現れます。いずれも正しい値に修正すれば反映後に復旧するので、作業前に変更前のレコード内容を控えておき、問題が起きたらすぐ戻せるようにしておくと安心です。

お名前.com以外のDNSサービスでも手順は同じですか?

登録するレコードの中身(MX・SPF・DKIM・DMARCの各値)は、どのDNSサービスでも共通です。異なるのは管理画面の名称や入力形式だけなので、本記事の設定値を各サービスの画面に読み替えて登録してください。なお、ドメインのネームサーバーを外部のDNSサービスに向けている場合は、お名前.comではなくそのサービス側で設定する点にだけ注意が必要です。

まとめ

お名前.comでのGoogle Workspaceメール設定は、「ネームサーバーの設定」→「DNSレコード設定」でMXレコード(smtp.google.com・優先度1の1件)を切り替え、SPF・DKIM・DMARCの3つの認証を同じ画面で仕上げ、最後にテストメールのAuthentication-ResultsでSPF・DKIM・DMARCのpassを確認する——ここまでやって完了です。作業自体は30〜60分ですが、DNS反映(MXは最大72時間)とDKIMの待ち時間があるため、3日ほどの余裕を持って計画してください。設定後は、DMARCレポートを確認しながら段階的にポリシーを強化していけば、なりすましに強いメール環境を維持できます。

本記事の検証ログ: 設定値・手順は2026年7月4日にGoogle公式ヘルプおよびお名前.comの設定画面仕様に基づき確認。監修: 髙田誠史(Google Professional Cloud Architect)。