Google Workspace DKIMの設定方法

どの設定方法を使うべきか

メールを送る当のドメイン用に、Google Workspaceの管理コンソールで生成したDKIMレコードを使います。Googleはデフォルトのセレクタをgoogleとしていますが、そのドメインでgoogle._domainkeyがすでに使われている場合は、別のセレクタが適切です。DNSプロバイダーがそのレコード長に対応していれば、2048ビットの鍵を選びます。1024ビットは、DNSプロバイダーが長い鍵に対応していない場合にだけ使います。

この設定でGoogle WorkspaceはTXTレコードを使います。例に合わせるためだけに、使用中のセレクタを置き換えないでください。既存のGoogle WorkspaceのDKIM鍵を交換する必要がある場合は、別のセレクタを使い、管理された鍵ローテーションの手順に従います。そうすれば、配送中のメールも引き続き検証できます。

下の画面は、Googleが文書化しているGoogle WorkspaceのDKIM設定の画面です。パスとラベルは、2026-08-13にGoogleの公式設定ガイドと照合しました。

Google WorkspaceでDKIMを設定する方法

Googleの送信者ガイドラインでは、Gmail宛てのすべての送信者にSPFまたはDKIMが必要です。Gmailの個人アカウント宛てに一日5,000通以上を送る一括送信者には、SPF、DKIM、DMARCのすべてが必要です。自社がこの基準に当てはまる場合は、Googleのメール送信者のガイドラインを別途確認してください。

1. 「メールの認証」を開く

管理コンソールでアプリ > Google Workspace > Gmail > メールの認証を開きます。このパスはGoogleの公式ドキュメントで確認済みです。

テストするGoogle Workspaceのメール経路で、表示上のFromアドレスに使うドメインを選択します。特にアカウントに複数のドメインやエイリアスがある場合は、何かを生成する前に、選択したドメインを確認してください。

2. DKIMレコードを生成する

「新しいレコードを生成」を選択します。セレクタと鍵長を選び、レコードを生成します。公開するDNSのホスト名とTXTレコードの値が表示されます。

値をすべて、承認済みのDNS変更にコピーします。公開鍵はあえてDNSで公開するものですが、この値はアカウント固有の設定です。生成した鍵を、使い回すDNSテンプレートに入れないでください。

3. Google WorkspaceのDNSレコードを公開する

GoogleのDKIM設定手順で、選択したドメインのホストと値が示されます。DKIMの検証側は_domainkeyの下のセレクタを参照します。DKIM公開鍵レコードの構文はRFC 6376で定義されています。

レコードの種類：TXT

ホスト（説明用の例）：

google._domainkey

値（説明用の例）：

v=DKIM1; k=rsa; p=<public-key-generated-by-google-workspace>

この例は公開しないでください。実際のホストとTXTの値全体は、設定中のアカウントとドメインについて、Google Workspaceの管理コンソールで生成します。

DNSプロバイダーによっては、ゾーン名を自動で付け足します。DNSゾーンがyourdomain.comの場合、ゾーンを付け足すホスト欄にgoogle._domainkey.yourdomain.comと入力すると、google._domainkey.yourdomain.com.yourdomain.comができてしまうことがあります。保存する前に最終的な完全修飾名を確認し、GoogleのDKIMトラブルシューティングを参考に、公開したレコードをGoogle Workspaceの表示と比べます。

4. Google Workspaceで認証を開始する

生成したTXTレコードがそのまま公開DNSで解決されるまで待ち、「メールの認証」に戻って「認証を開始」を選択します。Googleによると、管理コンソールが正しいDNSの更新を認識するまで、最大48時間かかることがあります。

DNSの応答が現れた時刻と、認証を開始した時刻を記録します。それでもGoogleがDNSの問題を報告する場合は、レコードを再編集する前に、権威DNSの応答と生成された値全体を比べます。

5. 実際のテストメールを送る

ユーザーや顧客が受け取るのと同じGoogle Workspaceの経路で、新しいメールを送ります。宛先は、メールの生のソースを確認できるメールボックスにします。

認証を開始する前に送ったメールは使いません。Googleによると、アカウントから自分自身に送ったメールは署名されない場合があるため、このテストには別の受信用メールボックスを使います。送信ゲートウェイや中継を含め、実質的に異なる経路はそれぞれテストします。

この設定がDMARCに与える影響

DKIMがDMARCに役立つのは、passしたDKIM署名のドメインが、表示上のFromドメインと一致する場合だけです。d=のドメインがFromドメインと無関係なら、署名は暗号上の検証に通ってもDMARCのアライメントに失敗します。アライメントの判定はRFC 9989で定義されています。

