DMARC p=reject 移行前チェック 7 項目

この記事でわかること

• DMARC を p=quarantine から p=reject に上げる直前に確認すべき 7 項目
• 各項目の優先順位と、抜けた場合に発生しやすい事故
• p=reject 適用後に問題が発生した場合の切り戻し判断フロー

p=reject 移行は「直前 7 項目」で事故が決まる

DMARC（ディーマーク）の段階強化（p=none → p=quarantine → p=reject）の全体像はDMARC ポリシーの段階強化で扱っています。本記事はその最終段である p=quarantine から p=reject に上げる直前の最終チェックに絞った内容です。

p=reject は「認証に失敗したメールを受信側に拒否させる」設定です。なりすまし対策としては最も強力ですが、自社の正規メールの設定漏れが残ったまま上げると、取引先に届くべきメールまで一律拒否される事故につながります。

事前観察を 2〜3 か月続けてきた企業でも、直前のチェックが甘いと当日に問題が表面化します。次の 7 項目を順に確認してください。

7 項目チェックリスト（優先順位順）

1. rua レポートで認証 fail 率がほぼ 0% である

最重要項目です。直近 2〜4 週間の rua（集計レポート）で、自社の正規送信元についての DMARC 認証 pass 率が 99% 以上になっていることを確認します。

確認方法はシンプルで、可視化ツールに rua を流し込み「自社が把握している送信元 IP / SaaS の合計通数のうち、policy_evaluated で dkim=pass または spf=pass かつ DMARC が pass になっている割合」を出します。読み方はDMARC レポートの見方とDMARC 集計レポートの読み方で詳しく解説しています。

fail が残っている場合は、まずその原因を解消してから次に進みます。DMARC fail のトラブルシューティングも併読してください。

2. Subdomain Policy（sp=）の設定が済んでいる

DMARC レコードに sp= を書かないと、親ドメインの p= がサブドメインにも継承されます。p=reject に上げた瞬間、すべてのサブドメインから送るメールが、設定漏れがあれば一律拒否されます。

サブドメインで独立してメールを送っている SaaS（マーケティング・請求書・通知系）がある場合は、先に sp=quarantine で観察期間を置き、安全を確認してから親と一緒に reject に上げます。設定パターンはDMARC の sp タグ（subdomain policy）の使い方を参照してください。

3. 主要 SaaS（MA・請求書・勤怠等）の SPF / DKIM 確認

部署が個別契約した SaaS は情シスの把握から漏れがちです。rua レポートの送信元 IP を WHOIS や逆引きで一覧化し、各 SaaS の管理画面で SPF と DKIM の設定が完了しているかを横並びで確認します。

特に新しく契約した SaaS は、初期設定で SPF の include: 追加を忘れているケースが多いです。SaaS ごとの確認手順は提供元のドキュメントが正です。

4. DKIM 鍵長が 2048 bit 以上である

1024 bit の DKIM 鍵は、計算機性能の向上に伴い段階的に廃止が進んでいます。p=reject で運用する以上、DKIM の検証強度は重要な指標です。

主要メールサービスの管理画面で鍵長を確認し、1024 bit の場合は 2048 bit へのローテーションを実施してから移行します。手順はDKIM の検証方法と鍵ローテーションを参照してください。

5. Authentication-Results ヘッダで DMARC=pass を確認

自分の Gmail / 個人アカウントへ社内メール・自動通知・SaaS 経由のメールを実際に送り、受信側で「メッセージのソースを表示」を開いて Authentication-Results ヘッダーを目視確認します。

dmarc=pass になっていれば本番でも同様に通ります。dmarc=fail がある場合は、その原因系統（SPF か DKIM か、アラインメントか）を特定するまで p=reject には上げません。

6. 内部メール・転送経路の影響範囲を把握

社員が自宅メールや個人 Gmail に自動転送設定している場合、転送経路で SPF が壊れて DMARC fail になります。ARC（Authenticated Received Chain）をサポートするプロバイダ間なら救済されますが、対応していない経路では拒否されます。

メーリングリスト（社外向けの ML、団体や業界 ML への投稿）も同様にヘッダーが書き換えられて fail することがあります。社内アンケートで「自動転送・外部 ML への投稿の有無」を事前に集めると、影響範囲が見えやすくなります。SPF / DKIM / DMARC の関係整理はSPF・DKIM・DMARC の違いを参照してください。

7. 切り戻し手順を事前準備（DNS TTL 短縮 + 旧値保管）

移行当日は、DMARC レコードの TTL を 300 秒（5 分）程度に短縮し、旧 p=quarantine の値もテキストで保管しておきます。

問題が発生した場合は、DNS 管理画面で p=quarantine に書き戻すだけで 5 分程度で切り戻せる体制を作っておきます。情シス担当者の連絡先・休日対応の段取りも合わせて文書化してください。

p=reject 適用後の判断フロー

適用後は 24〜72 時間のモニタリングを行い、問題が出た場合に冷静に判断するためのフローを準備します。

判断基準のポイントは次のとおりです。

• 「配信問題が出たら即切り戻し」ではない。原因が SPF の include 漏れなど 5 分で直せる種類なら、reject を維持したまま forward fix する
• 原因特定に時間がかかる場合は迷わず p=quarantine に戻す。reject 維持にこだわって取引先メールを止めるよりも、一旦戻して原因究明することが事業継続上は正しい
• 戻した後は必ず根本原因を解消してから再度上げる。「同じ問題が再発する」状態で何度も切り戻しを繰り返すと、社内の DMARC 運用への信頼が損なわれます

姉妹記事としてDMARC 認証失敗のトラブルシュート手順を併読すると、切り戻し後の原因究明がスムーズになります。

よくある質問

pct=100 にしてから reject に上げるべきですか

はい、必ず pct=100 で十分な観察期間を取ってから reject に上げてください。pct を下げたままだと、reject の影響を限定的にしか観測できず、本番影響が読めません。

観察期間はどれくらい必要ですか

最低 2 か月、可能なら 3 か月以上の pct=100 運用を推奨します。月次・四半期での特殊な送信パターン（請求書・年末年始の挨拶メール一括送信など）が観察期間に含まれていることを確認してください。

切り戻し後にすぐ reject に戻していいですか

原因を解消した上で、解消したことを rua レポートで 1〜2 週間確認してから再度上げます。「直したつもり」で戻すと同じ事故を繰り返します。

まとめ

• 7 項目を優先順位順に確認。1〜2 番は必須、3〜7 番は順次対応
• sp= の設定漏れと SaaS の SPF/DKIM 漏れが事故の二大要因
• DNS TTL を短縮し、切り戻し手順を文書化してから移行当日を迎える
• 適用後は 24〜72 時間モニタリング。問題が出たら 5 分で戻せる体制で挑む

移行判断に不安がある場合

rua レポートの読み込みや SaaS の棚卸しに時間がかかる、p=reject 移行の判断材料が揃っているか不安、といった場合はドメイン番人の無料診断で現状を可視化できます。移行計画の整理や直前確認の伴走が必要な場合は、お問い合わせフォームからご相談ください。事前に内容をご確認いただいた上で進めますので、安心してお任せいただけます。