DMARCでp=rejectにするためのプロセス

DMARCでp=rejectにするためのプロセス

「見えていない送信元」を潰し込み、合意形成と予算取得を経て、安全にp=rejectへ到達する


著者: 竹洞 陽一郎

DMARCを最終的にp=rejectへ到達させることは、なりすまし（ドメインスプーフィング）対策として非常に有効です。
しかし、単にDMARCレコードをp=rejectに変更するだけでは、正規メールが弾かれて業務影響が出るリスクがあります。
本記事では、まず攻撃者がOSINTで標的を選定するという前提を確認し、p=rejectにする3つの目的を整理した上で、送信元の洗い出し→SPF/DKIMアライメントの整理→費用と移行要否の判定→ポリシーの引き上げという、実務で破綻しにくい進め方を紹介します。

まず念頭に置くこと：攻撃者はOSINTで標的を選定する

p=rejectを検討する際は、最初に攻撃者側の視点を念頭に置いてください。
攻撃者は、いきなり特定の企業を狙い撃ちするわけではありません。
OSINT（Open Source Intelligence：公開情報を用いた調査）によって多数の企業を機械的にプロファイリングし、労力に見合う標的を選び出します。

このとき攻撃者が見ているのは、外部から確認できる設定です。
主に以下の3つが調査対象になります。

DNS
SPF、DKIM、DMARCの各レコードの有無と内容、ネームサーバーの構成、サブドメインの列挙、DNSSECやCAAの設定状況などを確認します。
DMARCがp=noneのままであれば、そのドメインを騙ったメールは受信者に届くと判断されます。
参照先を失った放置レコードが見つかれば、サブドメインの乗っ取りという別の攻撃経路も検討されます。
Web
公開サイトのサーバー情報、使用しているソフトウェアとそのバージョン、TLSの設定、公開されたままの管理画面やディレクトリなどを確認します。
古いバージョンのまま運用されていれば、既知の脆弱性を突く攻撃の候補になります。
メール
MXレコードの構成、SMTPバナーから読み取れるMTAの種別とバージョン、STARTTLSへの対応、MTA-STSやTLS-RPTの設定状況などを確認します。
オープンリレーの有無や、認証を経ずに送信できる経路が残っていないかも調査対象です。

これら3つがいずれもきちんと設定されていれば、攻撃者は「面倒な会社」と判断し、より手薄な別の標的へ移ります。
攻撃者も費用対効果で動いているため、防御が固いことが外部から見て分かる状態そのものが、抑止力として機能します。
DMARCのp=rejectは、このうちDNSとメールの項目において、最も分かりやすい防御シグナルを出す手段です。

p=rejectにする3つの目的

以上を踏まえると、p=rejectを目指す目的は以下の3つに整理できます。
この3つを明確にしておくと、社内での合意形成や予算取得の際に、投資対効果を説明しやすくなります。

目的1：なりすましメールが届かないようにする
p=rejectを設定すると、DMARCに合格しないメールは、原則として受信側で拒否されます。
拒否はSMTPのDATAコマンド完了後に5xxエラーを返す形で行われるため、受信者の迷惑メールフォルダにすら入りません。
自社ドメインを騙ったフィッシングメールやビジネスメール詐欺（BEC）が、取引先やお客様に届かない状態を作ることが、最も基本的な目的です。
なお、受信側がポリシーを上書きする場合があります。詳細は次項で説明します。
目的2：なりすましメールが届かないことを攻撃者に明示する
攻撃者がOSINTで調べるDNSの項目のうち、DMARCレコードは誰でも参照できる公開情報です。
p=rejectを掲げること自体が、「このドメインを騙っても受信者には届かない」という明示的なシグナルになります。
攻撃者は効率を重視するため、成果の出ないドメインを攻撃対象から外します。
弊社の分析では、p=rejectへ移行したドメインは、2〜3週間程度で、DMARCレポートで観測された全メッセージ数に占めるなりすましメールの割合が、軒並み0〜1%まで低下しています。
一方、p=quarantineでは、なりすましメールが減らないことも同じ分析から判明しています。
目的3：BIMIで商標登録したシンボルマークを表示する
BIMI（Brand Indicators for Message Identification）は、DMARCポリシーがEnforcementの状態、すなわちp=quarantineまたはp=rejectであることを前提条件としています。
Enforcementとは、組織ドメインとその配下の全サブドメインのポリシーがp=noneではない状態を指し、RFC 9989 §3.2.9で定義されています。
p=rejectへ到達することで、商標登録済みのシンボルマークをVMC（Verified Mark Certificate／認証マーク証明書）で認証し、受信者のメールクライアントに表示できるようになります。
これは、DMARCだけでは防げない攻撃への対抗策になります。
攻撃者が全く無関係のドメインを使い、そのドメインでSPF/DKIM/DMARCを合格させた上で、表示名（ヘッダーFromの名前部分）だけを自社に見せかける手口です。
RFC 9989は§2.2および§2.4で、表示名の詐称をDMARCの対象外と明記しています。
正規メールにシンボルマークが表示される状態が定着すれば、マークのないメールを受信者が識別しやすくなり、なりすましメールの送信は更に困難になります。

