GmailのDKIM設定により、不正な送信者によるドメインのなりすましを防止し、メール配信性を向上させることができます。Google Workspace(旧G Suite)を使用している場合でも、カスタムドメインでGmailを使用している場合でも、適切なDKIMの設定により、メッセージが認証チェックを通過し、受信者の受信トレイに確実に届くようになります。
このガイドでは、Google WorkspaceドメインのDKIM設定、よくある設定ミス、正しく実装したにもかかわらずDKIMが失敗する場合について説明します。
I. DKIMができること(そして防げないこと)
DKIM(DomainKeys Identified Mail)は、送信メールに暗号署名を追加します。受信サーバーは、ドメインのDNSレコードに公開された公開鍵を使用して署名を検証します。
DKIMが検証すること:
- メッセージ本文が転送中に改変されていないこと
- 署名ドメインがメッセージを承認したこと
- DKIM署名が宣言されたドメインと一致すること
DKIMが失敗する場合:
- 転送により署名が破損する:メールがメーリングリストや自動転送を介して転送される場合、コンテンツの変更(フッターの追加など)によりDKIM署名が無効になります
- アライメントの問題:DKIMの合格がDMARCの合格を保証するわけではありません — DKIM署名の
d=ドメインはFrom:ヘッダードメインと一致する必要があります - 鍵ローテーションの問題:新しいDKIM鍵ペアを生成したがDNSの更新を忘れた場合、すべての送信メッセージがDKIM検証に失敗します
- DNS伝播の遅延:新しいDKIM公開鍵の公開には数分から数時間かかる場合があり、一時的な検証失敗を引き起こします
DKIMは認証であり、承認ではありません。有効なDKIM署名は、メッセージが署名ドメインから送信されたことを証明しますが、送信者が正当であるか、望まれているかを証明するものではありません。
II. 前提条件:Google Workspace vs Gmailパーソナルアカウント

