DMARC ポリシーを p=none に設定することは、一般的に監視モードと呼ばれます。

これは、受信メールサーバーに対して、DMARC 認証を評価し、要求された場合にレポートを生成するよう指示しますが、メッセージが失敗した場合に DMARC 強制アクションを適用しないことを意味します。実際には、DMARC に失敗したメッセージが、あなたの DMARC ポリシーによって拒否または隔離されないということです。

この設定は有用ですが、しばしば誤解されています。

p=none は保護ではありません。可視性です。

組織はこれを使用して、誰が自社のドメインの代わりにメールを送信しているか、どのシステムが認証を通過しているか、どのベンダーがアラインメントに失敗しているか、そしてスプーフィング攻撃がすでに発生している可能性がある場所を発見します。

適切に使用すれば、p=none はドメインを強制適用に備えるための診断フェーズです。無期限に使用すると、可視性のみの姿勢となり、ドメインを正確なドメインスプーフィングにさらすことになります。

I. DMARC p=none が実際に行うこと

p=none を含む DMARC レコードを公開すると、受信メールサーバーは完全な DMARC 評価を実行できます。

メッセージが SPF または DKIM を通過するかどうか、そしてそれらの認証された識別子の少なくとも1つが可視的な From ドメインとアラインしているかどうかをチェックします。

メッセージが DMARC を通過するのは、以下の少なくとも1つが真である場合のみです:

• SPF が通過し、SPF 認証済みドメインが可視的な From ドメインとアラインしている。
• DKIM が通過し、DKIM 署名ドメインが可視的な From ドメインとアラインしている。

SPF が通過するだけでは不十分です。DKIM が通過するだけでも不十分です。アラインメントこそが、認証を受信者が見るドメインに結びつけるものです。

p=none では、認証が失敗した場合に DMARC ポリシーアクションを適用しないよう受信者に指示します。集約レポートが設定されている場合、受信者は観察した認証結果を示す DMARC レポートを送信する可能性があります。

この区別は重要です。

p=none を持つドメインは、DMARC レコードを持たないドメインと同じではありません。ドメインは評価されており、レポートを受信できます。しかし、まだ DMARC 強制によって保護されていません。

II. 組織が p=none から始める理由

ほとんどの組織は、DMARC を開始する前に自社のメールエコシステムを完全には理解していません。

それは普通のことです。

メールは予想以上に多くのシステムを通じて組織を離れることがよくあります:

• Microsoft 365 または Google Workspace
• マーケティングオートメーションプラットフォーム
• CRM システム
• サポートチケットプラットフォーム
• トランザクショナルメールプロバイダー
• 請求・請求書システム
• HR プラットフォーム
• 地域別ツール
• レガシーアプリケーション
• サードパーティベンダー
• シャドー IT サービス

これらのソースが特定されアラインされる前にドメインが直接 p=quarantine または p=reject に移行すると、正当なメールが失敗する可能性があります。

だから監視モードが重要なのです。

p=none は、セキュリティチームと IT チームが強制適用を開始する前に、実世界の認証動作を安全に観察する方法を提供します。

このフェーズ中、DMARC レポートは以下を明らかにできます:

• 適切に認証された正当な送信者
• SPF または DKIM アラインメントに失敗した正当な送信者
• 適切な設定なしで送信しているサードパーティプラットフォーム
• ドメインを使用している未知の IP アドレス
• まだメールを送信しているレガシーシステム
• 個別のレビューが必要なサブドメイン
• ドメインに対するスプーフィング攻撃
• DNS ルックアップ制限に近づいている SPF レコード

目標は p=none に留まることではありません。

目標は、可視性を使用してドメインを強制適用に備えることです。

III. 適切な方法で DMARC 監視を開始する

基本的な静的 DMARC 監視レコードは次のようになります:

v=DMARC1; p=none; rua=mailto:[email protected]

このレコードは機能しますが、レポートが実際に受信、解析、レビュー、および対応される場合のみです。

これが多くの組織が失敗するところです。

DMARC レポートは通常、XML ファイルとして届きます。多くの受信者から届き、大量のメッセージをカバーし、どの送信者が正当で、どれが誤設定され、どれが不正かを特定するための分析が必要です。

アクティブな監視なしの静的レコードは、誤った進捗感覚を生み出します。

より良いアプローチは、Skysnag を通じて DMARC 監視を開始し、ドメイン用に管理された DMARC レコードを生成することです。

ここから始めてください:

https://app.skysnag.com/en/register/

Skysnag は、DMARC レポートの収集と分析を支援し、チームが送信者を特定し、認証のギャップを修正し、自信を持って強制適用に移行できるようにします。

IV. p=none で何が問題になるか

監視モードは、正しく実装されていない場合、静かに失敗する可能性があります。

レポート配信の失敗

rua= タグのメールボックスがレポートを受信できない場合、組織は可視性を失います。

一般的な原因には以下があります:

• 不正確なレポートアドレス
• メールボックスサイズの制限
• レポートメールのフィルタリングまたは隔離
• 外部レポート送信先の認証問題
• レポートメールボックスを監視する人がいない
• メールセキュリティツールによってブロックされるレポート添付ファイル