p=rejectでも必ず拒否されるわけではない

RFC 9989 §5.4は、受信側がrejectというポリシーの公開だけを理由にメッセージを拒否すべきではない（SHOULD NOT）と規定しています。
さらに§8では、DMARCに完全に参加する受信側の要件として、Author Domainのp=rejectというポリシーだけを根拠にメッセージを拒否してはならない（MUST NOT）と、より強い言葉で規定されています。
DMARCでは表現できない経路で送られた正規メールの拒否や、メーリングリストの運用障害を避けるためです。
実際のDMARCレポートでも、ポリシーが上書きされた場合はその理由が記録され、local_policyやarc=passといった値が現れます。

ただし、この規定が禁じているのは、p=rejectであることを唯一の根拠にすることです。
他の判断材料と組み合わせて拒否することまでは、妨げられていません。

実際に上書きが行われるのは、そのメールが転送されたものであると受信側が確認できた場合に限られます。
具体的には、ARC（Authenticated Received Chain、RFC 8617）のヘッダーが付与されている場合や、転送前の認証結果を伝えるX-Original-Authentication-Resultsヘッダーが付与されている場合です。
それ以外のDMARC不合格メールは、基本的に排除されます。

攻撃者が送るなりすましメールに、正規の転送であることを示すこれらのヘッダーが付くことはありません。
したがって、この上書き規定によってなりすましメールが受信者に届くことは、実務上ほとんどありません。

ゴール：p=rejectにできる状態とは

DMARCは「SPF（RFC 7208）またはDKIM（RFC 6376）のいずれかが認証に成功し、かつアライメント（識別子の整合性）が満たされる」場合に合格となります（RFC 9989 §4.4）。
アライメントには、組織ドメインが一致すれば合格とするrelaxedと、ドメインの完全一致を求めるstrictの2種類があり、どちらを要求するかはドメイン所有者がDMARCレコードで指定します。
したがってp=rejectへ進むには、少なくとも全ての正規送信について、 SPFアライメントまたはDKIMアライメントが安定して合格する状態を作る必要があります。
ただし、これはあくまで最低条件です。実際に目指すべき水準は後述します。

よくある躓きポイント：最初から全体費用が出せない

多くの組織では、メール送信が「情シスのMTA」だけではなく、外部のメール配信サービス、SaaS、業務委託先、拠点システムなどに分散しています。
この状態では、最初から「取り組み全体の費用」を精密に出すことが難しく、予算化が止まりがちです。
そこで本記事では、最小コストで全体像を把握し、第二フェーズの予算を合理的に積み上げるためのプロセスを採用します。

目標水準：SPFとDKIMの双方のアライメント一致

第一フェーズに入る前に、各送信元をどの水準まで持っていくべきかを確認しておきます。
結論として、目指すべきはSPFとDKIMの双方でアライメントを一致させることです。

DMARCの合格条件と、DMARCへの参加要件は別

DMARCの合格判定そのものは、SPFアライメントとDKIMアライメントのいずれか一方が成立すれば合格となります（RFC 9989 §4.4）。
この点だけを見ると、どちらか片方に対応すれば十分に思えます。

しかしRFC 9989は、DMARCへの参加という観点では、より強い水準を求めています。
§5.1では、ドメイン所有者はAuthor Domainとアライメントする認証済み識別子を「少なくとも1つ、望ましくは2つ」生成するメールを送信するものとされています。
§4.5では、ドメイン所有者がDKIMとSPFの双方を基盤の認証メカニズムとして使用することが、RECOMMENDED（推奨）と明記されています。
§5.1.1および§5.1.2では、SPFをDMARC向けに構成する場合、DKIMをDMARC向けに構成する場合のそれぞれについて、Author Domainとアライメントする識別子を生成しなければならない（MUST）と規定されています。

さらに§8「Conformance Requirements for Full DMARC Participation」では、DMARCに完全に参加するための要件が、初めて規範的な言葉で列挙されました。
ドメイン所有者に対する要件は、以下の5項目です。

