Google WorkspaceのSPF・DKIM・DMARC設定方法|メールが届かないを防ぐ確認手順

Google WorkspaceのSPF・DKIM・DMARCを設定する順序を解説。送信元の棚卸し、DNS変更、メールヘッダーの確認、届かないときの切り分けまで整理します。

広告・PR本記事にはアフィリエイト広告が含まれます。

送信メールがSPF・DKIM・DMARCの認証を通って受信箱へ届くイメージ

Google Workspaceで独自ドメインのメールを運用していても、SPF・DKIM・DMARCが未設定または不完全だと、送信メールが迷惑メールに分類されたり、受信側で拒否されたりする可能性があります。EC運営では、問い合わせへの返信、受注・出荷通知、請求案内、メール配信など送信元が増えやすいため、Google Workspaceだけを設定すれば終わりとは限りません。

この記事では、送信元の棚卸しからSPF、DKIM、DMARCの設定、テストメールのヘッダー確認までを安全な順序で整理します。実際に登録する値は利用中のサービスによって異なるため、自社の管理コンソールと各送信サービスの公式案内を優先してください。

OFFICIAL INFORMATION

Google Workspaceを会社のメール運用に活用する

独自ドメインのGmail、ドライブ、Meetなどを会社で利用できます。MO-LIBの紹介リンクから新規に申し込む場合は、対象条件を満たすと初年度の利用料金が1ユーザーあたり10%割引になります。申し込み前にリンク先の対象プランと適用条件をご確認ください。

SPF・DKIM・DMARCは何を確認する仕組みか

三つの仕組みは役割が異なります。SPFは送信を許可したサーバー、DKIMはメールへ付けられた電子署名、DMARCは差出人ドメインとの整合と認証失敗時の扱いを確認します。一つだけ設定するのではなく、送信元の実態に合わせて組み合わせます。

仕組み 主に確認すること 設定場所
SPF そのサーバーがドメインからの送信を許可されているか DNSのTXTレコード
DKIM 送信メールへ正しい署名が付き、途中で改変されていないか Google管理コンソールとDNS
DMARC SPF・DKIMとFromドメインが整合し、失敗時にどう扱うか DNSのTXTレコード

Googleのメール送信者ガイドラインでは、個人用Gmailへ送信するすべての送信者にSPFまたはDKIMが求められ、一括送信者にはSPF、DKIM、DMARCが求められています。送信数が少ない会社でも、なりすまし対策と配信の安定性を考え、三つを整えるのがよいでしょう。最新要件はGoogle公式のメール送信者ガイドラインで確認してください。

設定前にメールの送信元をすべて棚卸しする

最初に、独自ドメインを使ってメールを送る仕組みを一覧にします。Google Workspaceだけでなく、問い合わせフォーム、ECカート、モール連携、受注管理、メール配信、請求システムなどが同じドメインを使うことがあります。

  • Google WorkspaceのGmail
  • WordPressなどのWebフォーム
  • ECカート・モール・受注管理・在庫管理・出荷システム
  • メールマガジン、MA、CRM、予約配信サービス
  • 会計、請求、勤怠、複合機などの業務サービス
  • 外部の制作会社や運用会社が使用する送信サービス

送信元を見落としたままSPFを置き換えたり、DMARCの拒否方針を強くしたりすると、正常な業務メールまで認証に失敗する可能性があります。各送信元について、Fromアドレス、実際の送信サービス、SPF・DKIM対応、担当者、停止可否を記録します。

手順1:既存のDNSレコードを保存する

変更前に、現在のSPF、DKIM、DMARCのTXTレコードを保存します。DNSサービス名、対象ドメイン、ホスト名、値、TTL、確認日時も一緒に残してください。画面だけでなくテキストでも記録すると、切り戻しや差分確認がしやすくなります。

SPFは同じドメインに複数のSPFレコードを追加するのではなく、必要な送信元を一つのレコードへまとめる必要があります。新しい送信サービスを追加するときも、既存値を削除して例文へ置き換えず、全送信元を確認して統合します。

手順2:SPFへ利用中の送信元を反映する

Google Workspaceだけから送信する場合、Google公式はSPFの例としてv=spf1 include:_spf.google.com ~allを案内しています。ただし、Webフォームやメール配信サービスなども同じドメインで送信する場合は、それぞれの公式案内にある送信元を含める必要があります。

  1. 既存のSPFレコードがあるか確認する
  2. Google Workspace以外の送信元を一覧にする
  3. 各サービスの公式SPF設定を確認する
  4. 一つのSPFレコードへ統合してDNSへ保存する
  5. 反映後にテストメールのSPF結果を確認する

SPFにはDNS参照回数の上限があり、外部サービスを増やし過ぎると認証に失敗することがあります。Googleのトラブルシューティングでも、SPFは最大10回のDNS参照に対応すると案内されています。送信元を使っていないのに古いincludeを残さず、定期的に整理してください。詳しい設定はGoogle公式のSPF設定をご確認ください。

手順3:DKIM鍵を生成して署名を開始する

