DMARC強制ポリシーとは？p=none・quarantine・rejectの違いと段階的な移行方法

DMARC強制ポリシーとは

DMARC強制ポリシーとは、DMARC レコードの p タグを quarantine（隔離）または reject（拒否）にして、なりすましの疑いが強いメールの配送を受信側で抑止させる設定のことです。

_dmarc.city.example.lg.jp.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-rua@city.example.lg.jp"

DMARC レコードの p タグは、SPF・DKIM による認証に失敗し、From ヘッダーのドメインとも一致しなかったメール（＝なりすましの疑いが強いメール）を、受信側にどう扱ってほしいかを示します。

p=none は導入初期の監視段階としては正しい設定ですが、そのままでは偽メールが受信箱に届くことを止められません。この診断項目は、DMARC レコードが実際になりすましメールの配送を抑止する「強制ポリシー」（quarantine または reject）になっているかを確認します。RFC 9989 3.2.9節も、ポリシーが p=none でない状態を Enforcement（強制）と定義しています。

DMARC レコードがそもそも正しく公開されているかは「DMARCレコード」で確認します。このページは、公開済みの DMARC の方針の強さに絞って解説します。

DMARCポリシーはどう段階的に強化するのか

RFC 9989 の考え方

RFC 9989 5.1節は、ドメイン所有者は通常 p=none と rua で始め、集計レポートで自組織のメールの流れを監査し、正規なのに認証できていない送信元を直してから強制ポリシーへ進むと説明しています。集計レポートの受信先は「DMARC集計レポート送信先」で確認します。

政府機関等向けガイドラインの要件

政府機関等の対策基準策定のためのガイドライン（令和7年度版）基本対策事項 6.2.2(1)-3 は、DMARC ポリシーに p=quarantine または p=reject を設定することを求めています。解説は次の手順を示しています。

• メールを利用しないドメインは p=reject とする。
• 利用するドメインは p=quarantine とし、レポートで認証失敗が少ないことを確認してから p=reject にする。
• 設定はすべてのメールに有効とする。
• やむを得ず p=none とする場合も、1年以内に quarantine または reject にすることが望ましい。

メーリングリストと p=reject の注意（RFC 9989 7.4節）

一方、RFC 9989 7.4節は、利用者がメーリングリストへ投稿し得る一般的なメール用ドメインは p=reject を公開すべきでない（SHOULD NOT）とし、公開する場合は p=none を1か月以上、続いて p=quarantine を同程度の期間運用して影響を比べること、SPF だけに頼らず有効な DKIM 署名を付けること（MUST）を求めています。職員が日常のメールに使うドメインでは quarantine を当面の到達点とし、reject は影響を確かめてから判断するのが安全です。

テストモード（t=y）と旧仕様の pct

• RFC 9989 の t=y は、受信側に方針を1段階弱めて適用するよう求めます。p=quarantine; t=y は実質 none、p=reject; t=y は実質 quarantine になります。
• 旧仕様 RFC 7489 の pct は、方針を適用するメールの割合（既定100）を示しました。選ばれなかったメールには1段階弱い方針が適用されるため、p=quarantine; pct=0 は実質 none、p=reject; pct=0 は実質 quarantine です。
• RFC 9989 は pct を廃止し（付録 A.6）、t=y を pct=0、t=n を pct=100 に相当するものとしました。未知のタグは無視されるため、新仕様の受信側は pct を読まず、旧仕様のままの受信側は t を読みません。受信側によって扱いが割れる点に注意が必要です。

サブドメイン方針（sp・np）

sp は既存サブドメイン、np は存在しないサブドメインへの方針です。sp を省略すると p が、np を省略すると sp（なければ p）が適用されます。p=reject; sp=none のように書くと、本体は守られてもサブドメインを名乗る偽メール（例：info.city.example.lg.jp）は素通りします。

DMARC強制ポリシーについてよくある誤解

• 「p=none でも DMARC 対応済み」：受信側要件（Google の大量送信者要件など）を満たすという意味では正しいものの、なりすまし抑止の効果はありません。
• 「reject にすると自分のメールも拒否される」：正規の送信元がすべて SPF/DKIM でアラインしていれば影響しません。影響が出るのは、未設定の送信元が残っている場合です。
• 「quarantine と reject の差は小さい」：quarantine では偽メールが迷惑メールフォルダに届き、利用者が開いてしまう余地が残ります。メールを送らないドメインは reject が適切です。なお RFC 9989 は受信側に、p=reject だけを理由に拒否せず他の分析と合わせて判断するよう求めています。

DMARC強制ポリシーの診断基準（セキュリティAIチェッカー）

取得対象と方法

• 「DMARCレコード」と同じく、メールドメイン（最終URLのホスト名から先頭の www. を除いたもの）の _dmarc TXT を Google Public DNS（DNS over HTTPS）で取得します。
• 有効な p（none / quarantine / reject）または mailto: の rua を持つ適用レコード（メールドメイン自身の1件、なければツリーウォークで見つけた親ドメインの1件）がある場合に評価します。親ドメインをたどるのは MX がある場合だけです。MX がなく dns.dmarc が対象外でも、メールドメイン自身に有効なレコードが1件あれば本項目は判定されます。
• レコードを ; で区切ってタグ単位で読み、p の値（大文字小文字は区別しない）と、t=y・pct=0 の有無を確認します。親ドメインのレコードを適用する場合は、有効な sp があれば sp を、なければ p を評価します（RFC 9989 4.10.1節）。

判定条件