Google Workspaceアカウント(Gmailインフラストラクチャを使用するビジネスドメイン):
- 完全なDKIM制御
- 鍵を生成し、DNSレコードを公開
- カスタムドメインのDMARC適用に必要
パーソナルGmailアカウント(@gmail.com):
- Googleが
d=gmail.comを使用してメッセージに自動的に署名 - @gmail.comアドレスのDKIMを設定することはできません
- Gmailパーソナルアカウントを介してカスタムドメインから送信する場合、そのメッセージにはドメインのDKIM署名がありません
このガイドはGoogle Workspaceドメインのみに適用されます。カスタムの「次のアドレスからメールを送信」アドレスでGmailパーソナルアカウントを使用している場合、メッセージには適切なドメイン認証がありません。
III. ステップ1:Google Workspace管理コンソールでDKIM鍵を生成する
スーパー管理者権限でGoogle Workspace管理コンソールにログインします。
- アプリ → Google Workspace → Gmail → メールの認証に移動
- ドロップダウンからドメインを選択
- 新しいレコードを生成をクリック
- DKIM鍵の長さを選択:
- 2048ビット(推奨):より強力な暗号セキュリティ、すべての主要なメールボックスプロバイダーでサポート
- 1024ビット:古い標準、DNS TXTレコードの長さが制約の場合のみ使用
- DKIMプレフィックスセレクターを入力(デフォルト:
googleの場合、セレクターはgoogle._domainkeyになります) - 生成をクリック
Googleは2つの情報を表示します:
- DNSホスト/名前:公開鍵を公開するサブドメイン(例:
google._domainkey.example.com) - TXTレコード値:
v=DKIM1; k=rsa; p=...で始まる公開鍵文字列
失敗条件:新しい鍵を生成したがDNSを更新しない場合、送信メッセージは直ちにDKIM検証に失敗します。Googleは「認証を開始」をクリックするとすぐに新しい秘密鍵で署名を開始しますが、公開鍵がまだ公開されていない場合があります。
IV. ステップ2:DNSにDKIM公開鍵を公開する
DNSプロバイダー(Cloudflare、GoDaddy、Route 53、Namecheapなど)にログインします。
次の値でTXTレコードを追加します:
| フィールド | 値 |
|---|---|
| タイプ | TXT |
| 名前/ホスト | google._domainkeyまたは完全なサブドメインgoogle._domainkey.example.com(DNSプロバイダーのUIによる) |
| 値 | Google管理コンソールから完全な公開鍵文字列を貼り付け、v=DKIM1; k=rsa; p=...を含む |
| TTL | 3600(1時間)またはデフォルト |
重要なフォーマット規則:一部のDNSプロバイダーでは、TXT値の周りの引用符を削除する必要があります。他のプロバイダーは自動的に追加します。DNSインターフェースが"v=DKIM1; k=rsa; p=..."のように引用符で囲まれた値を表示する場合、それは正常ですが、手動で余分な引用符を追加しないでください。
DNS伝播時間:プロバイダーとTTL設定によって、変更には5分から48時間かかる場合があります。GoogleはDKIM署名を有効にする前に24〜48時間待つことを推奨しています。
DKIM DNS公開が失敗する場合:
- サブドメインのタイプミス:
google._domainkeyの代わりにgoogl._domainkeyに公開すると、すべてのメッセージがDKIMに失敗します - 切り捨てられた鍵:一部のDNSインターフェースには文字数制限があります。公開鍵が切り捨てられると、DKIM検証が失敗します
- 間違ったレコードタイプ:TXTの代わりにA、CNAME、またはMXとして公開すると、鍵が読み取れなくなります
V. ステップ3:DNS公開を確認する
DKIM署名を有効にする前に、公開鍵が正しく公開されていることを確認してください。
DNSルックアップツールを使用します:
nslookup -type=TXT google._domainkey.example.comまたはオンラインチェッカー:
期待される結果:v=DKIM1; k=rsa; p=MII...で始まる完全な公開鍵文字列が表示されるはずです
ルックアップが失敗した場合:
- サブドメイン名を再確認(
google._domainkey) - 他のタイプではなくTXTレコードを公開したことを確認
- DNS伝播のためにもっと待つ
- DNSプロバイダーが長いTXTレコードに特別なフォーマットを必要とするかどうかを確認
VI. ステップ4:Google WorkspaceでDKIM署名を有効にする
Google Workspace管理コンソール → Gmail → メールの認証に戻ります。
- 作成したドメインとDKIM設定を見つける
- 認証を開始をクリック
これで何が起こるか:
- Googleは秘密鍵を使用してドメインからのすべての送信メッセージに署名を開始します
- DKIM署名の
d=値はドメインと一致します(例:d=example.com) - 受信サーバーは公開鍵を求めて
google._domainkey.example.comにクエリを送信します
失敗条件:DNSが伝播する前に「認証を開始」をクリックすると、公開鍵が利用可能になるまですべての送信メッセージがDKIM検証に失敗します。バウンスメッセージやDMARCレポートにDKIM署名検証エラーが表示されます。
安全なアプローチ:DNS TXTレコードを公開してから24〜48時間待ってからDKIM署名を有効にします。これにより、公開鍵がグローバルに伝播されます。
VII. ステップ5:DKIM署名をテストする
Google Workspaceアカウントから個人のメールアドレス(Gmail、Outlook、Yahoo、ProtonMailなど)にテストメールを送信します。
認証ヘッダーを確認:
Gmailの場合:メッセージを開き、3点メニューをクリックし、オリジナルを表示を選択します。次を探します:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.com; s=google;
h=from:to:subject:date;
bh=...;
b=...
Authentication-Results: mx.google.com;
dkim=pass [email protected] header.s=google header.b=...Outlook/Microsoft 365の場合:メッセージソースを表示するか、Authentication-Resultsヘッダーでdkim=passを確認します。
検証すべきこと:
d=example.comが送信ドメインと一致するs=googleがセレクターと一致する- Authentication-Resultsに
dkim=passがある
DKIMが失敗する場合:
- dkim=temperror:DNSルックアップがタイムアウト(伝播のためにもっと待つ)
- dkim=permerror:公開鍵が見つからないか、形式が不正
- dkim=fail:署名が一致しない(メッセージが変更されたか、DNSに間違った鍵がある)
- DKIM署名がまったくない:Google WorkspaceでDKIM署名が有効になっていないか、パーソナルGmailアカウントから送信している
VIII. よくあるDKIM Gmail設定ミス