DKIMは、Google管理コンソールで公開鍵を生成し、その値をDNSのTXTレコードへ追加してから、管理コンソールで認証を開始します。Google WorkspaceでGmailを有効化した直後は、DKIM鍵を生成できるまで24〜72時間かかる場合があります。

  1. 特権管理者でGoogle管理コンソールへログインする
  2. アプリ、Google Workspace、Gmail、メールの認証を開く
  3. 対象ドメインを選び、DKIMレコードを生成する
  4. 表示されたホスト名とTXT値をDNSへ追加する
  5. DNS反映後、管理コンソールで認証を開始する
  6. 外部の受信先へテスト送信し、ヘッダーを確認する

2048ビット鍵をDNS事業者が扱える場合は、Googleが推奨する2048ビットを選びます。DNSへ追加する値は組織ごとに異なるため、記事の例をコピーせず、管理コンソールに表示された値を使用してください。手順と待機時間はGoogle公式のDKIM設定で確認できます。

手順4:DMARCは監視から段階的に強くする

DMARCを設定する前に、SPFとDKIMを少なくとも48時間前に設定し、正しい送信元が認証を通ることを確認します。最初からp=rejectにすると、棚卸しから漏れた業務メールが拒否される可能性があります。

Googleは、最初はp=noneでレポートを監視し、問題がなければ一部をquarantineへ進め、その後に適用割合や方針を段階的に強くする方法を案内しています。レポートの受信先は、集計メールを継続して確認できる専用アドレスや解析サービスを用意します。

段階 主な目的 確認してから次へ進む条件
p=none 認証結果を監視する 正規送信元の失敗原因を把握できた
p=quarantine 失敗メールの一部を迷惑メール扱いにする 業務メールへの影響がない
p=reject 失敗メールを拒否する 送信元と例外運用を継続管理できる

DMARCの例文にあるドメインやレポート受信先をそのまま使わず、自社の送信環境と確認体制に合わせて設定してください。最新の手順はGoogle公式のDMARC設定をご確認ください。

テストメールのヘッダーで認証結果を確認する

DNSにレコードが見えるだけでは、実際のメールが正しく認証されているとは限りません。社外のGmailまたはGoogle Workspace宛てにテストメールを送り、受信側で「メッセージのソースを表示」からAuthentication-Resultsを確認します。

表示 意味 次の確認
spf=pass 送信元がSPFで許可されている Fromドメインとの整合も確認
dkim=pass DKIM署名を検証できた 署名ドメインとFromの整合を確認
dmarc=pass DMARCの整合条件を満たした 主要送信元すべてで再現するか確認
fail / neutral / none 認証失敗または設定なし 送信元、DNS値、署名、反映待ちを確認

自分自身へのテストだけではDKIMを正しく確認できない場合があるため、Google公式手順どおり外部の受信者へ送ります。本文、差出人、返信先が異なる通知メールは、種類ごとにテストしてください。

メールが届かないときの確認順序

認証エラーが出たときは、DNS値を何度も変更する前に、どの送信元のどの認証が失敗したかを分けます。DNSの反映には最大48時間程度かかる場合があるため、保存直後の結果だけで誤りと判断しないことも重要です。

  1. 送信に使ったサービスとFromアドレスを確認する
  2. 受信側ヘッダーでSPF・DKIM・DMARCの結果を見る
  3. DNSのホスト名、値、余分な引用符や空白を確認する
  4. SPFが一つにまとまり、全送信元を含むか確認する
  5. DKIM署名が実際のメールへ付いているか確認する
  6. DMARCの整合と方針、適用割合を確認する
  7. 変更履歴を残し、反映時間を待って再テストする

ECの自動通知は、管理画面上の送信元表示と実際の配信基盤が異なることがあります。サービス名だけで推測せず、公式マニュアルと実際のヘッダーを照合してください。

EC運営で用意したいメール認証の管理表

一度設定して終わりにせず、新しいカートや配信サービスを追加するときに更新できる管理表を用意します。担当者が変わっても判断できるよう、値だけでなく用途と確認結果を残します。

  • 送信サービス名と用途
  • Fromアドレスと対象ドメイン
  • SPF・DKIM対応状況と公式案内URL
  • DNSへ反映した日、変更者、変更前後の値
  • テスト送信日時、受信先、認証結果
  • DMARCレポートの確認担当と頻度
  • サービス終了時に削除するDNS設定

新しい送信元を追加する場合は、契約担当だけで完結させず、メール管理者へ連絡して認証とテストまでを導入手順に含めます。独自ドメインGmailの初期切り替えはGoogle Workspaceで独自ドメインGmailを設定する方法で整理しています。

まとめ

Google WorkspaceのSPF・DKIM・DMARCは、例文をDNSへ貼り付けるだけの作業ではありません。最初にすべての送信元を棚卸しし、現在のDNSを保存したうえで、SPF、DKIM、DMARCの順に設定とテストを進めます。

特にDMARCは、正規メールの認証結果を確認してから段階的に方針を強くすることが重要です。ECカート、問い合わせフォーム、受注・出荷、メール配信など、業務で使うメールを種類ごとにテストし、設定値と結果を管理表へ残してください。

設定手順・紹介プログラム確認日:2026年9月2日。Google Workspace、Gmail、DNS事業者、各送信サービスの仕様は変更される場合があります。作業時はGoogle管理コンソールと各公式案内に表示される最新情報を優先してください。紹介リンク経由で申込み・契約が行われた場合、MO-LIBに紹介料が発生することがあります。

RELATED ARTICLES

あわせて読みたい記事