DMARCポリシーを変更する前に、DMARCチェックで公開中のポリシーを確認します。ポリシーを公開DNSで調べても、本番のどの送信元が一致しているかや、受信側が特定のメールを受け入れたかはわかりません。アライメントに失敗するケースは、DKIM署名がDMARCのアライメントに失敗する理由をご覧ください。

設定の検証方法

公開DNSを確認する

Googleが生成したセレクタを、送信ドメインを含めてそのまま照会します。

dig +short TXT google._domainkey.yourdomain.com

権威DNSの応答と、少なくとも1つのパブリックリゾルバーの応答を比べます。PalisadeのDKIMチェックで、公開されているレコードを確認することもできます。公開DNSでの参照でわかるのは、DNSで見えるかどうかです。Gmailがそのセレクタを使っている証明にはなりません。

Google Workspaceのステータスを確認する

「メールの認証」に戻り、選択したドメインで認証が有効になっていることを確認します。これで、Google WorkspaceアカウントがそのドメインのDNS設定を受け入れたことがわかります。

Google Workspaceのステータスが緑でも、すべての送信経路で署名されている証明にはなりません。ゲートウェイ、中継、別の送信元は、異なる設定を使っている可能性があります。

配信されたメールを確認する

新しく届いたテストメールを開き、生のヘッダーを確認します。Gmailのテスト用メールボックスなら、メッセージのソースを表示で開けます。DKIM-Signatureに想定どおりの署名ドメインとセレクタが含まれていることを確認し、受信側が付けた認証結果を探します。

Authentication-Resultsフィールドは、RFC 8601で定義されています。dkim=の結果や、署名ドメインとセレクタを示すheader.d=とheader.s=のプロパティも含まれます。

Authentication-Results: receiver.example;
  dkim=pass header.d=yourdomain.com header.s=google

DKIMの設定を完了とみなすのは、配信されたメールに想定どおりのセレクタがあり、信頼できる受信側の結果がdkim=passを示し、DKIMでDMARCを満たす場合は署名ドメインが表示上のFromドメインと一致しているときだけです。

DMARCレポートを確認する

集計レポートがたまったら、同じドメインで送信する他の送信元とは分けて、Google Workspaceのトラフィックを確認します。集計レポートにおける送信元ごとの認証とアライメントの結果は、RFC 9990で定義されています。ただし、失敗した個々のメールの調査の代わりにはなりません。

よくあるトラブル

Google WorkspaceでDKIMレコードを生成できない

ドメインでGmailが有効になっていること、アカウントに必要な管理権限があることを確認します。Googleによると、Gmailを有効にしてから鍵を生成できるようになるまで、24〜72時間かかります。

DKIMレコードが解決されない

権威DNSでレコード名全体を確認します。ゾーン名の重複、途中で切れたTXTの値、誤ったドメインでの公開がよくある原因です。チェックツールでレコードが見つからない場合は、照会した名前を生成されたホストと比べ、DKIMレコードが見つからない場合の対処法を確認してください。

Google WorkspaceがDNS更新の問題を報告し続ける

「メールの認証」に表示されるTXTの内容と、権威DNSの応答を正確に比べます。Googleによると、ステータスにDNSの更新が反映されるまで最大48時間かかります。選択したドメイン、セレクタ、公開鍵全体が一致していることを確認するまでは、2つ目の鍵を生成したり、レコードを置き換えたりしないでください。

DKIMはpassするがDMARCが失敗する

表示上のFromドメインと、受信側のAuthentication-Resultsヘッダーにあるheader.d=を比べます。別のドメインのDKIM署名がpassしても、DMARCに必要なDKIMのアライメントにはなりません。DMARCポリシーを変更する前に、一致する署名ドメインを調べます。

Google Workspaceから直接送るとpassし、ゲートウェイ経由だと失敗する

Gmailから直接送った経路とゲートウェイ経由の経路で、生のヘッダーを比べます。ゲートウェイが署名された内容を変更したり、署名を削除したり、別のドメインで署名し直したりしている可能性があります。これはメールの証拠の違いから推測したもので、Google Workspaceによる診断ではありません。必要な変更の後に最終的な署名を行うよう設定し、同じ経路で再テストします。

公開したGoogle WorkspaceのDKIMレコードを確認し、残りの送信元を把握する

DKIMチェックで、設定したドメインとセレクタについて公開DNSが返す内容を確認します。変更を完了とみなす前に、その結果を管理コンソールと、新しく配信されたメールに照らし合わせます。

DNSの参照では、Google Workspaceが本番のすべてのメールに署名していること、DKIMのドメインがDMARCに対して一致していること、受信者が今後のメールをどう扱うかは証明できません。DMARC集計レポートのデータからすべての送信元を特定し、次に確認すべきものに優先順位を付けたいIT部門やMSPは、Palisadeで始めましょう。証拠の確認と、DNSやポリシーの変更は、引き続き人が行います。