DMARC 自体の有無は dns.dmarc（重み3、未設定は「× 要改善」）で評価しているため、ここでは二重に減点しないよう対象外とします。この項目に「× 要改善（fail）」はありません。

自治体ドメインでの判定例

p=reject; t=y や p=reject; pct=0 は、実質 quarantine として「○ 問題なし」になります。

診断の限界

• メールドメイン自身のレコードでは sp / np を評価しません。p=reject; sp=none も「○ 問題なし」になるため、サブドメインからメールを送らない場合は sp=reject を設定しているか手動で確認してください。
• pct が 1〜99 の場合は「○ 問題なし」としています。RFC 9989 で廃止された中間値は受信側によって扱いが異なり、政府機関向けガイドラインも「すべてのメールに有効」とすることを求めているため、pct は削除してください。
• 実際の受信側がどう処理したかは集計レポートでしか分かりません。
• 受信側は DMARC の方針を「要望」として扱い、最終的な処理は各メールサービスの判断に委ねられます。「○ 問題なし」でも偽メールが一切届かないことを保証するものではありません。

DMARCポリシーがp=noneのままだとどんなリスクがあるか

• 偽メールが受信箱に届く：p=none では、受信側は DMARC 失敗メールを特別扱いしません。自治体名を名乗る給付金・税還付・選挙・災害支援を装ったフィッシングが、住民の受信箱にそのまま届く可能性があります。
• 住民の被害と信頼低下：偽サイトで個人情報やカード情報を入力させられる被害が発生すると、問い合わせ対応・注意喚起・報道対応などの負担が生じます。
• 注意喚起の限界：「当市からのメールを装った不審なメールにご注意ください」という告知は事後的な対策で、届いてしまった偽メールの開封を完全には防げません。受信段階で隔離・拒否される状態にしておくことが根本的な対策です。
• サブドメインの抜け穴：sp=none や存在しないサブドメインを使った偽装は、本体を reject にしても防げません。

DMARC強制ポリシーへの移行方法（p=none → quarantine → reject）

1. 監視（p=none）から始める

_dmarc.city.example.lg.jp.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-rua@city.example.lg.jp"

集計レポートで、送信元IPごとの SPF/DKIM/DMARC 結果を確認し、正規なのに fail している送信元（委託システム、配信サービス、複合機など）の SPF 追加や DKIM 署名を進めます。

2. quarantine へ移行する

; まずテストモードで影響を確認（RFC 9989 準拠の受信側は none として扱う）
_dmarc.city.example.lg.jp.  IN  TXT  "v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc-rua@city.example.lg.jp"
; 問題なければ t=y を外す
_dmarc.city.example.lg.jp.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-rua@city.example.lg.jp"

3. reject へ移行する

_dmarc.city.example.lg.jp.  IN  TXT  "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc-rua@city.example.lg.jp"

メールを送らない Web 専用ドメインやサブドメインは、最初から p=reject で構いません。職員が日常的に使うドメインは、前述の RFC 9989 7.4節の注意を踏まえて reject への移行を判断します。

4. 移行判断の目安

• 集計レポート上、正規送信元からのメールが SPF または DKIM でアラインして pass している。
• 新しいシステムを導入する際の「送信ドメイン認証の設定」が調達仕様・運用手順に組み込まれている。
• 問い合わせ窓口に「届かない」という苦情が出たときの切り戻し手順（p を一時的に戻す）が決まっている。

5. 移行スケジュールの例

政府機関向けガイドラインが示す「導入から1年以内に強化」を目安にしつつ、送信元の数や委託システムの状況に合わせて調整します。期間はあくまで例であり、レポートで正規メールの認証状況を確認できたことを移行の条件にしてください。

6. 確認方法

dig +short TXT _dmarc.city.example.lg.jp
# p タグだけを確認
dig +short TXT _dmarc.city.example.lg.jp | grep -oiE '(^|[; "])(s|n)?p=[a-z]+'

設定後はセキュリティAIチェッカーで再診断し、根拠欄に「quarantineまたはrejectです。」と表示されることを確かめてください。

メールを止めないための注意点

• DKIM 未設定の送信元が残ったまま reject にすると、その送信元からのメールが受信側で拒否されます。自動転送では SPF が失敗するため DKIM 署名が必須です。件名や本文を書き換えるメーリングリストでは DKIM も失敗し得るため、リスト側の対応（From の書き換えと再署名）を確認します。
• pct は RFC 9989 で廃止されたため、新規設定では使わず t=y で段階導入します。旧仕様の受信側は t=y を無視して p をそのまま適用するため、テスト中でも一部で隔離が始まる前提で進めます。
• 変更前に TTL を短くしておき、問題が出たら速やかに p=none へ戻せるようにします。
• 既存の _dmarc レコードは書き換えで更新し、2件目を追加しないでください（複数あると全部無視されます）。

よくある質問（FAQ）

参考資料

• RFC 9989 Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 7489（廃止済み、旧仕様・pct タグ）
• Google「メール送信者のガイドライン」
• 内閣官房国家サイバー統括室「政府機関等のサイバーセキュリティ対策のための統一基準群」（対策基準策定のためのガイドライン（令和7年度版））
• ScanNetSecurity「迷惑メール対策推進協議会『送信ドメイン認証技術 DMARC導入ガイドライン』公表」
• 経済産業省 報道発表（2023年2月1日）

「DMARC強制ポリシー」と関連する診断項目

• DMARCレコードhigh
• DMARC集計レポート送信先low
• SPFの終端ポリシーmedium
• SPFレコードmedium
• CAAレコードlow
• DNSSECmedium
• SPFの一意性・構文・DNS参照数high
• MTA-STSmedium