SPFとDKIMの双方について、アライメントする識別子を生成することが、条件を付けないMUSTとして並んでいる点に注意してください。
加えて、p=rejectのドメインではSPF単独への依存が明確に禁じられています。
つまり、p=rejectを目指す本記事の文脈では、DKIMアライメントの一致は選択肢ではなく必須要件です。

実務上も、片方だけでは破綻する

規格上の要件を別にしても、片方だけの対応は運用上のリスクを抱えます。

SPFのみに依存する場合
SPFは送信経路に依存するため、転送やメーリングリストを経由すると成立しません。
また、SPFレコードの評価におけるDNSルックアップ回数には10回という上限があり（RFC 7208 §4.6.4）、送信元が増えるとPermErrorで破綻します。
そしてp=rejectを目指す以上、SPF単独への依存はRFC 9989 §8が明確に禁じています。
DKIMのみに依存する場合
DKIMは経路に依存しないため転送には強い一方、メーリングリストが件名やフッターを書き換えると署名が壊れます。
鍵のローテーション漏れや、送信システム側の署名設定の不備によって、突然合格しなくなることもあります。

双方のアライメントを一致させておけば、いずれか一方が壊れても、もう一方でDMARCに合格します。
したがって第一フェーズの送信元一覧では、各送信元についてSPFアライメントとDKIMアライメントの両方の可否を記録してください。
次に述べる送信元の4分類も、「双方の一致が可能か」という基準で判定します。

第一フェーズ：送信元の洗い出しと分類（合意形成のための整理）

第一フェーズの目的は、技術実装を進めることではなく、どこからメールが送られているかと、どの程度の対応が必要かを明確にして、予算取得に必要な材料を揃えることです。
進め方として、月1回の分析ミーティングを2回開催し、PowerDMARCの分析結果をもとに送信元を洗い出し、SPF/DKIMアライメントの対応状況を整理する方法を推奨します。

PowerDMARCでリスト化できること

PowerDMARCではDMARCレポート（RUA）を解析し、実際に送信が行われている送信元（IP/ホスト/送信元サービス）を可視化できます。
これにより、サービスの数だけ手作業で確認する負担を大きく削減できます。

ただし、DMARCレポートは「実際に送信が発生しているもの」しか観測できません。
送信頻度が極端に低いものや、将来利用される可能性のある仕組みについては、関係部署へのヒアリングで補完が必要になる場合があります。

第一フェーズの成果物（ここが予算取得に効きます）

第一フェーズの成果物として、送信元一覧と、各送信元の対応方針（無料で対応可／有料オプション要否／移行要否／オンプレ実装要否）を整理した一覧表を作成します。
これにより、次の一手（第二フェーズ）を、感覚ではなく根拠のある形で決められるようになります。

送信元の4分類（実務で使える判定軸）

洗い出した送信元は、以下の4つに分類します。
この分類ができると、「何にいくらかかる可能性があるか」が見えるようになります。

分類1：ベンダーに依頼すれば、SPFとDKIMの双方のアライメントが一致できるもの
管理画面での設定、またはベンダーサポートへの依頼により、Return-Path（Envelope From）のカスタムドメイン化やDKIM署名の設定が可能なケースです。
追加費用は発生せず、標準機能の範囲で対応できます。
分類2：自社運用MTAでDKIMを実装すべきもの
オンプレミスのMTA（例：Postfix、Sendmailなど）で、DKIM署名を追加する必要があるケースです。
milter連携などの実装作業が必要となるため、社内工数または外部委託費用を見込みます。
分類3：外部メール配信サービスで、料金を払ってSPFとDKIMの双方のアライメントの一致ができるもの
Return-Pathのカスタムドメイン化や専用設定が、有料プランまたは有料オプションになっているケースです。
費用と契約条件を確認し、第二フェーズの予算に計上します。
分類4：外部メール配信サービスで、料金を払ってもSPFとDKIMの双方のアライメントの一致ができないので移行すべきもの
一部のベンダーでは、技術的な制約や運用上の都合によりアライメントの一致が実現できず、プラットフォーム移行が必要になります。
移行計画、影響範囲、段階移行の要否を含めて検討します。

外部ベンダーでも追加費用が出る代表例（SPFアライメント）

外部メール配信サービスは「DMARC対応」と言っていても、標準プランではReturn-Pathがベンダー管理ドメインのままで、SPFアライメントが不一致となることがあります。
その場合、「Return-Pathを御社ドメイン配下に変更する」機能が、有料プラン／有料オプションとして提供されていることがあり、追加費用が発生します。

