Google Workspace（Gmail）でDMARCを設定する方法

Google Workspace（Gmail）向けのDMARCは、お客様のドメインからのメールがSPFまたはDKIMの検証に失敗した場合、受信サーバーに対して、そのメールを隔離するか、拒否するか、あるいは単に報告するかを指示します。Google Workspaceは送信メールの配信とDKIM鍵の生成を処理しますが、DMARCレコードを公開することはありません。その部分はお客様ご自身で設定するDNSレコードであり、お客様のドメインとなりすまし攻撃の間に立ちはだかる唯一の防壁となります。

Googleが2024年に導入した大量送信者向け要件により、DMARCは大量送信者にとってもはや任意の措置ではなくなりました。Gmailに対して1日あたり5,000通以上のメッセージを送信するドメインは、有効なDMARCレコードを設定しなければならず、そうしないとメッセージが拒否されるリスクがあります。

特にGmailでのDMARCの設定方法をお探しの場合でも、手順は同じです。GmailはGoogleのメールインフラストラクチャを利用しているため、個人のGoogle Workspaceプランをご利用の場合でも、Gmail for Business経由で送信する場合でも、以下の設定手順が適用されます。 このガイドでは、SPFおよびDKIMの前提条件、公開すべき正確なレコード、各タグの詳細解説、監視モード（p=none）から完全適用モード（p=reject）までの段階的な手順など、必要な情報をすべて網羅しています。また、レコードの例や、設定過程でメールの配信を妨げるよくあるミスについても解説しています。

DMARCとは何か、そしてなぜGoogle Workspaceにはそれが必要なのか？

DMARC（Domain-based Message Authentication, Reporting, and Conformance）は、DNS に基づく電子メール認証規格であり、SPF と DKIM を統合し、受信サーバーに対してこれらの検証に失敗したメッセージの処理方法を指示するとともに、どの送信者があなたのドメインを使用してメールを送信しているかに関するレポートを送信します。

ここで、多くの人が見落としている点があります。Google Workspaceは 転送を保護します。TLS による接続の暗号化、受信スパムのフィルタリング、そして送信メールの確実な配信を行います。しかし、DMARC は ドメインレベルの 制御であり、ドメイン所有者だけが設定できます。Googleがユーザーに代わってDMARCレコードを公開することはなく、Google側でどれほどスパムフィルタリングを行っても、攻撃者がドメインを偽装して 他の人々 人々に送信することを防ぐことはできません。DMARCは、まさにこの隙間を埋めるものです。

また、これはもはや任意ではなくなりました。 Googleの大量送信者向け要件 では、1日あたり5,000通以上のメッセージをGmailアドレスに送信するドメインは、DMARCレコードを公開しなければならず、そうしない場合、Googleはメールの受信を拒否し始めます。この閾値を下回る場合でも、DMARCは現在、良好な配信率を確保するための最低限の要件となっています。 

概念について詳しく知りたい場合は、以下の詳細ガイドをご覧ください。 「DMARCとは何か」をご覧ください。 

前提条件：まずSPFとDKIMを設定してください

DMARC自体はメールの認証を行いません。DMARCはSPFおよびDKIMの上に位置し、その結果を適用するものです。DMARCの検証に合格するためには、これら少なくとも1つが合格している必要があります かつ ドメインと整合している必要があります。したがって、DMARCレコードを公開する前に、これら2つを確実に整備してください。以下に簡略版を記載します。それぞれに詳細な手順へのリンクがあります。

Google Workspace 向け SPF（クイックセットアップ）

SPFとは、ルートドメインに設定する単一のTXTレコードであり、そのドメインに代わってメールを送信することが許可されているサーバーを指定するものです。Google Workspaceの場合、必須のレコードは以下の通りです：

v=spf1 include:_spf.google.com ~all

v=spf1 でレコードを開始し、include:_spf.google.com で Google のメールサーバーを認証し、~all でそれ以外のすべてをソフト失敗とします。追加のサービスを経由して送信する場合は、それらの include を同じレコードに追加してください（決して 2 つ目の SPF レコードを作成しないでください）：

v=spf1 include:_spf.google.com include:servers.mcsv.net include:sendgrid.net ~all

フラット化、ルックアップ、およびエッジケースに関する詳細な解説については、当社の Google Workspace向けSPFレコードの完全ガイド ガイドをご覧ください。

Google Workspace 向け DKIM（クイックセットアップ）

DKIMは、送信メールに暗号署名を追加します。Google Workspaceが鍵を生成し、それをDNSに登録します：

1. 管理コンソールで、[アプリ] → [Google Workspace] → [Gmail] → [メールの認証] の順に選択します。
2. ドメインを選択し、「新しいレコードを生成」をクリックしてください（2048ビットを推奨）。
3. Googleが生成したTXTレコードをコピーしてください。これは「google._domainkey」のようなホスト名と、「v=DKIM1; k=rsa; p=…」で始まる長い値で構成されています。
4. そのTXTレコードを、ご利用のDNSホストで公開してください。
5. 管理コンソールに戻り、「認証を開始」をクリックします。

レコードは次のようなものです：

Host/Name:  google._domainkey.yourdomain.com
Type: TXT
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...

完全な手順については、以下の「 ドメインのDKIM設定方法をご覧ください。

Note: Google Workspace handles DKIM signing (you generate the key in the Admin Console) and SPF is a DNS record you publish yourself, but Google does not create or publish a DMARC record for your domain. That part is entirely on you, and it's what the rest of this guide covers.

Google Workspace で DMARC レコードを設定する方法

SPFとDKIMが稼働していれば、DMARCの導入準備は整っています。ここでは、その手順を段階ごとに詳しく説明します。

ステップ 1：DMARC レコードを作成する

DMARCレコードとは、タグで構成される単一のTXTエントリのことです。基本的なレコードの例は次のようになります：

v=DMARC1; p=none; rua=mailto:[email protected];

当社の DMARCジェネレーターを使用すれば、構文を自動的に生成して視覚的に作成できます。各タグの役割は以下の通りです：

• v: プロトコルバージョンを定義するために使用され、常に DMARC1 となります。これは必須のタグです
• p: は、DMARCポリシーモードを定義するために使用され、これも必須のタグです。 
• rua: 集約レポートの宛先を指定するために使用されます。これはオプションのタグですが、認証結果を監視するために強く推奨されます。 

Note: The one tag people misread is p. p=none, which is the starting point, not the end state, as it only monitors and reports, it doesn't protect anything yet. The goal is to reach p=reject without breaking mail flow.

ステップ 2: DNS にレコードを登録する

DMARCの設定は、ドメイン登録業者またはDNSホストのDNSに追加し、 Google 管理コンソール内には Google 管理コンソールには設定しません。DMARC は DNS レコードであり、Google Workspace の設定ではありません。DNS パネルで、以下を追加してください：

そのままにしておいてください。DNSの反映には最大48時間かかる場合がありますが、通常はそれよりはるかに早く、多くの場合1時間以内に完了します。

ステップ 3: DMARC レコードの確認

公開後は、当社の DMARCレコードチェッカーで正しく解決されるか確認してください。チェックに成功すると、レコードが表示され、構文が有効であることが確認されます。例えば、検出されたポリシーが「p=none」であること、有効なRUA報告アドレスが指定されていること、構文エラーがないことが表示されます。チェッカーがレコードを検出できない場合は、DNSの伝播にさらに時間を置くか、ホスト名または名前フィールドを再確認してください。

ステップ4：適用前にレポートを確認する

p=none が有効になると、Google やその他の受信サーバーは、RUA タグに記載されたアドレス宛てに集計レポート（RUA レポート）の送信を開始します。これらのレポートには、貴社のドメインを差出元としてメールを送信しているすべての送信元と、それぞれが SPF および DKIM の整合性チェックに合格したか不合格だったかが表示されます。

注目すべき点は、正常に機能していない正当な送信元です。実際に使用しているマーケティングプラットフォーム、CRM、ヘルプデスクツール、または請求書発行サービスであっても、そのドメインでSPFやDKIMがまだ設定されていないために、整合性が取れていない可能性があります。強制適用を行う前にこれらを修正してください。そうしないと、隔離や拒否の設定により、自社のメールまでブロックされてしまうことになります。 

生のDMARC XMLは読みづらいので、当社の 「DMARCレポートの読み方」 ガイドを参照して内容を解釈してください。送信サイクル全体を把握できるよう、監視期間は最低でも2～4週間を確保することをベストプラクティスとしています。

ステップ 5：強制措置へ移行（p=隔離、その後 p=拒否）

レポートで正当な送信者がすべて通過していることが確認できたら、ポリシーを段階的に厳格化してください：

1. p=なし → p=隔離: 配信に失敗したメールは受信トレイではなくスパムフォルダに振り分けられます。レポートを再度確認してください。
2. p=隔離 → p=拒否: 不合格となったメールは即座にブロックされます。ここで、本格的ななりすまし防止対策が機能し始めます。

より安全に展開するには、 t (t=y) タグを使用して、適用レベルを最大に設定する前にポリシーをテストしてください。適用レベルの選択や段階的な引き上げについては、当社の DMARCポリシー ガイドで詳しくご確認ください。

Google Workspace の DMARC レコードの例

現在の段階に合わせて、そのままコピーして使える3つの記録例です。メールアドレスはご自身のものに置き換えてください。

基本的な監視（はじめに）

v=DMARC1; p=none; rua=mailto:[email protected];

報告を伴う隔離

v=DMARC1; p=quarantine; rua=mailto:[email protected]; adkim=r; aspf=r;

完全な施行

v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=s; aspf=s;

Note: the strict alignment here (adkim=s, aspf=s) requires the domain in the DKIM signature or SPF to match your sending domain exactly, with no subdomains. Relaxed (r) allows subdomains to align. Example mail from mail.yourdomain.com still aligns with yourdomain.com. Use relaxed while you're stabilizing, and only switch to strict once you're certain every legitimate sender uses your exact domain.

Google Workspace の DMARC に関するよくある間違い

SPFやDKIMを導入していない状態でDMARCを公開する

SPFもDKIMも検証に合格せず、整合性も取れていない場合、DMARCには適用すべきルールがありません。特に「隔離」や「拒否」の設定で、まずDMARCを適用すると、自社のメールが配信失敗する可能性があります。必ずSPFとDKIMを正常に機能させてから、その上にDMARCを重ねるようにしてください。

p=none の状態を無期限に維持する

p=none は監視のみを行い、何もブロックしません。多くのドメインがこの設定を公開し、レポートが届くのを確認したまま、それ以上の対応を一切行いません。p=reject に設定するまでは、スプーフィング攻撃者には影響が及びません。none は最終的な設定ではなく、一時的な監視段階として扱ってください。

SPF/DKIMにおけるサードパーティ送信者の欠落

マーケティングツール、CRM、チケット管理システム、請求書発行サービスなどは、すべて「as you」形式でメールを送信します。これらがSPFの許可リストに登録されていない場合、または整合性のあるDKIMで署名されていない場合は、DMARCの検証に失敗し、ポリシーを適用するとそれらのメールはブロックされます。ポリシーを厳格化する前に、監視レポートを活用してすべての送信元を把握しておきましょう。

誤ったDNSホスト名の使用

最も頻繁に見られる構文エラーは、レコードの「value」フィールドに「_dmarc」を記述してしまうか、先頭のアンダースコアを完全に省略してしまうことです。「host/name」フィールドには「_dmarc」（「_dmarc.yourdomain.com」に解決されるもの）を指定する必要があります。また、「value」フィールドには「v=DMARC1; …」という文字列を指定します。

1つのドメインに複数のDMARCレコードを設定する場合

1つのドメインには、DMARCレコードを1つだけ設定できます。_dmarc TXTレコードを2つ以上設定すると、受信側はDMARCを完全に無視するようになり、保護機能が無効になってしまいます。レコードを更新する場合は、2つ目を追加するのではなく、既存のレコードを編集してください。

PowerDMARCがGoogle Workspace向けのDMARCをどのように簡素化するのか

手動でのDMARC運用は機能しますが、生のXMLレポートの読み取り、問題のある送信者の特定、そして「none」から「reject」への安全な移行といった継続的な作業において、多くのドメインが足踏み状態になっています。

PowerDMARC は、それらのXMLレポートを人間が読みやすいダッシュボードに変換し、ホスト型DMARCを提供することで、毎回DNSに手を加えることなくポリシーを更新できるようにします。また、自動化された適用プロセスをガイドし、新しい送信元があなたのドメインとして送信を開始した瞬間にリアルタイムのアラートを送信するため、正当なメールを遮断することなく、より迅速に「p=reject」による完全な保護を実現できます。

よくあるご質問

1. Google Workspace には DMARC が組み込まれていますか？

いいえ。Google Workspace では、通信のセキュリティ、スパムフィルタリング、DKIM キーの生成は処理されますが、DMARC レコードの作成や公開は行われません。DMARC は DNS レコードであり、ドメイン所有者が別途公開する必要があります。

2. Google Workspace に DMARC レコードを追加するにはどうすればよいですか？

管理コンソールで追加するのではなく、DNSホストでホスト名/名前を「_dmarc」、値を「v=DMARC1; p=none; rua=mailto:[email protected]」のように設定して、TXTレコードとして公開します。

3. Google Workspace における正しい DMARC レコードとは何ですか？

まずは監視用に「v=DMARC1; p=none; rua=mailto:[email protected]」から始め、正当な送信者が通過するようになったら「p=quarantine」へと移行し、最終的には「p=reject」に設定してください。

4. DMARCを設定する前に、SPFとDKIMは必要ですか？

はい。DMARCはSPFおよびDKIMの結果を適用するため、DMARCの検証に合格するには、少なくともいずれか一方を実装し、設定を整合させる必要があります。DMARCを導入する前に、両方を設定しておくことをお勧めします。 

5. DMARCレコードにおける「p=none」とはどういう意味ですか？

p=none は監視モードです。受信側は配信に失敗したメールを報告しますが、それに対して何の措置も講じません。これは安全な出発点ですが、隔離または拒否モードに移行するまでは保護機能は働きません。

6. DMARCレコードが有効になるまで、どのくらいの時間がかかりますか？

レコードの反映には最短で数分しかかかりませんが、DNSの変更が反映されるまでには最大48時間かかる場合があります。集計レポートは通常、1～2日以内に届き始めます。

7. なぜ私のGoogle Workspaceのメールは、依然としてDMARCの検証に失敗しているのですか？

通常、このような現象が発生するのは、正当な送信元（多くの場合、サードパーティのサービス）がSPFレコードで承認されていないか、DKIMの整合性が取れていないためです。集計レポートを確認して、問題の原因となっている送信元を特定し、整合性を修正してください。

8. Googleの一括送信者向けガイドラインにおいて、DMARCは必須ですか？

はい。Googleの一括送信者に関する要件に基づき、Gmailに対して1日あたり5,000通以上のメッセージを送信するドメインは、有効なDMARCレコードを設定する必要があります。そうしないと、メールが拒否される可能性があります。当社の GoogleおよびYahooのコンプライアンス ガイドをご参照ください。

• について
• 最新記事

Ahona Rudra

ドメインおよびメールセキュリティの専門家（所属： PowerDMARC

AhonaはPowerDMARCのマーケティングマネージャーで、サイバーセキュリティのトピックについて5年以上の執筆経験があり、ドメインと電子メールのセキュリティを専門としている。ジャーナリズムとコミュニケーションの卒業後学位を取得し、2019年からセキュリティ分野でキャリアを固めている。

最新記事 by Ahona Rudra(全て見る)

• 無料のDMARCツール：チェッカー、ジェネレーター、モニタリング（2026年） - 2026年7月30日
• メールフィルタリングサービスとは？ - 2026年7月29日
• メールのなりすまし：その仕組みと対策 - 2026年7月29日