p=reject後の運用ガイド

1. p=rejectはゴールではなくスタート

このセクションのポイント: p=rejectの設定完了で「安全」と考えるのは早計です。メール認証の環境は常に変化しており、継続的な監視・最適化なくして安全は維持できません。

「設定して終わり」ではない理由

p=rejectを達成すると、なりすましメールは2〜3週間で激減し、DMARCコンプライアンス率は99%を超えます。
この時点で「もう対応は完了した」と思いがちですが、以下の理由から継続的な運用が不可欠です。

送信環境は変化する

新しいSaaSツールの導入、メール配信サービスの変更、取引先との連携システムの追加など、メール送信経路は日々変化します。
新たな送信経路が追加されるたびに、SPF・DKIMの設定とDMARC Alignmentの確認が必要です。
これを怠ると、正規のメールがp=rejectにより拒否される事態が発生します。

攻撃手法は進化する

攻撃者はp=rejectのドメインを直接的になりすますことを諦めますが、攻撃そのものを止めるわけではありません。
無関係のドメインを使った名前詐称、類似ドメイン（typosquatting）による攻撃、サプライチェーンを経由した間接攻撃など、手法を変えて攻撃を続けます。

業界標準は厳格化している

Gmailの送信者ガイドライン、PCI DSS 4.0、各省庁のガイドラインなど、メールセキュリティに関する要件は年々厳しくなっています。
p=reject設定だけでなく、Alignmentの厳格モード（strict）やBIMIの実装など、追加対応が求められる場面が増えています。

p=reject後の運用で目指すべき状態

2. RUAレポートの継続監視と活用

このセクションのポイント: p=reject後のRUAレポートは「セキュリティ監査報告」です。定期的な確認により、設定不備、攻撃の兆候、DNSの問題を早期に発見できます。

なぜp=reject後もRUAレポートが重要なのか

p=reject設定後、RUAレポートの重要性はむしろ増します。
p=noneの段階ではレポートは「現状把握」のために使いますが、p=reject後のレポートは「防衛線の監視」として機能します。

正規メールの認証失敗の検知

新しいSaaSツールの導入、メール配信サービスの設定変更、DNSレコードの意図しない変更など、正規メールの認証が失敗する原因は多岐にわたります。
RUAレポートで認証失敗を早期に検知し、メールの不達を最小限に抑えることができます。

Overrideの監視

受信側MTAが、p=rejectのポリシーを上書き（Override）しているケースがRUAレポートに記録されます。
上書き理由としては、転送（forwarded）、メーリングリスト（mailing_list）、受信側のローカルポリシー（local_policy）などがあり、それぞれの発生頻度と傾向を把握することが重要です。

攻撃傾向の変化の把握

なりすましメールの送信元IPアドレス、送信地域、送信量の推移を監視することで、攻撃の傾向変化を察知できます。
突然なりすましメールが増加した場合は、新たな攻撃キャンペーンの開始を示唆している可能性があります。

RUAレポートの確認頻度

RUAレポートの確認頻度は、組織の規模とリスクレベルに応じて設定します。

週次確認（推奨最低頻度）

DMARCコンプライアンス率の推移、認証失敗件数の異常な増減、Override件数の推移を確認します。
商用のDMARCレポート分析サービスのダッシュボードであれば、数分で完了します。

即時アラート

DMARCコンプライアンス率の急激な低下や、特定のIPアドレスからの大量の認証失敗など、異常値を検出した際に即時通知を受ける設定を推奨します。

月次レビュー

月単位での傾向分析、SPFレコードの最適化要否の判断、新たに検出された送信元の正当性確認を行います。
このデータは、コンプライアンス報告やセキュリティレビューの基礎資料としても活用できます。

Overrideの種類と対応

p=reject設定後、受信側MTAがポリシーを上書きするケースは一定数発生します。
RUAレポートでOverrideの理由を確認し、適切に対応することが重要です。

forwarded（転送）

メール転送によりSPF検証が失敗し、受信側がp=rejectを緩和したケースです。
DKIMが正しく設定されていれば、転送先でもDKIM検証が合格するため問題ありません。
DKIMが失敗する場合は、転送経路での改変が原因の可能性があり、ARCの活用を検討します。

mailing_list（メーリングリスト）

メーリングリスト経由の配信でDMARC認証が失敗したケースです。
メーリングリスト運用者にARC対応やFrom書き換えの実施を依頼するか、メーリングリスト用のサブドメインの利用を検討します。

local_policy（ローカルポリシー）

受信側独自のポリシーにより、p=rejectが緩和されたケースです。
多くの場合、受信側の管理者判断によるものであり、送信側からの直接的な対応は困難ですが、件数が多い場合は原因を調査する価値があります。

3. SPFレコードの最適化

このセクションのポイント: SPFレコードは「設定したら終わり」ではなく、送信環境の変化に伴い肥大化・陳腐化します。定期的な最適化がメール到達率の維持に直結します。

SPFレコードが抱えやすい問題

DNSルックアップ数の超過

SPFの仕様（RFC7208 Section 4.6.4）では、DNSルックアップは10回までに制限されています。
include、a、mx、redirect、existsのメカニズムがそれぞれ1回以上のルックアップを発生させます。
メール配信サービスを複数利用している場合、各サービスのinclude先がさらにネストしたincludeを含んでいることがあり、10回を容易に超えてしまいます。
10回を超えた場合、SPF検証はPermerror（恒久エラー）となり、全てのメールでSPFが失敗します。

不要なincludeの残存

過去に利用していたメール配信サービスやSaaSツールのincludeが、解約後もSPFレコードに残っているケースが非常に多いです。
不要なincludeはDNSルックアップ数を無駄に消費するだけでなく、意図しない第三者からの送信をSPFで許可してしまうセキュリティリスクにもなります。

DNS応答サイズの増大

SPFレコードが長くなると、DNSのUDP応答（通常512バイト以下）に収まらず、TCPフォールバックが発生します。
TCPフォールバックは応答時間の増大を招き、受信側MTAのタイムアウトによるTemperror（一時エラー）の原因となります。

最適化のポイント

不要なincludeの削除

現在利用していないメール配信サービスやSaaSツールのincludeを洗い出し、削除します。
RUAレポートの送信元IPアドレスと照合することで、実際に使用されているincludeを特定できます。

includeのネスト構造の確認

各includeが内部でさらにどれだけのDNSルックアップを発生させているかを確認します。
1つのincludeが内部で3〜4回のルックアップを発生させていることも珍しくありません。

SPF Flatteningの検討

includeをIPアドレスリストに展開する「SPF Flattening」により、DNSルックアップ数を削減できます。
ただし、メール配信サービス側のIPアドレスが変更された場合にSPFレコードの更新が必要となるため、自動化の仕組みが不可欠です。

送信経路の統廃合

複数のメール配信サービスを利用している場合、統廃合を検討します。
送信経路を集約することで、SPFレコードの簡素化、管理工数の削減、コストの最適化が同時に実現できます。

定期レビューの推奨頻度

SPFレコードの状態は、四半期に1回の頻度でレビューすることを推奨します。
特に、新しいSaaSツールの導入やメール配信サービスの変更があった場合は、即座に確認してください。

4. DKIMの運用管理

このセクションのポイント: DKIM鍵は適切に管理しないと、鍵の漏洩や暗号強度の低下により、セキュリティリスクが生じます。鍵のローテーションと鍵長の見直しが重要です。

DKIM鍵のローテーション

DKIM署名に使用する秘密鍵は、定期的にローテーション（更新）することが推奨されます。
鍵が長期間同じままだと、万が一鍵が漏洩した場合に、攻撃者が正規のDKIM署名を付与したなりすましメールを送信できてしまいます。

ローテーションの手順

新しい鍵ペアを生成し、新しいセレクタ名でDNSに公開鍵を追加します。
送信側で新しい秘密鍵での署名を開始した後、旧セレクタの公開鍵をDNSから削除します。
移行期間中は新旧両方のセレクタがDNSに存在する状態となり、メールの配信に影響はありません。

推奨頻度

年に1〜2回のローテーションが一般的に推奨されます。
セキュリティ要件が厳しい組織では、四半期ごとのローテーションを検討してください。

DKIM鍵長の確認

DKIM鍵長は、現在2048ビット以上が推奨されています。
1024ビット鍵は依然として多くの環境で使用されていますが、計算能力の向上に伴い、将来的にはセキュリティ上のリスクとなる可能性があります。

鍵長を2048ビットにすると、DNSのTXTレコードが長くなるため、レコードを複数の文字列に分割して登録する必要がある点に注意してください。