DMARCのポリシーを強化していく（p=quarantine / p=reject）場合、SPFまたはDKIMのいずれかでアライメントを満たす必要があるため、
このSPFアライメント対応が実質的に必須となり、結果として追加費用が発生することがあります。

第二フェーズ：対応方針の決定と予算化（やることを“確定”する）

第二フェーズでは、第一フェーズの分類結果を踏まえて、各送信元ごとに以下を確定します。

この確定情報に基づいて、第二フェーズの予算を積み上げます。
「よく分からないから一式見積」ではなく、送信元ごとの根拠があるため、社内説明が通しやすくなります。

ポリシーの引き上げ：p=noneからp=rejectへ

第二フェーズで各送信元の対応が完了したら、DMARCポリシーを引き上げます。
一般的には、p=none → p=quarantine → p=rejectと3段階で移行する方法が紹介されています。
しかし弊社では、p=noneで送信元の仕分けとSPF/DKIMの整備を終えた後、p=quarantineを経由せず、直接p=rejectへ移行することをお勧めしています。

p=quarantineを経由しない理由

問題の即時検知
p=rejectであれば、DMARCに合格できないメールは送信時に即座にエラーとなります。
p=quarantineでは迷惑メールフォルダに入るだけで、送信側が問題に気づけません。
目的が達成できない
p=quarantineでは、なりすましメールが受信者の迷惑メールフォルダには届いてしまうため、目的1を満たしません。
また、攻撃者から見て「送っても無駄なドメイン」とは判定されないため、目的2の抑止効果も得られません。
実際に、p=quarantineではなりすましメールの割合が下がらないことが分析から判明しています。
見逃した正規の送信元を炙り出せる
週に数通だけ送る正規のメール配信プラットフォームは、DMARCレポートからは見つけ出す事が困難です。
p=rejectにすることで、こうした送信元をmaillogや利用している現場からの申請という形で顕在化させることができます。
また、なりすましメールが急速に減少するため、レポートの分析精度が上がり、少数のメールを送っている送信元も見つけやすくなります。
ただし、この方法は第一フェーズで洗い出しきれなかった、ごく低頻度の送信元を発見するための最終的な安全網です。
この方法に頼る前に、第一フェーズの分析を十分に行い、既知の送信元を可能な限り洗い出しておくことが前提となります。

メーリングリストへの対応

RFC 9989は、一般の利用者がメーリングリストに参加するドメインについて、p=rejectによる相互運用性の問題を指摘しています。
メーリングリストがヘッダーFromを保ったまま件名やフッターを書き換えると、SPFもDKIMも壊れ、DMARCが不合格になるためです。

これに対する弊社の考え方は、DMARCのポリシーを緩めるのではなく、ARCを実装したメーリングリストを使うことです。

自社でメーリングリストを運用する場合
ARC（RFC 8617）に対応したソフトウェアを使用してください。
Mailman 3を推奨します。
ARCによって転送前の認証結果が引き継がれるため、受信側は正規の転送であると判断でき、前述のポリシー上書きが働きます。
Google Groupsを利用する場合
特別な対応は不要です。
送信元ドメインがp=rejectを掲げている場合、Google Groups側がヘッダーFromの書き換えを行います。
送信元がきちんと認証を保証していることをGoogle Groupsが認識して処理するため、p=rejectのままで問題ありません。

つまり、メーリングリストの存在は、p=rejectを見送る理由にはなりません。
リスト側をARC対応にすることで、ポリシーを緩めずに相互運用性を確保できます。

移行判断の基準

p=rejectへ進めるかどうかは、第一フェーズで作成した送信元一覧を基準に判断します。
以下の3点が満たされていることを確認してください。

送信元一覧の全項目に決着がついている
洗い出した送信元それぞれについて、SPFまたはDKIMのアライメントが一致する状態になっているか、あるいは対応方針が確定して実装が完了している必要があります。
「調査中」「ベンダー回答待ち」の項目が残っている状態では、まだ移行の段階ではありません。
対応しない送信元について合意が取れている
アライメント一致が実現できず移行が必要な送信元について、移行完了・利用停止・例外扱いのいずれかで関係部署と合意が取れている必要があります。
例外扱いとする場合は、そのメールが拒否されることを利用部門が承知している状態にしてください。
レポートの受信とアラート体制が整っている
移行後に想定外の認証失敗が発生した場合、即座に検知できる体制が必要です。
DMARCレポートの継続的な受信と、異常値検出時の通知設定を事前に整えてください。
RFC 9989 §8も、集約レポートを受信するメールボックスを用意し、レポートを収集して分析することを、DMARCに完全に参加するための要件（MUST）として挙げています。