1. DNS伝播前に署名を有効にする
問題:すべての送信メッセージが数時間または数日間DKIM検証に失敗します。
修正:公開鍵を公開してから24〜48時間待ってから「認証を開始」をクリックします。
2. カスタムドメインでパーソナルGmailアカウントを使用する
問題:Gmailパーソナルアカウントは「次のアドレスからメールを送信」を使用する場合、カスタムドメインのDKIM署名をサポートしません。
修正:Google Workspaceに移行するか、DKIMをサポートするサードパーティのSMTPサービス(SendGrid、Mailgun、Postmark)を使用します。
3. 複数の送信者に1つのDKIM鍵のみを公開する
問題:組織が企業メールにGoogle Workspaceを使用していても、マーケティングプラットフォーム(Mailchimp、HubSpot)からも送信している場合、これらのサードパーティ送信者には異なるセレクターを持つ独自のDKIM鍵が必要です。
修正:各送信者に個別のDKIM TXTレコードを追加します:
google._domainkey.example.com(Google Workspace)k1._domainkey.example.com(Mailchimp)hubspot._domainkey.example.com(HubSpot)
4. 鍵ローテーション後のDNS更新を忘れる
問題:Google Workspaceで新しいDKIM鍵ペアを生成した場合(セキュリティ上の理由または鍵の侵害後)、新しい公開鍵が公開されるまでメッセージがDKIMに失敗します。
修正:Google管理コンソールで新しい鍵を生成する前に、常に新しい公開鍵をDNSに公開します。
5. DKIMパス=DMARCパスと仮定する
問題:DKIM署名は検証に合格してもアライメントが欠落している場合はDMARCに失敗する可能性があります。
DMARCアライメント要件:DKIM署名のd=ドメインはFrom:ヘッダードメインと一致する必要があります(またはアライメントモードによってそのサブドメインである必要があります)。
失敗シナリオの例:
[email protected]から送信されたメッセージ- DKIM署名に
d=mailprovider.comがある - DKIMは合格するが、
mailprovider.com≠example.comのためDMARCは失敗
修正:サードパーティの送信者がd=値にドメインを使用するように設定するか、フォールバックとしてSPFアライメントを実装します。
IX. DKIM、SPF、DMARC:連携の仕組み