不要なDKIMレコードの削除

過去に利用していたメール配信サービスのDKIMセレクタが、DNSに残っていることがあります。
不要なDKIMレコードはDNSのクリーンアップのために削除することを推奨します。
ただし、削除前に、そのセレクタが現在使用されていないことをRUAレポートで確認してください。

5. サブドメイン戦略

このセクションのポイント: サブドメインの管理が甘いと、APEXドメインのp=rejectが設定されていても、サブドメイン経由でなりすましが行われます。sp=rejectと未使用サブドメインの対策が重要です。

サブドメインポリシー（sp=）の設定

DMARCレコードのsp=タグは、サブドメインに適用するポリシーを指定します。
sp=が未指定の場合、APEXドメインのp=の値がサブドメインにも適用されます。

しかし、サブドメインごとに個別のDMARCレコードが設定されている場合は、そちらが優先されます。
組織内で利用されている全てのサブドメインのDMARC設定状況を把握し、一貫したポリシーが適用されていることを確認してください。

未使用サブドメインの防御

メール送信に使用していないサブドメインも、攻撃者によってなりすましに利用される可能性があります。
未使用サブドメインに対しては、以下の「Null設定」を行うことで、なりすましを防止できます。

SPFのNull設定

v=spf1 -all を設定し、そのサブドメインからのメール送信を一切許可しないことを宣言します。

DKIMのNull設定

ワイルドカードDKIMレコード *._domainkey.subdomain.example.com に空のレコードを設定することで、全てのDKIM検証を失敗させます。

DMARCのNull設定

v=DMARC1; p=reject; を設定し、認証失敗メールの拒否を指示します。

用途別サブドメインの活用

メールの用途に応じてサブドメインを使い分けることで、運用の柔軟性と監視の精度を高められます。

マーケティングメール用サブドメイン

例：marketing.example.com
大量配信のマーケティングメールをサブドメインから送信することで、APEXドメインのIPレピュテーションへの影響を分離できます。

トランザクションメール用サブドメイン

例：notify.example.com
注文確認、パスワードリセットなどのシステム通知メールを分離することで、到達率の管理を個別に行えます。

サブドメインを増やすことで管理対象は増えますが、RUAレポートの分析精度が向上し、問題の特定が容易になるメリットがあります。

6. DNSパフォーマンスとメール到達率

このセクションのポイント: SPF・DKIM・DMARCはDNSに依存しているため、DNSの応答速度がメール認証の成否に直結します。DNSのパフォーマンス問題は、RUAレポートでTemperrorとして検出できます。

DNSの遅延がメール認証に与える影響

SPF・DKIM・DMARCの全てがDNSからのレコード取得に依存しています。
受信側MTAがDNSに問い合わせた際に、応答が遅延すると、タイムアウトによりTemperror（一時エラー）が発生し、認証が失敗します。

SPFのタイムアウト

SPFは仕様上（RFC7208）、20秒のタイムアウトが明記されています。
SPFレコードのincludeがネストしている場合、複数回のDNSルックアップが直列で行われるため、累積遅延がタイムアウトに達するリスクが高まります。

DKIMのタイムアウト

DKIMは仕様上、タイムアウトが制定されていません。
そのため、受信側MTAが独自にタイムアウト値を設定しており、環境によって異なります。
短いタイムアウトを設定している受信側MTAでは、DNS応答が遅いだけでDKIM検証が失敗することがあります。

DNSパフォーマンスの確認方法

RUAレポートにおいて、SPFやDKIMのTemperror（一時エラー）が一定数報告されている場合は、DNSの応答速度に問題がある可能性があります。
以下のポイントを確認してください。

DNSサーバの応答時間

自社のDNSサーバ（権威DNSサーバ）の応答時間を、世界各地からモニタリングします。
特に、メールの受信先が海外に多い場合は、地理的に分散したDNSサーバの利用やCDN型DNSの活用を検討します。

TTL設定の最適化

SPF・DKIM・DMARCのDNSレコードのTTL（Time To Live）が極端に短い場合、キャッシュが効かず、毎回権威サーバへの問い合わせが発生します。
頻繁に変更しないレコードについては、TTLを長めに設定する（例：3600秒〜86400秒）ことで、DNS負荷の軽減と応答速度の向上が見込めます。

