p= の 3 段階（ざっくり）
DMARC レコードの p= は、SPF / DKIM の認証に失敗したメールを
受信側にどう扱ってほしいかを示します。代表値は次のとおりです。
| 値 | 意味（受信側の目安） | ひとことで言うと |
|---|---|---|
p=none |
拒否・隔離しない（レポート収集が主目的） | 監視のみ — なりすましは止まらない |
p=quarantine |
迷惑メールフォルダ等へ隔離を推奨 | 疑わしい送信を届けにくくする |
p=reject |
受信拒否を推奨 | なりすましを最も強く抑止 |
DMARC がない場合のリスク説明のあと、
「レコードはあるが p=none のまま」という中間状態を理解するときの参考表です。
サンプル報告書では p=quarantine の例も示しています（
架空企業サンプル）。
なぜいきなり reject にしないか
正規の通知メール（請求 SaaS・採用 ATS・マーケツールなど）は、
SPF / DKIM のどちらかが御社ドメインと整合（アライメント）していないと、
DMARC 判定で「失敗」になります。
その状態で p=reject にすると、正規メールまで拒否されうるため、
多くの組織は段階的に強めます。
- 送信経路の洗い出し — 社内通知・顧客向け・委託ベンダーそれぞれがどのドメイン・サーバーから送るか
- SPF / DKIM の整合 — 各経路で認証が通るよう DNS を揃える（SPF だけでは足りない理由）
- p=none でレポート確認 — 失敗メールの内訳を把握（
rua=等） - quarantine → reject — 問題がなければ段階的に強化。一部は
pct=で割合を絞って試す
この作業の主体は、通常DNS 管理者・メール基盤ベンダー・御社 ITです。 外部攻撃面レビューは、その前後で第三者視点の DNS 事実を報告書にまとめる位置づけです。
サブドメインと sp=
代表ドメイン（example.co.jp）だけ DMARC を強くしても、
サブドメイン（mail.example.co.jp 等）が緩いままだと、
なりすましの抜け道になることがあります。
DMARC レコードの sp= はサブドメイン向けポリシー、
adkim= / aspf= はアライメントの厳しさに関わります。
詳細な設計値の決定は本記事の範囲外とし、
レビューでは公開 DNS に書かれている事実（有無・値・矛盾）を整理します。
外部から確認する内容（例）
| 観点 | 確認する内容（例） |
|---|---|
| ポリシー段階 | p= / sp= が none / quarantine / reject のどれか |
| レポート | rua=（集約レポート先）の有無 — 運用中かどうかの手がかり |
| SPF / DKIM との関係 | 正規送信に使うサービスが SPF include・DKIM セレクタに載っているか |
| 整合性 | 複数ドメイン・グループ会社ドメイン間で方針がバラバラでないか |
目的は「すぐ reject にしろ」ではなく、 今どの段階にいて、次に誰が何を揃えるべきかを 社内で共有しやすい形にまとめることです。
含まないこと（よくある誤解）
- DMARC レポートの受信・解析代行（標準外。必要なら別途ご相談）
- DNS 変更や M365 / Google 管理画面でのポリシー適用の代行
- 正規メールへの影響を見るための大量送信テスト
- 社内メールログのフォレンジック、ペンテスト（別契約）
調査データは閉域環境内で扱います
御社からお預かりした .eml や調査結果は当社事業所内の閉域環境でのみ保管・処理します。 公開 DNS への問い合わせは発生しますが、 御社データを当社クラウドや第三者 SaaS に載せる運用は行いません。 報告書は基本メールで納品し、調査画面のログインはお渡ししません。
シリーズの読み順（参考）
- 外部攻撃面とは何か — 全体像
- DMARC がないと何が起きうるか — リスクの説明
- SPF だけでは足りない理由 — 送信経路・SPF の穴
- 本記事 — ポリシー強化の意味と段階
御社ドメインの現状を事実ベースで整理する場合は お問い合わせください。 攻撃面 → 脆弱性診断 → 必要ならペンテストと、段階は契約ごとに異なります。