DMARC合格率だけで判断してはいけない理由

移行の判断材料として、DMARCの合格率（コンプライアンス率）を使いたくなります。
しかし、合格率はあくまで目安であり、これだけを見て判断すると誤ります。
理由は2つあります。

合格率の分母には、なりすましメールが含まれる
DMARCレポートは、自社ドメインを騙って送信されたメールも含めて観測します。
そのため、正規送信の整備が完了していても、なりすまし攻撃を受けている最中のドメインでは合格率は低いままです。
逆に、なりすましがほとんど発生していないドメインでは、未対応の正規送信元が残っていても合格率は高く出ます。
つまり合格率は、正規送信の整備がどこまで進んだかを測る指標としては機能していません。
低頻度の送信元は、合格率にほとんど現れない
週に数通、月に数通しか送らない正規の送信元は、送信量が小さいため合格率の数値をほとんど動かしません。
合格率が99%に達していても、残りの1%の中に業務上重要な送信元が埋もれている可能性は消えません。
「合格率が高いから移行して良い」という判断は、この見えていない送信元のメールが消失するリスクを見落とすことになります。

合格率は、整備作業の進捗を大まかに把握したり、移行後の急激な低下を異常検知の手がかりとして使う分には有用です。
しかし移行の可否は、あくまで送信元一覧の全項目に決着がついているかという、作業の網羅性で判断してください。

サブドメインの扱い（spタグとnpタグ）

DMARCのポリシーは、組織ドメインに適用されるpタグだけでなく、サブドメインに適用されるspタグも合わせて設計します（RFC 9989 §4.7）。
spタグとnpタグがいずれも存在しない場合、サブドメインにはpタグの値が適用されます。
そのため、組織ドメインをp=rejectにすれば、原則としてサブドメインも同じポリシーで保護されます。

問題になるのは、サブドメインに独自のDMARCレコードが設定されている場合や、メール送信に使っていないサブドメインが多数存在する場合です。
攻撃者はOSINTのDNS調査でサブドメインを列挙し、防御の手薄なサブドメインを騙ってなりすましメールを送信します。
組織ドメインのp=reject化と合わせて、サブドメインの防御も設計してください。

spタグ
組織ドメインとサブドメインで異なるポリシーを適用したい場合に使用します。
適用対象はDNS上に実在するサブドメインのみで、組織ドメイン自身には適用されません。
また、組織ドメインではなくサブドメインに公開したDMARCレコードにspを記述しても、ポリシー探索の仕組み上そのspは無視されます。
spタグは、必ず組織ドメインのDMARCレコードに記述してください。
npタグ
RFC 9989 §4.7で新設されたタグで、DNS上に存在しないサブドメイン（Non-existent subdomain）に適用されるポリシーを指定します。
npタグが存在しない場合はspタグ、それも存在しない場合はpタグの値が適用されます。
np=rejectを設定することで、実在しないサブドメインを騙るなりすましを一括で拒否できます。
実在するがメール送信に使っていないサブドメイン
npタグの対象外となるため、個別にNull設定を行います。
SPFはv=spf1 -all、DMARCはv=DMARC1; p=reject;を設定します。

第一フェーズの送信元の洗い出しと並行して、DNSゾーンファイルからサブドメインの一覧を作成し、メール送信に使っているものと使っていないものを仕分けておくと、この作業がスムーズに進みます。

まとめ：p=rejectは“設定”ではなく“プロセス”

攻撃者はOSINTで外部から見える設定を調べ、防御の甘い標的を選びます。
DNS、Web、メールのいずれもきちんと設定されていれば「面倒な会社」として攻撃対象から外れ、p=rejectはそのうちDNSとメールの防御シグナルを担います。

p=rejectはDNSレコードを1行変えるだけで到達できますが、本当に重要なのは「正規送信を壊さない状態を作る」ことです。
そのために、まずは第一フェーズで送信元を洗い出し、無料/有料/移行/オンプレ実装の分類を行い、第二フェーズで予算と方針を確定する進め方が現実的です。
移行の判断は、合格率という数値ではなく、送信元一覧の網羅性で行ってください。
予算がない状態からでも、段階的に合意形成を進め、なりすましの遮断・攻撃者への抑止・BIMIによるシンボルマーク表示という3つの目的を、最終的に達成することができます。