これが、手動 DMARC レポートがうまくスケールしない理由の1つです。

レポートが収集およびレビューされていない場合、p=none は運用価値がほとんどない DNS レコードになります。

不完全なレポート

すべての受信者が DMARC 集約レポートを送信するわけではありません。

大手メールボックスプロバイダーは一般的にレポートを送信しますが、小規模プロバイダー、レガシーシステム、一部のエンタープライズゲートウェイは送信しない可能性があります。つまり、DMARC レポートは有用な可視性を提供しますが、すべてのメッセージの完全なグローバルビューではありません。

組織は DMARC レポートを完璧なデータセットではなく、強力なシグナルとして扱うべきです。

レポートの遅延

DMARC 集約レポートはリアルタイムアラートではありません。

通常、メッセージが処理された後に、しばしば遅延を伴って届きます。これは、トレンド分析、送信者の発見、強制適用計画には優れていますが、即座のフィッシング検出として扱うべきではないことを意味します。

認証結果の誤読

よくある間違いは、SPF 通過または DKIM 通過を DMARC 通過として扱うことです。

DMARC は可視的な From ドメインとのアラインメントを必要とします。サードパーティベンダーは独自のドメインを使用して SPF を通過したり、独自のドメインで DKIM に署名したりする場合がありますが、あなたのドメインの DMARC アラインメントには依然として失敗します。

これは、強制適用の前に解決すべき最も重要な問題の1つです。

V. p=none がリスクにさらす場合

p=none は可視性を提供しますが、正確なドメインスプーフィングを阻止しません。

攻撃者があなたの実際のドメインから来たと主張するメールを送信し、メッセージが SPF、DKIM、DMARC アラインメントに失敗した場合、あなたの p=none ポリシーは受信者に DMARC のためにメッセージを隔離または拒否しないよう指示します。

受信プロバイダーは、独自のスパム、フィッシング、評判、セキュリティシステムを使用してメッセージをフィルタリングする可能性があります。しかし、あなたの DMARC ポリシー自体は受信者にそれをブロックするよう求めていません。

これは実際の露出期間を作り出します。

攻撃者は以下を試みる可能性があります:

• 正確なドメインスプーフィング
• 経営幹部のなりすまし
• 偽の請求書メッセージ
• 認証情報のフィッシング
• ベンダー支払い詐欺
• 偽のサポートまたはセキュリティアラート
• 保護されていないサブドメインの悪用

まだ p=none にあるドメインの場合、DMARC はこれらの試みが発生していることを示すことができます。それらが配信されることを防ぐことはできません。

VI. p=none に長く留まりすぎることがリスクである理由

多くの組織は p=none を公開し、レポートを受信し、前進することはありません。

それが最も一般的な失敗です。

監視フェーズには明確な目的と終点があるべきです。

ドメインが何ヶ月または何年も p=none のままである場合、組織は悪用に対する可視性を持っているかもしれませんが、それに対する DMARC 強制がありません。

これは以下に使用されるドメインにとって弱い立場です:

• 顧客とのコミュニケーション
• 従業員とのコミュニケーション
• 請求と請求書
• パスワードリセット
• アカウント通知
• セキュリティアラート
• ベンダーとのコミュニケーション
• 経営幹部のコミュニケーション
• 規制された、または高信頼のワークフロー

これらのドメインの場合、監視は行動につながるべきです。

VII. p=none が適切な場合

p=none は、組織が DMARC を開始し、送信者を発見し、または認証修正を検証している場合に適切です。

新しく取得したドメイン、複雑な環境、またはメールソースがまだマッピングされているドメインにも有用です。

一般的な有効な使用例には以下があります:

• 初期 DMARC 展開
• メールソースの発見
• サードパーティ送信者のレビュー
• SPF および DKIM アラインメントテスト
• 移行計画
• ドメイン取得評価
• レガシーシステムのレビュー
• 強制適用前の検証

しかし、p=none は重要な送信ドメインの最終状態になるべきではありません。

顧客、従業員、またはパートナーが信頼するドメインの場合、長期的な目標は通常、正当なメールが適切にアラインされた後、p=quarantine または p=reject による強制適用であるべきです。

VIII. p=none から強制適用への移行

監視から強制適用への道は、証拠に基づくべきです。

強制適用に移行する前に、以下を確認してください:

• すべての正当な送信者が特定されている。
• 重要な送信者が DMARC を通過している。
• サードパーティベンダーが適切にアラインされている。
• SPF レコードがルックアップ制限を超えていない。
• 必要な場所で DKIM が有効になっている。
• サブドメインがレビューされている。
• 未知の送信者が調査されている。
• ビジネスオーナーが変更を理解している。
• ロールバック手順が定義されている。
• DMARC レポートがアクティブに監視されている。

これらの条件が満たされたら、組織は選択したドメインまたはサブドメインを強制適用に移行し始めることができます。

実用的な強制適用パスは次のようになります:

1. 発見のために p=none から始める。
2. 認証またはアラインメントに失敗する正当なソースを修正する。
3. リスクの低い、または十分に理解されているサブドメインを p=quarantine に移行する。
4. 影響を監視し、残りの問題を解決する。
5. 成熟したビジネスクリティカルなドメインを p=quarantine に移行する。
6. 信頼度が高いときに p=reject に移行する。

この段階的なアプローチは、すべてのドメインを一度に変更するよりも安全です。

また、現在の DMARC 対応プログラムで推奨されなくなったパーセンテージベースのロールアウトに依存することも避けられます。

IX. p=none に関する一般的な誤解

「p=none は保護されていることを意味する」

誤り。

p=none は監視していることを意味します。DMARC に失敗したメッセージを隔離または拒否するよう受信者に指示するものではありません。

「SPF と DKIM で十分」

必ずしもそうではありません。

SPF と DKIM は、可視的な From ドメインとアラインする場合にのみ DMARC に有用になります。アラインメントがなければ、メッセージは SPF または DKIM を通過しても DMARC に失敗する可能性があります。

「レポートはすべてを教えてくれる」

いいえ。

DMARC レポートは有用ですが、遅延があり、不完全であり、受信者が送信することに依存しています。

すべてのメッセージをグローバルに表示するわけではなく、集約レポートにはメッセージの内容は含まれません。

「永遠に p=none のままでいられる」

技術的には可能ですが、セキュリティ的には、ドメインが監視のみのモードに留まることを意味します。

重要なドメインの場合、p=none は永続的な戦略ではなく、フェーズであるべきです。

「強制適用はメールを壊す」

強制適用は、発見なしで実装されると正当なメールを壊す可能性があります。

だから監視が存在します。

p=none の目的は、強制適用前に問題を見つけて修正することであり、永続的に強制適用を避けることではありません。

X. フォレンジックレポートはどうか?

DMARC は ruf= タグを通じて失敗レポートをサポートしていますが、無闇に有効にすべきではありません。

失敗レポートは、受信者の実装によって、機密性の高いメッセージレベルの情報を含む可能性があります。また、プライバシーの懸念から、主要なメールボックスプロバイダー間での採用が限られています。

ほとんどの組織にとって、rua= を通じた集約レポートがデフォルトの出発点であるべきです。

法務、プライバシー、セキュリティ、保持に関するレビューの後でのみフォレンジックレポートを使用してください。

XI. ツールが重要な理由

DMARC 監視は、レポートが実行可能になる場合にのみ有用です。

生の XML レポートは手動でレビューするのが困難です。送信者別に正規化、グループ化され、SPF および DKIM アラインメントについて解釈され、時間の経過とともに追跡される必要があります。

Skysnag Protect は、チームに以下の可視性を提供することで、このプロセスを自動化するのに役立ちます:

• 承認された送信者
• 不正なソース
• SPF および DKIM アラインメント
• DMARC 通過および失敗トレンド
• サブドメインアクティビティ
• 強制適用の準備状況
• 認証失敗
• 時間経過による送信者の変化

これにより、組織は受動的監視からアクティブな保護に移行できます。

Skysnag で DMARC 監視を開始し、無料の DMARC レコードを取得してください:

https://app.skysnag.com/en/register/

XII. 実装チェックリスト

このチェックリストを使用して p=none を効果的にしてください。

• [ ] 集約レポート付きの DMARC 監視レコードを公開する。
• [ ] 管理されていないメールボックスではなく、監視されたレポート送信先を使用する。
• [ ] DMARC レポートが受信および解析されていることを確認する。
• [ ] すべての正当な送信ソースを特定する。
• [ ] 未知のソースを正当、誤設定、または不正として分類する。
• [ ] 各送信者の SPF アラインメントを検証する。
• [ ] 各送信者の DKIM アラインメントを検証する。
• [ ] SPF DNS ルックアップ制限をレビューする。
• [ ] サードパーティベンダーがアラインされた認証をサポートしていることを確認する。
• [ ] プライバシーおよび法務チームが承認しない限り、フォレンジックレポートを避ける。
• [ ] サブドメインを個別にレビューする。
• [ ] quarantine または reject に移行するための基準を定義する。
• [ ] 強制適用前にロールバック手順を確立する。
• [ ] ポリシー変更後、レポートを継続的に監視する。

XIII. 重要なポイント

DMARC p=noneは監視モードです。

これにより、受信メールサーバーはDMARCを評価してレポートを送信できますが、失敗したメッセージをブロックまたは隔離するよう指示するものではありません。

そのため、検出には有用ですが、長期的な保護には不十分です。

組織はp=noneを使用して、正当な送信者を特定し、認証の失敗を検出し、サードパーティの整合性を修正し、強制実施の準備をする必要があります。

主な失敗は、p=noneのまま無期限に留まることです。

重要なドメインの場合、正当なメールが適切に整合されたら、監視からp=quarantineまたはp=rejectへと移行する必要があります。

DMARCの強制実施こそが、完全一致ドメインなりすましのリスクを軽減するものです。監視は、そこに安全に到達するための手段です。

SkysnagでDMARC監視を開始し、無料のDMARCレコードを取得しましょう: