DMARC p=reject 段階移行の判断基準と監視設計

Google Workspace の公式ヘルプは、DMARC (Domain-based Message Authentication, Reporting and Conformance) p=reject 段階移行を最終目標として、p=none → quarantine → reject の順で段階的に導入する手順を明示しています。この記事では、各フェーズの移行判断基準・監視指標・ロールバック条件を整理します。

この記事を読んだほうが良い人

• Google Workspace で自社ドメインのメール送信を管理しており、DMARC を p=none のまま放置している情シス担当者
• SPF/DKIM の設定が完了しているが、p=quarantine への移行タイミングを決めかねている方
• p=quarantine 以降の監視指標とロールバック条件を言語化したい方

DMARC ポリシー 3 値の役割対比

DMARC レコードの p= タグには 3 種類の値があり、受信サーバーの動作が根本的に変わります。

ポリシー値	受信サーバーの動作	適切なフェーズ
p=none	認証失敗でも通常配送。集計レポート（RUA）のみ送信	初期監視フェーズ
p=quarantine	認証失敗メールを迷惑メールフォルダへ振り分け	移行検証フェーズ
p=reject	認証失敗メールをバウンス（拒否）	本番強制フェーズ

段階的に進める理由は、「正規の業務メールが巻き込まれていないか確認しながら移行できるから」です。いきなり p=reject にすると、設定漏れのある送信サービスからのメールが全てバウンスします。

DMARC アライメントの基本

DMARC には「アライメント」という概念があります。From ヘッダのドメインと、SPF の認証ドメイン（Return-Path で確認できるドメイン）または DKIM 署名ドメイン（d= タグ）が一致するかどうかを確認する仕組みです。

adkim= と aspf= タグでアライメントの厳密度を指定できます。

• relaxed（デフォルト）：サブドメインまでは一致を許可する（例：mail.yourdomain.com が yourdomain.com と一致する）
• strict：完全一致のみ許可する

メール配信サービスを使っている場合、From ドメインと送信元ドメインが異なることが多いため、relaxed モードで運用するのが一般的です。strict を使う場合は、全ての送信元で d=yourdomain.com と一致する DKIM 署名が設定されていることを確認してから設定します。

フェーズ 0：p=none 設定前の SPF/DKIM 設定確認チェックリスト

DMARC を有効にする前に、SPF (Sender Policy Framework) と DKIM (DomainKeys Identified Mail) の設定が完了していることを確認します。Google Workspace の公式ヘルプでは「SPF と DKIM を設定してから 48 時間待ち、その後 DMARC を追加する」ことを推奨しています。

SPF の確認チェック

• ドメインの DNS に SPF レコード（TXT レコード）が登録されているか
• Google Workspace 用の include:_spf.google.com が含まれているか
• マーケティングツール・問い合わせシステム・申請システムなど、GWS 以外のメール送信サービスの送信 IP も SPF に含まれているか
• SPF レコードの DNS ルックアップ数（include: / a / mx / ptr / exists / redirect の合計）が 10 件以内に収まっているか（include: の数だけでなくすべての DNS 参照メカニズムを合算してカウントする）

Google Workspace のみを使っている場合の最小構成 SPF レコードは次のとおりです。

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

~all（ソフトフェイル）か -all（ハードフェイル）かについては、DMARC を p=reject にするまでは ~all が安全です。p=reject で運用が安定してから -all への変更を検討します。

SPF レコードが正しく設定されているかは、ターミナルで次のコマンドで確認できます。

dig TXT yourdomain.com | grep spf

DKIM の確認チェック

• Google Workspace 管理コンソールのメール設定から DKIM 署名が「有効」になっているか
• DKIM キーを DNS に追加してから最大 48 時間の伝播待ちが完了しているか（※Gmail 組織有効化直後は Admin コンソールでキー生成できるまでに 24–72 時間の事前待機が別途発生する場合がある）
• サードパーティ送信サービスにも個別の DKIM 設定が完了しているか

DKIM が正しく伝播しているかは次のコマンドで確認できます（google._domainkey は Google Workspace のデフォルトセレクター名です）。

dig TXT google._domainkey.yourdomain.com

TXT レコードが返ってきて、v=DKIM1; k=rsa; p=... 形式の文字列が含まれていれば正常です。

DMARC レコードの初期設定例（p=none）

以下は監視フェーズ用の最小構成です。rua= に指定したアドレスに集計レポート（XML）が届きます。

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; pct=100

なお、Google 公式ドキュメントによると ruf=（フォレンジックレポート送信先）タグを設定しても Gmail はフォレンジックレポートを送信しません。ruf= タグは必須ではなく、rua= の集計レポートに集中するのが実務的です。

フェーズ 1：p=none での監視と quarantine 移行判断基準

p=none で運用中に確認すべき観点と、次のフェーズへの移行判断基準を整理します。

週次の監視チェック

• rua= で受け取った集計レポート（ZIP または GZIP 形式の XML ファイル）を確認し、送信元 IP ごとの DMARC 通過率を把握しているか
• 認証失敗している IP が「意図した送信元」か「意図しない送信元」かを分類しているか
• 意図した送信元（マーケツールなど）が失敗している場合は、その送信元の SPF/DKIM 設定を修正済みか
• 未知の送信 IP（自社が送信した記憶のないもの）が出現していないか確認しているか

RUA レポートは自動転送されますが、誰も開いていない状態が続きやすいです。週次のカレンダー通知を設定し、確認する当番をあらかじめ決めておくと「受け取っているつもりで見ていない」状態を防げます。

p=quarantine への移行判断基準

以下を全て満たしたら移行を検討します。

• 直近 7 日間の RUA レポートで、DMARC 認証通過率が毎日 95% 以上であること
• 業務で使用している全ての送信元（GWS、マーケツール、申請システム等）が認証通過していること
• 未知・認識外の送信 IP が RUA レポートに出現していないこと

95% は実務上の目安です。残り 5% の失敗は転送メールや特殊なシステムメールが大半を占めます。「業務必須の送信元が全て通過しているか」を最重要の基準として確認してください。

フェーズ 2：p=quarantine の段階適用と p=reject 移行

pct タグで段階ロールアウトする

quarantine や reject に移行する際は、pct= タグ（ポリシー適用対象のパーセンテージ）を使って段階的に適用するのが安全です。最初から pct=100; p=quarantine にする代わりに、次の順で引き上げます（大規模組織は pct=1 から始めるのが GWS 公式の推奨です）。

• pct=10 で 1 週間観察
• 問題がなければ pct=25 に引き上げて 1 週間
• さらに pct=50 → pct=100 の順で引き上げる

段階開始時（pct=10）のレコード例です。

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

pct=100 まで引き上げて安定確認を行う段階のレコード例です。

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

p=reject 移行後の最終形（sp= でサブドメインも reject にする場合）です。

v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:dmarc-reports@yourdomain.com

p=quarantine 移行後の監視指標

監視指標	確認頻度	要調査の目安
DMARC 通過率（RUA レポート）	毎日	95% を下回ったら原因調査
業務メールのバウンス増加	毎日	バウンスが増加傾向にあったら調査
迷惑メール誤判定の問い合わせ	週次	件数が前週より増えたら送信元を再確認
未知の送信 IP の新規出現	週次	新規 IP が出たら正規の送信元か確認

p=reject への移行判断基準

• pct=100; p=quarantine の状態で 30 日間継続して通過率 98% 以上であること
• 迷惑メール誤判定（正規業務メールが quarantine 扱い）の問い合わせがゼロであること
• サブドメイン（sp= タグ）の扱いを確認済みであること
• 組織外への自動転送メールが存在する場合、その影響を把握した上で移行していること

30 日・98% という基準は実務的な目安です。送信ボリュームが少ない場合はサンプルが偏りやすいため、7 日ではなく 30 日で判断する方が安定した数値が得られます。

ロールバック条件と対応

p=quarantine または p=reject に移行した後、以下の状況が発生したら即座に p=none に戻します。

• 正規の業務メールがバウンスまたは迷惑メール扱いになっている報告が来た
• 取引先・顧客から「メールが届かない」という問い合わせが複数件来た
• RUA レポートで DMARC 通過率が 80% を下回った

ロールバック自体は DNS の p= 値を書き換えるだけで、TTL 伝播後（最短 1 時間〜最大 48 時間）に反映されます。緊急ロールバックに備えて TTL を 3600 秒以下に設定しておくと対応が速くなります。p=reject への移行前に TTL を 3600（1 時間）に引き下げておくことを推奨します。

よくある失敗パターンと対処

パターン 1：SPF の include チェーン超過

メール送信サービスを追加し続けるうちに SPF の include: が 10 件を超え、SPF が永続的に失敗する状態（PermError）になります。この問題の厄介なところは、SPF レコードを見ただけでは気づきにくい点です。include: が参照するレコードがさらに include: を持っている場合、ネストの深さで 10 件に到達します。

対処は 2 段階で考えます。まず dig TXT yourdomain.com でレコードを取得し、参照チェーンの数を数えます。10 件を超えている場合は、使用頻度の低い送信サービスの include: を削除するか、送信 IP を ip4: / ip6: で直書きする方式に変更します。

パターン 2：マーケティングツールを DMARC の監視対象から外してしまう

GWS 側の設定は完璧でも、メール配信サービスの SPF/DKIM 設定を漏らし、DMARC 失敗が出続けるケースがあります。特にメルマガ配信ツール・問い合わせフォームツール・CRM からの自動送信は、From ドメインが yourdomain.com であっても送信 IP は GWS のものではありません。RUA レポートで失敗 IP を特定し、各サービスのドキュメントに従って SPF レコードへの追加と DKIM 署名の設定をそれぞれ行うことで解消できます。

パターン 3：サブドメインのポリシーを見落とす

p= は組織ドメイン全体に適用されますが、サブドメイン専用のメール（例：newsletter.yourdomain.com）には sp= タグで別ポリシーを設定できます。p=reject に移行した後にサブドメインからの正規メールがバウンスし始めるケースがあるため、移行前に sp= の設定を確認します。

まずは sp=quarantine でサブドメインに対して穏やかなポリシーを適用し、問題がなければ sp=reject に引き上げる手順が安全です。

パターン 4：メール転送が DMARC を壊す

外部へのメール自動転送は、転送先のサーバーが送信元 IP を書き換えるため SPF アライメントが失敗します。転送経路が存在する場合は、p=reject 移行前に ARC (Authenticated Received Chain) への対応状況を確認します。ARC は転送経路における認証チェーン情報を保持する仕組みで、Google のメールサーバーは ARC に対応しています。

組織内で Outlook や Gmail への転送設定を行っているユーザーがいる場合、p=reject 移行後に転送先で受信できなくなる可能性があります。RUA レポートで転送経由の失敗 IP を事前に把握しておくことが重要です。

まとめ：Gmail 送信者認証のフェーズを止めずに進めるために

DMARC の段階移行でよく起きるのは「p=none のまま数ヶ月放置」です。RUA レポートを受け取っているつもりでも、誰も分析していない状態が続くと移行の意思決定が進まなくなります。

各フェーズのおおよその所要期間をまとめると次のとおりです。

フェーズ	内容	最低観察期間
フェーズ 0	SPF/DKIM 設定 → 伝播待ち	48〜72 時間
フェーズ 1	p=none で RUA 監視	最低 7 日間（通過率 95% 達成まで）
フェーズ 2a	p=quarantine pct=10〜100 段階適用	各段階 7 日間 × 4 ステージ
フェーズ 2b	p=quarantine pct=100 で安定確認	30 日間（通過率 98% 維持）
フェーズ 3	p=reject 移行	—

急いでも合計で約 2 ヶ月は見ておくのが現実的です。途中のフェーズをスキップすると問題の発見が遅れ、ロールバック後にゼロから再確認が必要になります。

進め方のポイントは 2 つです。

1 点目は「定期レビューの仕組みを作る」こと。週に一度、RUA レポートの通過率を誰かが確認するルールを設け、移行判断の数値基準（95% 超か否か）を事前に合意しておきます。属人化しないことが継続の条件です。

2 点目は「ロールバック手順を先に書いておく」こと。問題発生時に即座に戻せると分かっていれば、移行の踏み出しが軽くなります。DNS の値を 1 行変えるだけで戻せる設計は DMARC の利点です。

Google Workspace の公式ヘルプが p=reject への移行を推奨する背景には、送信者なりすましへの対策がメールセキュリティの基盤として位置づけられているという事実があります。SPF/DKIM 設定確認から始め、7 日間 RUA レポートを観察し、通過率 95% を超えたら次のフェーズへ進む——このサイクルを繰り返すことで p=reject まで到達できます。

コーポレートITのご相談はお気軽に

この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。