DKIM単独で配信性は向上しますが、なりすましに対するポリシーを強制するものではありません。DMARCがすべてを結びつけます。
DMARC要件:
- 少なくとも1つの認証メカニズム(SPFまたはDKIM)が合格する必要があります
- 少なくとも1つの合格メカニズムが
From:ヘッダードメインとアライメントする必要があります
例:アライメントされたDKIMパス = DMARCパス
From: [email protected]- DKIM署名:
d=example.com(アライメント済み) - DKIM結果:
pass - DMARC結果:
pass
例:アライメントされていないDKIMパス = DMARC失敗
From: [email protected]- DKIM署名:
d=thirdpartymail.com(アライメントされていない) - DKIM結果:
pass - DMARC結果:
fail(SPFも失敗した場合)
DKIMが合格してもDMARCが失敗する場合:
- SPFは合格するがエンベロープ送信者が
From:ヘッダーとアライメントしない - DKIMは合格するが署名ドメインが
From:ヘッダーとアライメントしない - コンテンツを変更するシステムを介してメッセージが転送される(DKIMが破損)
Skysnag Protectを使用してすべての送信者のDMARCアライメントを監視し、認証は成功するがDMARCが失敗する場所を特定します:
X. DKIMが合格しても配信性が低い場合
DKIM検証の合格は受信トレイへの配置を保証するものではありません。メールボックスプロバイダーは複数のシグナルを評価します:
認証 + レピュテーション + コンテンツ
- 認証:DKIM、SPF、DMARC
- レピュテーション:IP/ドメインの履歴、苦情率、エンゲージメント指標
- コンテンツ:件名、本文、リンク、添付ファイル
失敗シナリオ:
- DKIMは合格するが、ドメインレピュテーションが悪い:有効な署名があるにもかかわらずメッセージがスパムに入る
- DKIMは合格、SPFは合格、しかしDMARCは失敗:一部の受信者はDMARC失敗に対してより積極的にフィルタリング
- DKIMは合格するが、コンテンツがスパムフィルターをトリガー:「今すぐ行動」などのフレーズ、過度のリンク、または疑わしい添付ファイルが認証を上書き
メールボックスプロバイダーが保証しないこと:
- Gmail、Microsoft、Yahoo、Appleは正確なフィルタリングルールを公開していません
- DKIMの合格は「ホワイトリスト」ステータスを作成しません
- 認証は役立ちますが、唯一の要因ではありません
DKIM設定後に配信性を向上させるには:
- DMARC適用を実装(
p=quarantineまたはp=reject) - 苦情率と配信停止リクエストを監視
- クリーンなメールリストを維持(無効なアドレスを削除)
- スパムのような件名と過度のプロモーション言語を避ける
XI. DKIM鍵のローテーションとセキュリティのベストプラクティス
DKIM鍵をローテーションするタイミング:
- 12か月ごと(暗号鍵の一般的なベストプラクティス)
- 鍵の侵害が疑われた直後
- 新しい管理者のオンボーディング時(鍵の露出を制限)
認証を破ることなくDKIM鍵をローテーションする方法:
- Google Workspace管理コンソールで異なるセレクターで新しい鍵ペアを生成(例:
google2._domainkey) - 古い鍵と一緒に新しい公開鍵をDNSに公開
- DNS伝播のために48時間待つ
- Google管理コンソールで新しい鍵への署名に切り替える
- 新しい鍵が機能することを確認した後、古いDNSレコードを削除
鍵ローテーションの失敗モード:新しい鍵への署名に切り替える前に古い公開鍵を削除すると、移行期間中にメッセージがDKIM検証に失敗します。
より良いアプローチ:移行中は両方の鍵をアクティブに保ち、すべてのメッセージが新しい署名を使用していることを確認してから古い鍵を廃止します。
XII. サブドメインのDKIM設定
サブドメインからメールを送信する場合(例:marketing.example.com、support.example.com)、各サブドメインには独自のDKIM設定が必要です。
Google Workspaceのアプローチ:
- Google Workspaceアカウントにサブドメインを追加(まだ追加していない場合)
- Google管理コンソールでサブドメインのDKIM鍵を生成
google._domainkey.marketing.example.comにTXTレコードを公開- サブドメインのDKIM署名を有効にする
失敗条件:親ドメイン(example.com)のDKIMのみを設定した場合、サブドメインが明示的に設定されていない限り、marketing.example.comから送信されたメッセージには有効なDKIM署名がありません。
サブドメインとのDMARCアライメント:
- 厳密なアライメント:DKIM
d=はFrom:ドメインと完全に一致する必要があります - 緩やかなアライメント(デフォルト):DKIM
d=は親ドメインでもよい(例:d=example.comはFrom: [email protected]とアライメント)
緩やかなアライメントは通常十分です。DMARCレポートでサブドメインのなりすましを防ぐ必要がある場合にのみ、厳密なアライメントを使用してください。
XIII. DKIMとDMARCコンプライアンスの監視
DKIM設定後、DMARC集計レポートを通じて認証結果を監視します。
DMARCレポートが示すもの:
- どの送信者がDKIMでメッセージに署名しているか
- どのDKIM署名が合格または失敗しているか
- 合格したDKIM署名が
From:ドメインとアライメントしているかどうか - SPFも合格(およびアライメント)しているかどうか
DMARCレポートでのDKIM失敗の解釈:
dkim=fail:署名が一致しない(メッセージが変更された、間違った鍵、または鍵ローテーションの問題)dkim=temperror:DNSルックアップが失敗(一時的な問題)dkim=permerror:公開鍵が見つからないか、形式が不正dkim=none:DKIM署名がない
監視が重要な理由:
- ドメインをなりすまそうとする不正な送信者を検出
- 設定ミスのあるサードパーティサービス(ESP、CRM、サポートツール)を特定
- 転送の問題を強調表示(DKIM署名を破壊するメーリングリスト)
- メール認証監視が組織の広範なセキュリティコントロールセットの一部であるコンプライアンスプログラムの証拠を提供
- Google Workspace、サードパーティの送信者、サブドメインが時間の経過とともに適切に認証されたままであることを確認するのに役立つ
Skysnag Protectの詳細:
XIV. DKIM Gmail設定チェックリスト
このチェックリストを使用して、Google Workspace DKIM設定が完全で期待どおりに機能していることを確認してください。
- カスタムの「次のアドレスからメールを送信」アドレスを持つパーソナルGmailアカウントではなく、Google Workspaceを使用していることを確認する。
- スーパー管理者権限でGoogle Workspace管理コンソールにログインする。
- Gmail認証設定に移動し、ドメインのDKIMレコードを生成する。
- サポートされている場合は2048ビットDKIM鍵を使用する。
- Googleが提供するセレクターと公開鍵を正確にコピーする。
- DKIM公開鍵をDNS TXTレコードとして公開する。
- DKIM署名を有効にする前にTXTレコードが正しく解決されることを確認する。
- DNSレコードが表示された後にのみGoogle WorkspaceでDKIM認証を開始する。
- Gmail、Outlook、その他のメールボックスプロバイダーにテストメールを送信する。
- メッセージヘッダーを確認し、dkim=passを確認する。
- DKIM d=ドメインが表示されるFromドメインとアライメントしていることを確認する。
- CRM、マーケティングツール、サポートプラットフォームなどのサードパーティ送信者に対して個別にDKIMを設定する。
- DMARC集計レポートを監視して、すべての送信者でDKIMアライメントを確認する。
- DKIMパスがDMARCパスを意味すると仮定しない。
- DKIM セレクターと鍵ローテーション手順を定期的に確認する。
XV. 重要なポイント
DKIMは、受信メールサーバーがドメインによって署名されたメッセージが承認され、転送中に変更されていないことを確認するのに役立ちます。
Gmailベースのビジネスメールの場合、DKIM設定はGoogle Workspaceを通じて処理する必要があります。パーソナルGmailアカウントは、カスタムドメインに対して同じドメインレベルのDKIM制御を提供しません。
DKIM単独ではドメインのなりすましを防ぐことはできません。SPFおよびDMARCと組み合わせると、特にDMARCアライメントが監視され、適用が適用される場合に、より強力になります。
最も一般的なGmail DKIM設定の失敗は、DNSフォーマットエラー、間違ったセレクター名、切り捨てられたTXTレコード、DNS伝播前の署名の有効化、およびサードパーティの送信者がGoogle Workspace DKIMでカバーされていると仮定することです。
DKIMパスは受信トレイへの配置を保証するものではありません。メールボックスプロバイダーは、レピュテーション、苦情率、コンテンツ、エンゲージメント、転送コンテキスト、および内部の不正使用シグナルを評価します。
DMARC監視は、DKIM署名がすべての正当な送信者で合格およびアライメントしているかどうかを確認する最良の方法です。
SkynagでDMARC監視を開始し、無料のDMARCレコードを取得: