Skip to content
無料の100クレジットで検証を始める
Qualisend
SPF設定ガイド

Google Workspaceの​SPF・DKIM・DMARC設定。

Google Workspaceの認証とは、自社ドメインとして送信するGmailのサーバーが本当に自社の正規の送信元であると証明することです。必要なのは3つのDNSレコードと、Admin console内の1つのスイッチです。3つのレコードは、Googleの共有includeを追加するSPFのTXTレコード、Admin consoleで生成してTXTレコードとして公開するDKIM鍵（その後「Start authentication」でオンにします）、DMARCポリシーレコードです。Google Workspaceは送信者であると同時に受信側でもある数少ないサービスです。3つすべてのアライメントを一致させることで、「via」の表示が出たり迷惑メールに振り分けられたりせず、Gmailの受信トレイに届くようになります。

SPFのinclude
Your DNSAdd the CNAME / TXT records
Google WorkspaceSigns & sends as your domain
The inboxSPF · DKIM · DMARC pass

Google Workspaceを認証すべき理由

Google WorkspaceのメールはすでにGoogle自身のインフラを経由していますが、認証するまでは自社ドメインとの結び付きが弱い状態です。Gmailに「via」の表示が出ることがあり、DMARCにも成功できず、Fromアドレスが自社のものであることを暗号的に証明できません。2024年2月以降、Google自身の送信者ガイドラインは、すべての送信者にSPFまたはDKIMの成功を求めています。さらに、すべての大量送信者（Gmail宛てに1日あたり約5,000通以上）には、アライメントが一致した状態で、少なくともp=noneのDMARCポリシーを公開することも求めています。Yahooも同じ月に同じルールを導入し、Microsoftも2025年に適用を始めました。ここではGoogleが自らのガイドラインに照らしてメールを評価するため、未認証のWorkspaceドメインは、迷惑メールフォルダーへの振り分けや拒否に最も直結します。SPF、DKIM、DMARCを正しく設定すれば、両方のメカニズムのアライメントが自社ドメインと一致し、「via」の表示が消え、DMARCに成功し、自社の名前で送信レピュテーションを築けます。

Google WorkspaceにおけるSPFの実情

Google Workspaceは本来の意味で「include」を使うサービスです。ルートドメインにある1つのSPFのTXTレコードに、共有メカニズムinclude:_spf.google.comを1つ追加します。レコード全体はv=spf1 include:_spf.google.com ~allです。CNAMEで委任するサービスとは異なり、これは本当に共有のincludeです（Workspaceの全顧客が同じものを使います）。Googleから送るメールのエンベロープ送信者は自社ドメインになるため、このincludeは、ほとんどの送信者の場合よりも重要な意味を持ちます。SPFのアライメントが組織ドメインと実際に一致し、DKIMだけでなくSPFもDMARCの成功に寄与するからです。重要な変更点が1つあります。include:_spf.google.comは現在、メカニズムがip4:/ip6:のみの1つのフラットなSPFレコードで、かつてのinclude:_netblocks.google.com / _netblocks2 / _netblocks3の連鎖はなくなりました。そのため、RFC 7208の10回制限に対して消費するDNSルックアップは1回だけです。古いガイドや一部のキャッシュを参照するSPFチェックツールが今も示す3～4回ではありません。Workspaceのユーザーは他のツールからも正当に送信することが多いため、Googleは-allではなく~all（softfail）で終えることを推奨しています。-allに引き上げるのは、すべての送信元を記載できたと確信してからにしてください。また、ドメイン上のSPFのTXTレコードは必ず1つだけにします。SendGrid、Mailchimp、Microsoft 365なども使っている場合は、2つ目のSPFレコードを公開せず、すべてのメカニズムをその1つのv=spf1の行にまとめてください（SPFレコードが2つあるとPermErrorになります）。

設定手順

Admin consoleで
  1. 1

    Authenticate emailを開く

    admin.google.comにsuper adminとしてサインインし、Menu (☰) → Apps → Google Workspace → Gmail → Authenticate emailに進みます。ここはDKIMのページです。SPFレコードとDMARCレコードはここではなく、DNSホストで直接追加します。

  2. 2

    正しいドメインを選択

    複数のドメインを管理している場合は、Authenticate emailページ上部のドロップダウンから送信ドメインを選びます。プライマリドメイン、セカンダリドメイン、ドメインエイリアスはそれぞれ個別に認証します。

  3. 3

    DKIM鍵を生成

    Generate new recordをクリックします。鍵の長さは2048ビットに設定し、セレクタープレフィックスはデフォルトのgoogleのままにします。2048ビットはGoogleの推奨で、1024ビットにするのは、DNSホストが長いTXTの値を保存できない場合のみにしてください。Generateをクリックします。

  4. 4

    DKIMレコードをコピー

    GoogleがTXTレコードを表示します。ホスト/名前はgoogle._domainkey、値はv=DKIM1; k=rsa; p=…で始まり、長い公開鍵が続きます。両方をコピーします。後でStart authenticationをクリックするため、このタブは開いたままにしてください。

DNSホストで
  1. 5

    DKIMのTXTレコードを公開

    DNSホストで、ホストをgoogle._domainkey、値をGoogleから提示されたものとするTXTレコードを追加します。2048ビットの鍵は、TXTの1文字列あたり255文字の上限より長いため、1つのレコード内で引用符付きの複数のかたまりのままにする必要があるホストもあります。ほとんどの管理画面は自動で処理します。そうでない場合は、分割された値を表示どおりに貼り付けてください。

  2. 6

    SPFレコードを追加（既存なら1つにまとめる）

    ルートドメイン（ホストは@または空欄）に、v=spf1 include:_spf.google.com ~allというTXTレコードを追加します。SPFレコードがすでにある場合は2つ目を作成せず、include:_spf.google.comを既存のv=spf1の行に他の送信元と並べてまとめます。

  3. 7

    DMARCレコードを公開

    ホスト_dmarcに、v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comというTXTレコードを追加します。p=none（監視のみ）から始めれば、アライメントを確認する間も何も影響を受けません。ポリシーの引き上げは後で行います。

Admin consoleで
  1. 8

    Start authenticationをクリック

    Authenticate emailページに戻り、DKIMのTXTレコードが反映されるのを待ってから、Start authenticationをクリックします。ここが見落とされやすい手順です。鍵を生成しただけでは何も起こらず、認証を開始すると、ステータスが「Authenticating email for this domain.」に変わります。

確認
  1. 9

    テストを送信してヘッダーを確認

    Workspaceのアドレスからメールを送り、別のGmailアカウントで開いて⋮ → Show originalを使います。SPF: PASS、DKIM: PASS（「signed-by: yourdomain.com」、セレクターgoogle）、DMARC: PASSであること、そしてすべてgoogle.comではなく自社ドメインとアライメントが一致していることを確認します。

  2. 10

    他のドメインとエイリアスでも手順を繰り返す

    送信に使うセカンダリドメインとドメインエイリアスごとに、DKIMとStart authenticationの手順を繰り返す必要があります。これらの各ドメインにはSPFレコードとDMARCレコードも必要で、ないとメールが認証されません。

追加するレコード

正確な値はGoogle Workspaceのセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。

タイプホスト値
TXT@v=spf1 include:_spf.google.com ~allルートドメインのSPF：SPFレコードは1つだけにし、他の送信元はこの行にまとめます。include:_spf.google.comが消費するDNSルックアップは現在1回です。
TXTgoogle._domainkeyv=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…(2048-bit public key from the Admin console)例です。実際の鍵はApps → Google Workspace → Gmail → Authenticate emailでドメインごとに生成されます。2048ビットの鍵は、引用符付きの文字列に分割して公開する必要がある場合があります。
TXT_dmarcv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comDMARCレコードはドメインごとに1つです。p=noneで始め、quarantine/rejectへと引き上げます。

ルートドメインのSPF（v=spf1）のTXTレコードは1つだけにし、すべての送信元をこの1行にまとめてください。SPFレコードが2つあると、それ自体がエラーになります。

DNSルックアップの10回制限

SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。Google Workspaceの設定がこの上限のうち何回を消費するかは、次のとおりです。

SPF 10-lookup budget1 used · 9 free

Google Workspaceは10回のルックアップのうち1回を消費します。ip4:とip6:のメカニズムはルックアップを消費しません。

DKIM

Google WorkspaceのDKIMは、固定値をコピーするのではなくAdmin console内で生成します。Apps → Google Workspace → Gmail → Authenticate emailを開き、ドメインを選択してGenerate new recordをクリックし、2048ビットとデフォルトのセレクタープレフィックスgoogleを選びます。するとGoogleがTXTレコードを表示します。ホストはgoogle._domainkey.yourdomain.com、値はv=DKIM1; k=rsa; p=<your public key>です。このTXTレコードをDNSホストで公開します。対応する秘密鍵はGoogleが保持し、送信メールに署名します。WorkspaceのDKIMには、他の多くのサービスと異なる点が2つあります。1つ目は、レコードの公開だけでは足りないことです。Authenticate emailページに戻ってStart authenticationをクリックしない限り、Googleはその鍵での署名を始めません（正しく公開したレコードでもDKIMに成功しない最も多い原因です）。2つ目は、2048ビットの公開鍵は1つのTXT文字列の上限である255文字を超えるため、多くのDNSホストでは1つのレコード内に引用符付きの複数のかたまりとして保存されることです。Admin consoleには整形済みの値が表示され、ほとんどの管理画面（GoDaddy、Cloudflare、Namecheapなど）は正しく連結します。後でGmailが鍵を無効と報告した場合は、連結の崩れが通常の原因です。セレクターはgoogleのままで問題ありません。変更が必要なのは、そのドメインの別のサービスがすでにそのセレクターを使っている場合だけです。従来の1024ビット鍵からは、可能なタイミングで切り替えてください。また、DKIMはアカウント全体で一度ではなく、ドメインごと、エイリアスごとに有効にする点にも注意してください。

DMARC

DMARCは自分で公開する別のポリシーレコードで、Googleが作成してくれるものではありません。_dmarc.yourdomain.comに、v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comというTXTレコードを追加します。p=noneは監視のみで、配信には一切影響しません。ただし受信側に集計レポートをメールで送るよう伝えるため、Google WorkspaceのメールがSPFとDKIMに成功し、アライメントが自社ドメインと一致しているかを確認できます。Workspaceでは両方のメカニズムのアライメントが一致する（SPFは自社のエンベロープドメイン、DKIMは自社ドメインのgoogleセレクター）ため、すぐに問題なく成功する様子を確認できるはずです。1～2週間、ruaレポートを確認し、Workspaceと外部ツールを含む正当な送信元がすべて認証されていることを確かめてから、ポリシーをp=quarantine、最終的にp=rejectへと引き上げます。使う送信元の数にかかわらず、_dmarcレコードはドメイン全体で1つだけにし、Google専用に2つ目のDMARCレコードを追加しないでください。なお、Googleの大量送信者向けルールが義務付けるのは最低限のp=noneだけですが、なりすましから実際にドメインを守るのはp=rejectです。

正しく設定できたか確認する

Admin consoleのステータスだけに頼らないでください。表示が遅れることがあり、DNSが反映済みでも「up to 48 hours」のままの場合があります。実際のメールで確認します。Workspaceのアドレスから別のメールボックスに送り、Gmailで開いて⋮ → Show originalを選びます。SPF: PASS、DKIM: PASS、DMARC: PASSと表示され、DKIMのsigned-byとSPFのドメインがどちらもgoogle.comではなくyourdomain.com（セレクターgoogle）になっていれば成功です。Googleは独自の診断ツール、Admin ToolboxのCheckMX（toolbox.googleapps.com/apps/checkmx）も公開しており、SPF、DKIM、DMARC、MXの各レコードの欠落や形式の誤りを指摘してくれます。レコードそのものは、dig TXT google._domainkey.yourdomain.comとdig TXT _dmarc.yourdomain.comでも確認できます。最後に、Qualisendのドメイン診断でドメインをチェックし、すべてのレコードが解決され、SPFレコードが10回の上限内に収まっていることを確認します。集計レポートが届き始めたら、DMARCレポート解析にレポートをドロップします。Googleが、アライメントの一致した、すべて成功している送信元として表示されるはずです。

ドメイン診断 DMARCレポート解析

よくある注意点

  • 認証失敗の原因

    DKIM鍵を生成しても、Authenticate emailページでStart authenticationをクリックするまでは何も起こりません。google._domainkeyレコードを公開済みで署名が未開始の状態が、DKIMのチェックに失敗し続ける最も多い原因です。

  • 認証失敗の原因

    2048ビットのDKIM鍵は1つのTXT文字列の上限である255文字より長いため、引用符付きの複数のかたまりとして保存されます。公開後にGmailが鍵を無効と報告した場合は、原因はほぼ確実に、連結の崩れ（または管理画面が分割を保持しなかったこと）です。

  • 認証失敗の原因

    DNSが正しくても、Admin consoleに「not authenticating」や「up to 48 hours」と表示され続けることがあります。ステータスの再チェックには遅れがあるためです。コンソールのバナーよりも、Show original / Admin Toolboxを信頼してください。

  • 適用範囲

    セカンダリドメインとドメインエイリアスごとにDKIMの個別の設定が必要で、これらの各ドメインには独自のSPFレコードとDMARCレコードも必要です。プライマリドメインを認証しても、他のドメインはカバーされません。

  • 認証失敗の原因

    ルートドメインのSPFのTXTレコードは1つだけにしてください。SendGrid、Mailchimp、Microsoft 365なども使っている場合は、include:_spf.google.comを1つのv=spf1の行にまとめます。SPFレコードが2つあるとPermErrorになります。

  • DNS設定

    include:_spf.google.comは現在1つのフラットなレコード（ルックアップ1回）ですが、古いガイドや一部のキャッシュを参照するSPFチェックツールは今も3～4回と数えます。古い数字を見て余裕を取りすぎたり、慌ててフラット化したりしないでください。

  • 適用範囲

    -allではなく~allを使ってください。Workspaceのユーザーは他のサービスからも正当に送信することが多いため、Googleはsoftfailを推奨しています。早すぎる-allは、記載し忘れた送信元のメールをhard failさせるおそれがあります。

  • 適用範囲

    外部リレー、Gmailの「Send mail as」の外部SMTP、またはマーケティングプラットフォームを経由するメールには、GoogleによるDKIM署名は付きません。これらの経路には独自の認証が必要で、WorkspaceのDKIMをオンにしただけではアライメントは一致しません。

SPFレコードを作成

以下ではGoogle Workspaceがあらかじめ選択されています。他に利用している送信プラットフォームを追加し、1つにまとめたレコードを公開してください。

1

送信元

メールの送信に使っているサービスを検索して、それぞれチェックを入れてください。

選択済み
ガイド →
2

このドメイン自身のサーバー

ドメインが（上記のサービスを経由せず）直接メールを送信する場合は、ドメイン自体を許可します。

3

その他の送信元・IP

リストにないもの（別のサービスのSPFホストや特定のIPアドレス）を追加します。

接頭辞のinclude:は自動で付加されます。サービスのドキュメントに記載されているホスト名を入力してください。

4

その他すべての送信元へのポリシー

上記に記載されていないサーバーからのメールを、受信側がどう処理すべきかを指定します（allメカニズム）。

生成されたSPFレコードDNSルックアップ1/10回
v=spf1 include:_spf.google.com ~all
  • ルートドメインにTXTレコードとして公開します。ホストは@（ドメインそのもの）、値は上記の文字列全体です。
  • SPFレコードは1つのドメインにつき1つだけにします。すべての送信元をこの1行にまとめてください。v=spf1で始まるTXTレコードが2つあると、両方とも無効になります。
  • DNSルックアップは10回以内に収めてください。include:、a、mxはそれぞれ1回とカウントされ、includeは内部でさらにルックアップを発生させることがあります。ip4:とip6:はカウントされません。

送信ドメイン認証の設定が済んだら、次は検証済みのクリーンなリストへの配信です。

リストを検証

Google WorkspaceのSPFに関するよくある質問

Googleのガイドラインでは、すべての送信者に形式上はSPFまたはDKIMを求めていますが、大量送信者（Gmail宛てに1日5,000通以上）にはDMARCも必要で、これはアライメントが一致したメカニズムが少なくとも1つないと成功しません。実際には、SPF、DKIM、DMARCの3つすべてを設定すべきです。WorkspaceではSPFとDKIMの両方のアライメントが自社ドメインと一致するため、両方を設定すれば、DMARCに成功する経路が2つになります。

ほとんどの場合、Authenticate emailページでStart authenticationをクリックしていないか、TXTレコードの反映前にクリックしたことが原因です。google._domainkey.yourdomain.comが解決されること（dig TXT google._domainkey.yourdomain.com）を確認してから、Start authenticationをクリックしてください。鍵は解決されるのに無効と報告される場合は、2048ビットの鍵が途中で切れていないか、分割された文字列がDNS管理画面で崩れていないかを確認します。

2048ビットです。Googleの推奨であり、強度も大幅に高くなります。1024ビットを選ぶのは、DNSホストがどうしても長い値を保存できない場合のみにしてください。何年も前の古い1024ビット鍵がある場合は、新しい2048ビット鍵を生成し、Start authenticationをやり直します。

現在は1回です。include:_spf.google.comは今、メカニズムがip4:/ip6:のみの1つのフラットなSPFレコードに解決されるため、10回のDNSルックアップのうち1回しか消費しません。以前は3つの_netblocksのincludeを入れ子にしており（合計約4回）、そのため多くの古い記事や一部のSPFチェックツールが今も3～4回と記載しています。

できますが、その必要はほとんどありません。同じドメインの別のサービスがそのセレクターをすでに使っていない限り、デフォルトのgoogleのままにしてください。セレクターはDKIM鍵に名前を付けるだけのものです。DMARCで重要なのは、署名のアライメントが自社ドメインと一致することです。

いいえ。DKIMはセレクターgoogleを使うため他のサービスのセレクターと衝突せず、DMARCは1つの共有レコードです。注意が必要なのはSPFだけで、SPFレコードは1つにします。include:_spf.google.comを他の送信元のメカニズムとまとめ、10回の上限に注意してください。

MX（Googleの現在の設定ではsmtp.google.comのレコード1つを使います）はメールの受信に関するもので、送信の認証とは関係ありません。SPF、DKIM、DMARCは、MXとは独立して機能します。ただし、受信の有無にかかわらず、実際に送信に使うすべてのドメインにSPF、DKIM、DMARCが必要です。

関連記事

GoogleとYahooの送信者ガイドラインWorkspaceのメールの評価基準となる2024年2月のルールです。大量送信者に求められるSPF、DKIM、DMARC、アライメントを扱います。SPF・DKIM・DMARCの解説3つのレコードの関係と「アライメント」の実際の意味を、わかりやすく解説します。DMARCの設定手順このガイドのp=noneのレコードから、安全なp=rejectポリシーまで進めます。SPFレコード作成ツールinclude:_spf.google.comを他の送信元とまとめ、10回の上限内に収まる有効なSPFレコードを1つ作成します。ドメイン診断公開後に、WorkspaceのSPF、DKIM、DMARCのレコードがすべて解決され、成功することを確認します。DMARCレポート解析集計レポートをドロップして、Googleがアライメントの一致した成功している送信元として表示されるか確認します。

ワークスペース・メールボックスの他のサービス

すべてのSPFガイド
Google WorkspaceのSPF、DKIM、DMARCを毎日監視レコードの設定は、最初の一歩にすぎません。ドメイン診断の監視は、SPFのルックアップ数、DKIMキー、DMARCポリシーを毎日再チェックし、どれかが壊れたときにメールでお知らせします。ドメイン診断の監視を見るSPFのDNSルックアップが多すぎる場合：数え方とpermerrorの直し方

公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。

認証の次は、リストをクリーンに保つ

SPF、DKIM、DMARCに成功すれば受信トレイに届き、クリーンなリストならその状態を維持できます。お手持ちのリストも検証してクリーニングできます。100クレジット無料、クレジットカード登録不要で始められます。

検証を始める