SPFレコードの簡素化

前述のSPFレコード最適化により、DNSルックアップ数を削減することが、Temperror対策としても有効です。

7. BIMIへの発展 — DMARCの限界を超える

このセクションのポイント: p=rejectでは防げない「無関係のドメインを使った名前詐称」に対し、BIMIはメールにブランドロゴを表示することで、受信者が視覚的に正規メールを識別できるようにします。

DMARCの限界とは

DMARCは自社ドメインのなりすましを防ぎますが、以下の攻撃には対応できません。

無関係のドメインを使った名前詐称

攻撃者が全く別のドメインを取得し、SPF・DKIM・DMARCを正しく設定した上で、メールの差出人名（Display Name）だけを自社の名前に偽装してメールを送信する手法です。
多くのメールクライアントでは差出人名のみが表示され、メールアドレスは表示されないため、受信者が偽装に気づきにくい状態です。

類似ドメイン（typosquatting）による攻撃

examp1e.com（lが1になっている）やexarnple.com（mがrnになっている）など、見た目が似たドメインを使った攻撃です。
これらのドメインは攻撃者自身が管理しているため、DMARC認証は合格してしまいます。

BIMIとは

BIMI（Brand Indicators for Message Identification）は、DMARC認証に合格したメールに送信者のブランドロゴを表示する仕組みです。
受信者は、メール一覧でロゴの有無を確認するだけで、正規のメールかどうかを視覚的に判別できます。

BIMIの導入要件

BIMIの導入には、以下の要件を満たす必要があります。

DMARCポリシーがp=quarantine以上

BIMIはp=noneのドメインでは利用できません。
p=rejectを設定済みであれば、この要件は既に満たされています。

VMC（Verified Mark Certificate）の取得

Gmailなど一部のメールプロバイダでは、ロゴの表示にVMC（認証マーク証明書）が必要です。
VMCの取得には、商標登録されたロゴが必要となります。

SVG形式のロゴファイル

BIMIで使用するロゴは、SVG Tiny PS形式（SVG Tiny Portable/Secure）で作成する必要があります。

p=rejectを達成している組織にとって、BIMIは次の論理的なステップです。
DMARCだけでは防げない視覚的ななりすましに対して、ブランド保護の効果を発揮します。

8. RUAレポートを活用したセキュリティインテリジェンス

このセクションのポイント: RUAレポートは単なる「認証結果の集計」ではなく、セキュリティインテリジェンスの宝庫です。Webサイトのログとの突き合わせにより、攻撃のプロファイリングが可能です。

RUAレポートから読み取れるセキュリティ情報

攻撃元の地理的分布

なりすましメールの送信元IPアドレスから、攻撃が行われている地域を特定できます。
特定の地域からの攻撃が集中している場合、その地域を起点とした標的型攻撃の可能性があります。

攻撃のタイミングと頻度

なりすましメールの送信量の時系列変化を分析することで、攻撃キャンペーンの開始・終了時期を把握できます。
特定のイベント（決算期、大型セール、プレスリリース直後など）に連動した攻撃パターンが見えてくることもあります。

利用されている送信インフラ

攻撃者がどのようなメール送信インフラ（ボットネット、不正利用されたSaaS、侵害されたサーバなど）を使用しているかを推定できます。

Webサイトのログとの突き合わせ

なりすましメールによる攻撃は、必ずWebサイトとセットで行われます。
フィッシングメールのリンク先は、偽のログインページや偽の決済ページであり、これらはWebサーバ上にホストされています。

RUAレポートで検出されたなりすましメールの送信元IPアドレスや送信地域を、Webサイトのアクセスログやセキュリティログ（secureログ、失敗ログイン試行など）と突き合わせることで、以下の分析が可能です。

攻撃候補のプロファイリング

なりすましメールの送信元と、Webサイトへの不審なアクセス元が一致する場合、同一の攻撃グループによる偵察活動の可能性があります。

攻撃の段階の推定

Webサイトへの偵察アクセスが先行し、その後になりすましメールが送信されるパターンが見られる場合、攻撃の準備段階を検知できている可能性があります。

コンプライアンス・レポートへの活用

RUAレポートのデータは、以下のコンプライアンス関連の報告・評価にも活用できます。

情報セキュリティ監査への対応

DMARC認証の合格率、なりすまし検知件数、対応履歴などを定量的なエビデンスとして提出できます。

PCI DSS準拠の証跡

PCI DSS 4.0で求められるDMARC対応の実施状況を、RUAレポートのデータで裏付けることができます。

サイバーデューデリジェンス

M&Aにおけるセキュリティリスク評価の際、対象企業のDMARC運用状況を示す客観的なデータとして利用できます。

9. 運用コストの最適化

このセクションのポイント: DMARC運用のコストは、送信経路の数、RUAレポートの分析方法、管理工数に大きく依存します。適切な設計により、セキュリティレベルを維持しながらコストを最適化できます。

コスト増大の原因と対策

送信経路の無秩序な増加

部門ごとに独自のメール配信サービスを契約していると、SPFレコードの肥大化、DKIM設定の管理工数増大、コストの分散が発生します。
対策：組織全体のメール送信ポリシーを策定し、利用可能なメール配信サービスを限定します。新規サービスの導入時には、IT部門による事前承認とSPF・DKIM設定の確認を義務化します。

RUAレポートの手動分析

XML形式のRUAレポートを手動で分析している場合、毎日数十〜数百通のレポートに対応するための工数が膨大になります。
対策：商用のDMARCレポート分析サービスを利用し、分析作業を自動化します。ダッシュボードによる視覚的な監視と、異常値のアラート通知により、確認工数を大幅に削減できます。

サブドメインの管理コスト

サブドメインが増えるほど、SPF・DKIM・DMARCの設定管理、RUAレポートの分析対象が増加します。
対策：不要なサブドメインの整理・統廃合を行い、管理対象を最小限にします。未使用サブドメインはNull設定で保護した上で、定期的に棚卸しを行います。

費用対効果の高い運用体制

FAQ

Q1. p=rejectにした後、RUAレポートはどのくらいの頻度で確認すべきですか？

A. 最低でも週次での確認を推奨します。
商用のDMARCレポート分析サービスを利用していれば、ダッシュボードで数分で確認できます。
加えて、異常値のアラート通知を設定し、コンプライアンス率の急激な低下や大量の認証失敗を即座に検知できる体制を整えてください。

Q2. SPFレコードの最適化はいつ行うべきですか？

A. 四半期に1回の定期レビューを推奨します。
また、新しいSaaSツールの導入やメール配信サービスの変更があった場合は、即座にレビューしてください。
RUAレポートでSPFのPermerrorやTemperrorが検出された場合も、即座に対応が必要です。

Q3. BIMIの導入にはどのくらいのコストがかかりますか？

A. BIMIの導入コストは、主にVMC（認証マーク証明書）の取得費用と、ロゴのSVG Tiny PS形式への変換作業費用で構成されます。
VMCの費用は認証局によって異なりますが、年間の証明書費用として数十万円程度が一般的です。
ロゴの商標登録が未了の場合は、商標登録の費用と期間も考慮する必要があります。
詳細はお問い合わせください。

Q4. サブドメインのDMARC設定が漏れていないか、どう確認しますか？

A. まず、DNSゾーンファイルから自社で管理している全サブドメインのリストを作成します。
次に、各サブドメインのDMARC・SPF・DKIMレコードの設定状況をツールで一括確認します。
メール送信に使用していないサブドメインについては、Null設定（SPF: v=spf1 -all、DMARC: v=DMARC1; p=reject;）が行われているかを確認してください。

Q5. DMARC運用を外部に委託することは可能ですか？

A. はい、可能です。
弊社のMailDataサービスでは、RUAレポートの自動分析、異常値の通知、定期レビュー、設定変更の助言、インシデント対応支援まで、DMARC運用を包括的にサポートしています。
社内にメールセキュリティの専門家がいない場合や、運用工数を削減したい場合にご活用ください。

Q6. p=rejectにしているのに、まだなりすましメールの報告があります。どうすれば良いですか？

A. p=rejectで防げるのは、自社ドメインを直接なりすます攻撃です。
攻撃者が無関係のドメインを使い、差出人名（Display Name）だけを自社に偽装する攻撃は、DMARCでは防げません。
この種の攻撃に対しては、BIMIの実装により、受信者が視覚的に正規メールを識別できるようにすることが有効です。
また、類似ドメイン（typosquatting）の監視サービスを利用し、自社に似たドメインが取得された場合にアラートを受け取る仕組みも検討してください。