はじめに
長年使ってきたメールクライアントを Gmail に移行しました。主な理由は Claude をはじめとする AI 連携のしやすさですが、Route 53 で取得したドメインもあったので Google Workspace を活用しようと思いました。
この記事では、Google Workspace の契約から Route 53 での DNS レコード設定、送受信テストで認証が通るまでの手順をまとめます。
記事中のドメイン名は example.com に置き換えています（スクリーンショットの該当箇所はモザイク処理）。実際に設定する際は、ご自身のドメインに読み替えてください。
この記事で話さないこと
- TXT・MX など DNS レコードタイプ自体の詳しい解説（設定に必要な範囲だけ触れます）
- 各サービスに登録済みのメールアドレスを新しいアドレスへ移行する手順
前提
作業前のドメインの状態は次のとおりです。
- ドメインは Route 53 で取得済み、パブリックホストゾーンあり
- メール関連のレコード（MX / SPF / DKIM / DMARC）は未設定
作業日は 2026 年 7 月 17 日です。料金や画面は当時のものなので、ご注意ください。
STEP 1: Google Workspace を契約する
Google Workspace の申込ページ から Business Starter プランで申し込みます。従業員数は「自分だけ」、地域は日本を選びました。
料金は月額 950 円と表示されていましたが、年間プランかつ、申し込み画面で最初の 3 か月間 50% オフが適用され、475 円からのスタートになりました。
次に、アカウント設定方法の選択では「既存のドメインを使用して設定する」を選びます。
あとは Route 53 で取得したドメイン名を入力して、支払い情報を登録すれば契約は完了です。
STEP 2: ドメインの所有権を証明する
契約が終わるとセットアップウィザードが始まります。ドメインホストの選択画面が出るので、Amazon Web Services を選びます。
すると、DNS に登録すべき確認コード（TXT レコード）が表示されます。
この値を Route 53 のホストゾーンに登録します。「レコードを作成」から、次のように入力します。レコード名は空欄にするのがポイントです。
| レコード名 | タイプ | 値 | TTL |
|---|---|---|---|
| （空欄） | TXT | google-site-verification=... |
60 |
登録したら Google の画面に戻って「確認」を押します。さほど時間はかからず確認が完了しました。
STEP 3: メールを受信できるようにする
続いて「Gmail を有効にする」に進むと、MX レコードのアクティベーションコードが表示されます。
MX（Mail eXchanger）レコードは「このドメイン宛のメールをどのサーバーが受け取るか」を宣言するものです。
| レコード名 | タイプ | 値 | TTL |
|---|---|---|---|
| （空欄） | MX | 1 SMTP.GOOGLE.COM |
60 |
STEP 4: 送信認証を設定する
MX を設定すれば受信はできますが、自分が送ったメールが相手に迷惑メール扱いされないためには、送信元の正当性を証明する 3 つのレコードが必要です。Google のメール送信者のガイドラインによると、すべての送信者は SPF または DKIM の設定が必須で、Gmail 宛に一日 5,000 件以上のメールを送信する場合は SPF、DKIM、DMARC の設定が必須です。
SPF は送信元のサーバーがそのドメインのメールを送ってよいサーバーかどうかの確認、DKIM は電子署名によるメールの改ざんやドメインのなりすましの検証、DMARC は受信側で DKIM や SPF の認証に失敗した時の扱いを定義するものです。それぞれ DNS レコードとして追加することで設定可能です。
DKIM の鍵を生成する
管理コンソールの DKIM 設定で鍵を生成します。ビット長は 2048 を選びました。
生成すると、レコード名 google._domainkey と、v=DKIM1; k=rsa; p= から始まる長い公開鍵の値が表示されます。これをそのまま Route 53 に貼り付けたところ、エラーになりました。
CharacterStringTooLong (Value is too long) encountered with
'"v=DKIM1;k=rsa;p=XXXXXXXXXXXXXXXXXXXXXXX..."'
DNS の文字列は 1 つあたり 255 文字までです。これは Route 53 の制限ではなく、DNS の仕様（RFC 1035）で決まっている TXT レコードの character-string の上限です。2048 ビットの DKIM 公開鍵はこの上限を超えるので、そのまま貼るとどの DNS サービスでも同じように弾かれます。
回避方法は、値を 255 文字以内に分割し、それぞれをダブルクォート（引用符）で囲んで、スペース区切りで同じ行に並べることです。
"v=DKIM1; k=rsa; p=（前半の255文字以内）" "（残りの文字列）"
分割して貼り直すと、エラーは出なくなります。
これは Route 53 がサポートする DNS レコードタイプ にも記載されたやり方です。DNS の受信側が複数の文字列を自動で連結して 1 つの値として扱ってくれるので、意味は変わりません。
255 文字を超える値を入力する必要がある場合、値を 255 文字以下の文字列に分割し、各文字列を二重引用符 (") で囲みます。コンソールで、同じ行にすべての文字列を一覧表示します。
登録後、管理コンソールで「DKIM が有効になりました」と表示されれば成功です。所有権、Gmail、DKIM の 3 つに緑のチェックが並びました。
SPF を追加する
SPF はルートドメインの TXT レコードとして登録します。値は Google の公式ドキュメントで案内されているものをそのまま使います。
v=spf1 include:_spf.google.com ~all
ここで、STEP 2 で作った所有権確認の TXT レコードと衝突します。新規作成しようとすると「指定された名前のレコードは既に存在します」と怒られるので、既存の TXT レコードを編集して、値を 1 行追加するかたちにします。1 つの TXT レコードセットの中に、所有権確認の値と SPF の値が並んで共存する状態です。
末尾の ~all（ソフトフェイル）は、SPF に合致しないメールを「疑わしいが拒否まではしない」扱いにする指定で、Google が推奨している値です。
~all タグは、SPF レコードに記載されていないサーバーからのメールを受信サーバーで迷惑メールとしてマークするように指示します。SPF レコードには ~all を使用することをおすすめします。
DMARC で方針を宣言する
最後に _dmarc という名前の TXT レコードを新規作成します。
| レコード名 | タイプ | 値 |
|---|---|---|
_dmarc |
TXT | v=DMARC1; p=none |
p=none は監視モードで、認証に失敗したメールがあっても受信側に何もさせません。DMARC は p=none（監視）から始めて、運用に問題がないことを確認してから p=quarantine（迷惑メールフォルダ行き）、p=reject（受信拒否）へ段階的に強化するのが定石です。いきなり p=reject にすると、設定漏れがあったときに自分の正規のメールまで届かなくなります。
DMARC の使用を開始するときは、ポリシー オプション（p）を none に設定することをおすすめします。ドメインからのメールが受信サーバーによってどのように認証されるのかがわかってきた段階で、ポリシーを更新します。ある程度の期間を設けて、受信側のポリシーを quarantine（または reject）に変更します。DMARC のおすすめのロールアウト方法をご覧ください。
STEP 5: 送受信テストで確認する
設定が終わったら、実際にメールを流して確かめます。
受信テストは、外部のアドレスから新しいアドレス宛に送るだけです。無事に Gmail の受信トレイに届きました。ただし送信元の都合で迷惑メールフォルダに振り分けられていたので、受信経路が動いていることの確認にとどめました。
大事なのは送信側です。新しいアドレスから旧メールアドレス（Outlook）にメールを送り、受信したメールのヘッダー（Authentication-Results）を開くと、認証の結果が客観的に見られます。
spf=pass smtp.mailfrom=example.com
dkim=pass header.d=example.com
dmarc=pass header.from=example.com
compauth=pass reason=100
3 つとも pass でした。さらに X-MS-Exchange-Organization-SCL: 1（迷惑メールではないという判定）も確認できたので、送信ドメインとしては問題ないということになります。なお、compauth や X-MS-Exchange-Organization-SCL は Outlook（Microsoft）側で付与されるヘッダーなので、Gmail など他のサービス宛に送った場合は表示される項目が変わります。
最終的に設定したレコード
メールのために追加したのは、次の 5 レコード（TXT は 1 レコードに 2 値）です。
| レコード名 | タイプ | 値 | 用途 |
|---|---|---|---|
| （ルート） | TXT | google-site-verification=... |
所有権確認 |
| （ルート） | TXT | v=spf1 include:_spf.google.com ~all |
SPF |
| （ルート） | MX | 1 SMTP.GOOGLE.COM |
受信経路 |
google._domainkey |
TXT |
v=DKIM1; k=rsa; p=...（255 文字で分割） |
DKIM |
_dmarc |
TXT | v=DMARC1; p=none |
DMARC |
余談
今回、作業を進める上でまずは Claude に作業計画を立案してもらいました。元々使っていたメールアドレスに届いていたメールの棚卸しなどをほぼすべて実施してくれました。現在は旧メールアドレスとの並行運用期間中です。ちなみに、既存サービスのメールアドレス変更が一番時間がかかりました。パスワードを忘れていたり、そもそもログインが必要な点を踏まえすべて Claude に委任するわけにもいかなかったので...今後はパスワード管理ツールもうまく活用したいですね。
参考