Google WorkspaceのDMARC設定方法｜p=noneから安全に始める手順

2026年9月13日

Google WorkspaceでSPFとDKIMを設定した後、次に検討したいメール認証がDMARCです。

DMARCにはnone、quarantine、rejectというポリシーがあります。しかし、なりすまし対策を強めたいからといって、最初からrejectを設定するのは安全とは限りません。Webサイトの問い合わせフォームやメール配信サービスなど、Google Workspace以外の正規の送信元が認証に対応できていないと、必要なメールまで拒否される可能性があります。

結論から言うと、DMARCはSPFとDKIMを確認したうえで、まずp=noneから開始します。レポートで正規の送信元と認証結果を確認し、問題を解消してからquarantine、rejectへ段階的に進めます。

この記事で分かること

DMARCとSPF・DKIMの関係
設定前に確認する送信元と認証結果
レポート受信用アドレスの準備方法
p=noneで始めるDMARCレコードの考え方
レポートを見ながらポリシーを強める順序
問題が起きた場合の確認方法と戻し方

DMARCとは

DMARCは、送信元として表示されるドメインとSPF・DKIMの認証結果を確認し、認証に合格しないメールを受信側がどう扱うかをDNSで示す仕組みです。

DMARCを設定すると、主に次の2つができるようになります。

認証に合格しないメールを、そのまま配信する、迷惑メールとして扱う、拒否するといった方針を示す
自社ドメインを使って送信されたメールの認証状況を集計レポートで確認する

DMARCは、メール本文を暗号化する機能ではありません。また、DMARCを追加しただけで、すべてのなりすましや迷惑メールを防げるわけではありません。

SPF・DKIMとの違い

仕組み	主に確認すること	設定場所
SPF	送信サーバーが許可された送信元か	DNS
DKIM	メールに付いた電子署名が正しいか	Google管理コンソールとDNS
DMARC	SPFまたはDKIMの結果とFromドメインの整合、失敗時の扱い	DNS

DMARCに合格するには、SPFとそのドメイン整合、またはDKIMとそのドメイン整合の少なくとも一方に合格する必要があります。単にSPFやDKIMの結果がpassであるだけでなく、利用者に表示されるFromアドレスのドメインとの関係も確認されます。

SPFの準備は「Google WorkspaceのSPF設定方法」、DKIMは「Google WorkspaceのDKIM設定方法」で確認できます。

設定前に確認する5つの項目

1. SPFとDKIMを48時間以上動作させる

Googleの公式情報では、DMARCを設定する48時間以上前にSPFとDKIMを設定するよう案内されています。

DNSレコードが存在することだけでなく、実際に自社ドメインから送ったテストメールのヘッダーで、SPFとDKIMが想定どおり認証されているかを確認します。

2. 自社ドメインを使うすべての送信元を確認する

Google Workspace以外にも、自社ドメインを使ってメールを送る仕組みがないか確認します。

Webサイトの問い合わせフォーム
メール配信・メールマーケティングサービス
CRM、予約、請求書などの業務システム
複合機、監視サービス、障害通知
SMTPリレーや外部メールゲートウェイ

外部サービスについては、その提供元が案内するSPF・DKIM設定とFromドメインの扱いを確認します。送信元を見落としたままポリシーを強めると、正当なメールが迷惑メール扱いや拒否の対象になる可能性があります。

3. 既存のDMARCレコードを確認する

DNS管理画面またはDNS確認ツールで、_dmarc.example.comのTXTレコードを確認します。example.comは自社のドメインに置き換えます。

すでにv=DMARC1から始まるレコードがある場合は、新しいレコードを追加せず、現在の値と運用状況を確認します。変更前の値は、ホスト名やTTLとともに記録してください。

4. レポートの受信先を用意する

DMARCの集計レポートは、ruaタグで指定したメールアドレスに届きます。個人の受信トレイではなく、専用メールボックスやGoogleグループを用意し、誰が確認するか決めておくと管理しやすくなります。

レポートはXML形式で届き、送信量や送信先によっては件数が多くなる場合があります。継続的な確認が難しい場合は、DMARCレポートの集約・分析サービスも選択肢になります。外部サービスを利用する場合は、提供元、保存場所、料金、機密情報の扱いを確認してください。

レポートの受信先がDMARCを設定するドメインと異なる場合、受信先側のDNSにも確認用レコードが必要です。

5. 変更担当者、確認時間、戻し方を決める

DNSを変更する人、レポートを確認する人、問題が起きた場合に判断する人を決めます。最初の確認期間中は、主要な送信サービスを実際に使ってテストし、通常業務のメールが認証されているか確認します。

最初のDMARCレコードを準備する

初期確認用の例は次のとおりです。

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

これはサンプルです。dmarc-reports@example.comは、実際にレポートを受信・管理できる自社のアドレスへ置き換えます。

タグ	意味
`v=DMARC1`	DMARCのバージョン
`p=none`	認証に失敗しても隔離・拒否を求めず、レポートで確認する
`rua=mailto:...`	集計レポートの送信先

初期段階では、必要性を確認できていないタグをむやみに追加せず、読み取れる構成から始めます。adkimやaspfを省略した場合は緩和モードが使われます。Googleは通常、緩和モードでも十分ななりすまし対策になると案内しており、厳格モードでは正当なサブドメインからのメールが影響を受ける可能性があります。

DNSへDMARCレコードを登録する

DMARCはGoogle管理コンソールではなく、ドメインのDNSを管理するサービスで設定します。

一般的な入力項目は次のとおりです。

項目	入力例
種別	TXT
ホスト名	`_dmarc`
値	`v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com`
TTL	DNS事業者の標準値、または社内方針に従う

DNS事業者によっては、ホスト名へドメイン全体を入力する場合や、ドメイン部分が自動追加される場合があります。登録後に_dmarc.example.comとして公開されているかを確認してください。

設定後に確認する

公開されたTXTレコードを確認する

DNS確認ツールで_dmarc.example.comのTXTレコードを検索し、登録した値が取得できるか確認します。DNS管理画面へ保存できたことと、外部から値を取得できることは別なので、両方を確認します。

DMARCレポートを確認する

Googleの推奨手順では、最初の1週間はp=noneで運用し、DMARCレポートを毎日確認します。

レポートでは、次の項目を確認します。

自社が利用している送信サービスがすべて現れているか
SPF、DKIM、DMARCに合格している割合
認証に失敗している正当な送信元がないか
心当たりのないIPアドレスやサービスがないか

XMLを直接読むのが難しい場合は、分析サービスを利用できます。ただし、レポートには送信元IP、ドメイン、送信件数などが含まれるため、利用前に情報の取り扱いを確認します。

quarantine、rejectへ段階的に進める

少なくとも1週間レポートを確認し、正当な送信元の問題を解消してから、適用を強めます。

Googleの例では、quarantineを少ない割合から開始します。

v=DMARC1; p=quarantine; pct=5; rua=mailto:dmarc-reports@example.com

pct=5は、DMARCに合格しないメールのうち5%をポリシーの対象にする例です。自社の送信量や影響範囲に合わせ、レポートと配送状況を確認しながら徐々に割合を増やします。

p=rejectでは、DMARCに合格しないメールが受信側で拒否される可能性があります。送信元の確認が不十分な状態で切り替えないでください。

問題が起きた場合の確認と戻し方

DMARCの変更後に正当なメールが届かない、迷惑メールへ入る、バウンスが増える場合は、次の順で確認します。

影響を受けている送信サービスとFromアドレスを特定する
メールヘッダーでSPF、DKIM、DMARCの結果とドメイン整合を確認する
DMARCレポートで同じ送信元の結果を確認する
外部サービス側の認証設定を確認する
必要に応じて、変更前のポリシーまたはp=noneへ戻す

削除や変更を繰り返す前に、現在値と変更履歴を保存します。メールが届かない原因はDMARCだけとは限りません。送信経路全体の切り分けは「Google Workspaceから送ったメールが相手に届かない原因と確認方法」も参考にしてください。

まとめ

Google WorkspaceのDMARC設定では、DNSへレコードを追加する作業より、設定前の送信元確認と導入後のレポート確認が重要です。

SPFとDKIMを設定し、48時間以上認証させる
Google Workspace以外の送信サービスも確認する
レポート専用の受信先を用意する
p=noneで始め、少なくとも1週間レポートを確認する
問題を解消してからquarantine、rejectへ段階的に進める

自社の送信元や既存のDNSレコードを判断できない場合は、現在値を削除する前に、DNS事業者、利用中の配信サービス、Google Workspaceの販売店やサポートへ確認してください。

出典・参考情報

情報確認日：2026年9月13日

よかったらシェアしてね！

URLをコピーしました！

URLをコピーしました！

この記事を書いた人

戸張将汰

コエドテックにて、Google Workspace活用、AI活用、Webサイト制作、業務効率化支援を担当。
中小企業の現場に合わせたIT導入・運用整理を行い、相談から実行、定着まで伴走します。