
## この記事でわかること

- p=noneからp=quarantineへ進むときに、必ず確認すべき3つの観察ポイント
- pctタグで「10%→50%→100%」と段階的に強化していく具体的な進め方
- p=rejectへの移行判断と、サブドメインのspタグの考え方

## p=noneのままでは「なりすまし」を防げない

DMARC（ディーマーク）を設定すると、最初は`p=none`（ポリシー: なし）から始めるのが定石です。`p=none`は受信側に「認証に失敗してもブロックしないでください、ただしレポートは送ってください」と指示する設定で、まずは正規のメール経路を全部洗い出すための「監視モード」として使います。

ただし`p=none`のままでは、**自社ドメインを名乗るなりすましメールがそのまま受信者に届いてしまう**状態が続きます。Gmail宛てに1日5,000通以上送る一括送信者にはDMARCの設定そのものが2024年2月から必須化されており、Microsoft Outlookも2025年5月から同等の要件を適用しています。詳しくは[DMARC義務化はいつから？対応手順をWeb 担当者向けに解説](/blog/dmarc-mandatory)で整理しています。

なりすまし対策としてDMARCを実効化するには、`p=none`の次に**`p=quarantine`（迷惑メールフォルダへ振り分け）→ `p=reject`（受信拒否）**と段階的にポリシーを強化していく必要があります。本記事では、その移行手順をIT担当者不在の中小企業でも安全に進められるように整理します。

DMARCそのものの概念や初期設定は、先に[DMARC とは？仕組みと中小企業が今すぐやるべき対応を 5 分でわかる入門](/blog/what-is-dmarc)と[DMARC設定方法を徹底解説](/blog/dmarc-setup-guide)をご確認ください。

![DMARCポリシーは段階的に強化する](/blog/dmarc-policy-tightening/policy-rollout-stages.svg)

## 強化前に必ず確認する3つのこと

p=quarantineに進む前に、`p=none`で運用しているDMARC集計レポート（rua）を最低でも2〜4週間は観察してください。Google公式のロールアウト推奨でも、複数の送信経路を持つ組織ほど監視期間を長めに取ることが推奨されています。レポートの読み方は[DMARCレポートの見方｜集計XMLを読み解く](/blog/dmarc-report-reading)で解説しています。

観察期間で確認したいのは次の3点です。

### 1. 自社が把握していない送信元が混ざっていないか

レポートのなかで認証に失敗しているIPアドレスが、すべて「自社の認知している送信経路」から出ているかを照合します。よくある見落としは次のような経路です。

- 会計システム・予約システムから届く自動通知メール
- マーケティング配信ツール（メール配信SaaS）
- 旧契約の請求書送信サービス、退職者用に残っている古いSMTPサーバー
- 海外子会社・委託先のメールサーバー

ここを把握しきらないままp=quarantineに上げると、**取引先や顧客に届くべき正規メールが迷惑メールに振り分けられる**事故につながります。

### 2. SPFとDKIMがそれぞれ十分にパスしているか

DMARCは「SPFかDKIMのどちらか1つでもパスしていれば認証成功」と判定する仕組みですが、**両方とも失敗しているメール**がレポートに多く出ている場合は強化を急ぐべきではありません。

理想形は、主要な送信経路すべてで**SPFとDKIMの両方がパスしている**状態です。SPFだけがパスしていてDKIMが未設定の経路は、メールが転送（フォワード）されるとSPFも壊れてDMARC失敗になりがちなので、優先的にDKIMを追加することをおすすめします。

DKIMの確認手順は[DKIM設定の確認方法｜署名が効いているかチェック](/blog/dkim-verification)に整理しています。

### 3. 認証「アラインメント」が取れているか

DMARCは「SPF/DKIMがパスしているだけ」では足りず、**Fromアドレスのドメインと、SPF/DKIMで認証されたドメインが一致（アラインメント）している**必要があります。

例えばマーケティング配信ツールが`mail.example.com`のSPFでパスしていても、Fromが`example.com`で配信ツール側がDKIMを署名していない場合、DMARC的には失敗扱いです。レポート内の`<auth_results>`と`<identifiers>`の組み合わせをチェックして、Fromドメインとアラインメントが取れているか確認します。

## p=quarantineへの段階的移行手順

3つの確認が済んだら、いよいよp=quarantineに進みます。**いきなり100%適用せず、`pct`タグで割合を区切って上げていく**のが基本です。

![pctタグによる段階的ロールアウトのイメージ](/blog/dmarc-policy-tightening/pct-rollout.svg)

### ステップ1: pct=10で開始

DNSのDMARCレコードを次のように更新します。`rua`は実際に運用しているレポート受信アドレスに置き換えてください。

```
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@example.com; sp=none; adkim=r; aspf=r
```

`pct=10`は「DMARCに失敗したメールのうち10%にp=quarantineを適用し、残り90%はp=noneとして扱う」という意味です。万一見落としていた送信経路があっても、影響範囲を10%に抑えられます。

この段階で1〜2週間運用し、毎週レポートを確認します。**「自社の正規メールがquarantine扱いになっていないか」を確認するのが目的**で、IPやドメインを精査して問題がなさそうであれば次のステップへ進みます。

### ステップ2: pct=50に引き上げ

```
v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc@example.com; sp=none; adkim=r; aspf=r
```

ここでもう一度1〜2週間の観察。`pct`の数値変更はDNSのTXTレコード値を書き換えるだけで反映されますが、TTL（DNSキャッシュ保持時間）の関係で受信側全体に行き渡るまで最大数時間かかる点だけ注意してください。

### ステップ3: pctを外す（pct=100相当）

問題がなければpctを取り除いて、p=quarantineを全件に適用します。

```
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; sp=none; adkim=r; aspf=r
```

`pct`を省略した場合のデフォルトは100%なので、上記が「全件にquarantineを適用する」設定です。

### pctタグの注意点（受信側で挙動が違う）

ここで知っておくべき重要な制約があります。`pct`の中間値（`pct=10`や`pct=50`など）は、**受信側のメールプロバイダによって解釈や厳密さが異なる**ことが知られています。`pct=0`（テストモード相当）と`pct=100`（全件適用）は確実ですが、中間値は「正確に10%を抜き出す」処理ではなく、各受信プロバイダが独自の確率的判定をしている実装が多く見られます。

加えて、現在策定中のDMARCの後継仕様「DMARCbis」の最新ドラフト（`draft-ietf-dmarc-dmarcbis-41`、2025年7月22日公開）では`pct`タグを廃止し、`t=y`（テストモード）／`t=n`（本番モード）という二択フラグに置き換える方向で議論が進んでいます。

つまりpctはあくまで**「100%適用への最終確認のためのセーフティネット」**として使うのが適切で、「ここまでは確実にブロックされる」という保証として頼り切らない方が安全です。

## p=rejectへの移行判断と進め方

p=quarantineを100%で1ヶ月以上運用し、レポート上で正規メールが安定してパスしている状態が続いたら、次は`p=reject`への移行を検討します。

### p=quarantineとp=rejectの違い

- **p=quarantine**: 認証失敗メールを迷惑メールフォルダへ振り分ける（受信側のフォルダには届く）
- **p=reject**: 認証失敗メールをSMTP接続の段階で拒否する（受信側にそもそも届かない）

p=rejectが厳しいのは、**受信者が迷惑メールフォルダから救出することすらできない**点です。誤検知が起きるとそのメールは完全に「届かなかった」状態になります。なりすまし対策としては最も強力ですが、その分だけ慎重に進める必要があります。

### p=rejectへの移行も段階的に

p=quarantineからの移行も、同じくpctで割合を区切って進めるのがセオリーです。

