## この記事でわかること - pctタグで「10→25→50→100%」と段階的に適用範囲を広げる具体的な手順とDNSレコード例 - 各ステップで「進む・止まる・戻す」を判断するためのレポート観察ポイント - DMARCbis（次世代仕様）でpctが廃止される見通しと、t=yフラグへの移行準備 ## pctタグは段階的ロールアウトの安全弁 DMARC（ディーマーク）のポリシー強化は、`p=none`から`p=quarantine`、最終的に`p=reject`まで段階的に進めるのが定石です。ただ「いきなり全件にp=quarantineを適用する」のは、把握できていない正規送信経路があった場合の影響が大きすぎます。 ここで安全弁の役割を果たすのが`pct`タグです。`pct`は0〜100の整数で、デフォルトは100。値を絞ることで、**DMARC認証に失敗したメールのうち何%にp=quarantine/p=rejectを適用するか**を指定できます。残りはひとつ下のポリシー（p=rejectならquarantine相当、p=quarantineならnone相当）として扱われます（[RFC 7489 Section 6.6.4](https://datatracker.ietf.org/doc/html/rfc7489#section-6.6.4)）。 ``` v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@example.co.jp ``` 上記であれば、DMARC失敗メールの10%だけがquarantine扱いになり、残り90%は監視のみ（p=none相当）として処理されます。`p=reject`に進むときも同じ要領で割合を絞れます。 p=noneからp=quarantineへ進む前に確認する3つの観察ポイントは、[DMARCのp=quarantine強化｜段階的移行の手順](/blog/dmarc-policy-tightening)に整理しています。本記事は、そのうえで実際にpctを操作するロールアウトのスケジュールと判断基準に絞って解説します。 DMARCそのものの概念や初期設定は、先に[DMARCとは？Web 担当者が今すぐ対応すべき理由](/blog/what-is-dmarc)と[DMARC設定方法を徹底解説](/blog/dmarc-setup-guide)をご確認ください。 ## 段階的ロールアウトの実務スケジュール（10→25→50→100%） 中小企業の実運用で扱いやすい刻みは、**10→25→50→100%の4段階**です。各段階で1〜2週間の観察期間を取ると、配送停止リスクを抑えつつ、おおむね2〜3ヶ月でp=quarantine 100%適用まで到達できます。 ![pctロールアウトの4段階スケジュール](/blog/dmarc-pct-rollout/rollout-schedule.svg) ### ステップ1: pct=10で開始（運用1〜2週目） ``` v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@example.co.jp; sp=none; adkim=r; aspf=r ``` DMARC失敗メールの10%だけがquarantine扱いになります。万一見落としていた送信経路があっても、影響範囲を10%に抑えられます。最初の1週間で集計レポート（rua）を確認し、異常がないか観察します。 ### ステップ2: pct=25へ引き上げ（運用3〜4週目） ``` v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.co.jp; sp=none; adkim=r; aspf=r ``` 四分の一まで広げます。pct値はTXTレコードの書き換えだけで反映されますが、DNSのTTL（キャッシュ保持時間）の関係で受信側全体に行き渡るまで最大数時間かかる点だけ注意してください。 ### ステップ3: pct=50へ引き上げ（運用5〜6週目） ``` v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc@example.co.jp; sp=none; adkim=r; aspf=r ``` 半分まで広げます。ここまで問題が出ていなければ、自社の送信経路はおおむね把握できていると判断できます。 ### ステップ4: pctを外して100%適用（運用7週目以降） ``` v=DMARC1; p=quarantine; rua=mailto:dmarc@example.co.jp; sp=none; adkim=r; aspf=r ``` `pct`を省略するとデフォルトの100%が適用されます。明示的に`pct=100`と書く必要はありません。むしろDMARCbisでpctが廃止されるため（後述）、運用が安定したらpct自体を取り除くのが推奨です。 p=quarantineで安定運用できたら、同じ要領で`p=reject; pct=10`から始めて段階的にrejectまで引き上げます。p=rejectまで進めば、なりすましメールは受信拒否され、ブランドと取引先を本格的に保護できる状態になります。 ## 各ステップの観察ポイントと判断基準 各ステップを進めるかどうかは、**rua（集計レポート）の数値**で判断します。「期間が経ったから次へ」ではなく、データを見て決めることが重要です。 レポートの読み方は[DMARCレポートの見方｜集計XMLを読み解く](/blog/dmarc-report-reading)で解説しています。 ### 進めてよいサイン（次のステップへ） - 主要送信元IPからのメールが、SPFまたはDKIMでアラインメント込みのpassを継続している - DMARC失敗が出ているIPが、把握済みの送信経路（マーケ配信ツール、社内SMTPサーバー等）に限られている - 取引先や社内から「メールが届かない」「迷惑メールに入った」という問い合わせが増えていない この3点が揃っていれば、次の割合に進んで問題ありません。 ### 止まるべきサイン（同じ割合で観察を延長） - 把握できていないIPからの正規メールがレポートに新たに出てきた - DMARC失敗の総数が前週比で大きく増えている - 季節要因（請求書送信、年次案内等）で普段と違う送信経路が動いている時期 この場合は1〜2週間観察期間を延ばし、新規送信経路のSPF/DKIMを整備してから次に進みます。 ### 戻すべきサイン（pctを下げる、またはp=noneに戻す） - 「お客様向けの自動配信メールが迷惑メールフォルダに入ったと連絡があった」など、正規メールの誤判定が現実に起きた - 重要取引先からの「届かない」相談が複数ドメインに渡って発生 この場合は迷わず`pct`を下げる、または`p=none`にいったん戻して原因究明を優先してください。pctはあくまで影響範囲を絞る安全弁なので、**戻すことを「失敗」ではなく「正常な運用」**と捉えるのがおすすめです。 ![進む・止まる・戻すの判断フロー](/blog/dmarc-pct-rollout/decision-flow.svg) ## pctの実装ばらつきとDMARCbisでの廃止予定 ここまでpctを使ったロールアウト手順を説明してきましたが、**pctタグには受信側の実装ばらつきという根本的な制約**があります。理解しておくと、ロールアウトの設計判断が現実的になります。 [RFC 7489 Section 6.6.4](https://datatracker.ietf.org/doc/html/rfc7489#section-6.6.4)では、受信側はpct値に近い割合をstatistical mechanism（統計的な仕組み）で実現することとなっています。ただしこの「近い割合」の実装は受信側プロバイダごとに差があり、中間値（pct=10やpct=50など）を厳密に実現していない実装も多いことが知られています。具体的には、以下の挙動差が報告されています。 - **0と100以外の中間値の精度が低い**: 受信プロバイダによってはpct=50を「半分くらい」程度の粗い解釈で扱う - **サンプリングの偏り**: 「特定の送信元」「特定のキャンペーン」「特定の時間帯」に集中して適用されるケースがあり、業務影響を見極めづらい - **受信側ごとの差異**: ある受信ドメインではpct=10で問題が出ないのに、別の受信ドメインではpct=10で誤判定が出るといった非対称が起きる このため、**「pctで段階的に上げているから安全」と過信せず、各ステップで必ずレポートと取引先からの実フィードバックを並行して観察する**ことが重要です。pctだけに頼った安全管理ではなく、送信側のSPF/DKIM整備とアラインメント確保が本丸で、pctはあくまで補助だと位置付けてください。中間値の挙動が気になる場合は、ステップを4段階より少なく（例: 10→100%の2段階）絞るのも実務的な選択肢です。 ### DMARCbisでpctが廃止｜t=yへの移行準備 DMARCの後継仕様「DMARCbis」（IETFのドラフト名: `draft-ietf-dmarc-dmarcbis`）の最新版（2025年7月公開、第41版）では、**pctタグは削除予定**です。受信側で精度が出ない実装上の問題と、運用現場で実質的にpct=0（テストモード）かpct=100（本番）の二択でしか使われていない実態を踏まえての変更です（[draft-ietf-dmarc-dmarcbis](https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/)）。 代わりに導入されるのが`t`タグ（testing flag）で、二択のフラグになります。 - `t=y`: テストモード。pct=0と同等で、ポリシーは適用されずレポートだけ生成される - `t=n`（デフォルト）: 本番モード。pct=100と同等で、`p`タグの値どおりに適用される ![DMARCbisでのpct→t移行](/blog/dmarc-pct-rollout/dmarcbis-migration.svg) DMARCbisは2026年初頭にProposed Standardとして公開される見通しで、3つの関連ドキュメント（本体・集計レポート・失敗レポート）はRFC Editor Queueに入っています。**既存のpct付きレコードは廃止後も無視される形で動き続ける**ため、緊急の書き換えは不要です。ただし新規に書き始める場合や、運用が落ち着いたタイミングでpctを取り除いておくのが将来のメンテナンス負担を減らす意味で安全です。 DMARCレコードに書く全11タグの一覧と各タグの役割は、[DMARCレコードのタグ完全リファレンス](/blog/dmarc-record-tags-reference)に整理しています。pctだけでなくrf・riもDMARCbisで廃止予定のため、補助タグの整理は先回りで進めておくと負担が軽くなります。 ## まとめ 要点をおさらいします。 - pctタグは「DMARC失敗メールのうち何%にポリシーを適用するか」を指定する安全弁。10→25→50→100%の4段階で各1〜2週間観察するのが扱いやすい刻み - 各ステップは「進む・止まる・戻す」をレポートと取引先フィードバックで判断する。戻すことは失敗ではなく正常な運用 - pctは受信側の実装ばらつきがあり、中間値の精度には限界がある。SPF/DKIMの整備とアラインメント確保が本丸 - DMARCbisでpctは廃止予定で、`t=y`/`t=n`の二択フラグに置き換わる。新規・更新時はpctを書かない方針が将来安全 pctのロールアウト中は「自社の送信経路を把握しきれているか」が問われます。把握できていないSaaSやサブシステムが1つでも残っていると、ロールアウトの途中で配送事故が起きやすくなります。 [ドメイン番人の無料診断](/diagnose)では、ドメインを入力するだけでDMARC・SPF・DKIMの設定状況とアラインメントの整合性をその場で確認できます。pct値を上げる前のチェックや、戻す判断材料にもご活用ください。設定状況がわからない場合や、ロールアウトの途中で迷った場合は、お気軽にご相談ください。専門家がわかりやすくサポートいたします。