```
1〜2週目: v=DMARC1; p=reject; pct=10; ...
3〜4週目: v=DMARC1; p=reject; pct=50; ...
5週目以降: v=DMARC1; p=reject; ...   ← pctを外して100%
```

ここでDMARCの仕様上、興味深いふるまいがあります。`p=reject; pct=10`の場合、DMARCに失敗したメールのうち**10%は拒否（reject）、残り90%は隔離（quarantine）として扱う**のがRFC 7489の定めです（`p=none`への降格ではありません）。つまりp=quarantineを100%で運用済みのドメインがp=reject; pct=10に進めても、保護レベルが下がることはありません。

p=rejectまで進めれば、なりすましメールはほぼ確実にブロックされ、ブランド毀損や顧客被害のリスクを大きく下げられます。

## サブドメインのポリシーとspタグ

最後に見落としがちなのが、**サブドメインのDMARCポリシー**です。

### spタグの役割

DMARCレコードの`sp`タグは、組織ドメインの「サブドメイン用ポリシー」を指定します。`sp`が省略されていると、受信側はサブドメインに対して`p`タグの値をそのまま継承します。

![spタグによるサブドメインポリシーの継承](/blog/dmarc-policy-tightening/subdomain-policy.svg)

例えば`example.com`に`p=reject`を設定し、`sp`を省略すると、`mail.example.com`や`info.example.com`などすべてのサブドメインも`p=reject`扱いになります。

### サブドメインを使い分けるならsp=を明示する

会社によっては、本体ドメインは`reject`にしたいが、マーケティング配信用に切ったサブドメインは試行段階で`quarantine`に留めたい、というケースがあります。その場合は`sp`タグで明示的に切り分けます。

```
v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@example.com; ...
```

逆に、利用していないサブドメインがある場合は、なりすましの起点に使われないよう本体と同じ`reject`相当に揃えておくのがおすすめです。サブドメイン側に独自のDMARCレコードを別途公開すると、そちらの設定が親ドメインの`sp`より優先されるので、必要な単位で個別に上書きできます。

## まとめ

- DMARCは**`p=none`→`p=quarantine`→`p=reject`の3段階**で強化する。各段階で2〜4週間の観察を挟み、自社の送信経路がすべてレポート上でパスしていることを確認してから次へ進む
- 段階的移行には**`pct`タグで10%→50%→100%と割合を上げる**手法が基本だが、中間値の解釈は受信側ごとに揺れがあるため最終確認のセーフティネットとして使う
- サブドメインのポリシーは**`sp`タグ**で明示的に制御する。省略時は親の`p`タグを継承する点を踏まえ、用途別にサブドメインを使い分ける場合は`sp`を必ず指定する

なお、強化を急がせる外的要因として [Google 送信者ガイドライン 2024](/blog/google-sender-requirements-2024) と [Microsoft DMARC 必須化 2025](/blog/microsoft-dmarc-mandatory-2025) があります。

## 強化フェーズで効くツールセット

段階強化を進めるうえで、レポート可視化ツールの選定は早めに決めておくと運用が楽になります。SaaS と OSS を含む主要 7 製品の比較は [DMARC レポート解析ツール おすすめ 7 選](/blog/dmarc-report-tool-comparison)、現在の DMARC / SPF レコードの中身を日本語で逐語解説してほしい場合は無料の [SPF / DKIM / DMARC 設定確認ツール](/tools/dns-auth-explainer) をご利用ください。

## 自社のDMARC設定を無料で診断します

「うちのDMARCは今`p=none`のままだけど、強化に進めても大丈夫？」「pctタグの数値を上げていいか判断がつかない」——そんな方のために、ドメイン番人ではDMARC・SPF・DKIMの設定状況を無料で診断する[ドメイン診断ツール](/diagnose)をご用意しています。

レポート上で気になる失敗が見つかったときの判断や、強化を進める段階の伴走は、専門家が手作業で確認する有償プランでもサポートしています。まずは無料診断で、いまの設定が次のステップに進める状態かどうかを確認してみてください。
