Proofpointの組織セーフリストに自社ドメインを登録する危険性と対処法

Proofpointの組織セーフリストに自社ドメインを登録する危険性と対処法

自社ドメインを名乗るなりすましメールが、DMARC failのまま社員の受信トレイに届く仕組み ― Proofpoint＋Microsoft 365の構成で確認すべき3か所

作成
著者: 竹洞 陽一郎

結論 ― 組織セーフリストから自社ドメインを削除してください

Proofpointの組織セーフリスト（Organizational Safe List）に、自社ドメインや自社のメールアドレスを登録しないでください。
メールのFrom（ヘッダーFrom）とMAIL FROM（エンベロープ送信者）は、誰でも詐称できます。
自社ドメインを組織セーフリストに登録すると、攻撃者が自社ドメインを名乗って送ったなりすましメールまで、スパム判定を省略して配送されます。
さらに、Proofpointの後ろにMicrosoft 365を置いている構成では、Microsoft 365がProofpointのIPアドレスでSPFを評価するため、ProofpointでDMARC failと判定されたメールが、Microsoft 365ではDMARC passになることがあります。
この状態では、DMARCのポリシーをp=quarantineやp=rejectにしても、なりすましメールは社員の受信トレイに届きます。
社内システムの通知メールなど、確実に届けたいメールがある場合は、ドメインではなく、その送信元のIPアドレスで登録してください。

Proofpointなどのメールセキュリティゲートウェイには、特定の送信者からのメールをスパム判定の対象外にする「セーフリスト」の機能があります。
社内システムの通知メールが迷惑メールとして扱われるのを避けるために、自社ドメインをセーフリストに登録している組織があります。
しかし、この設定は、攻撃者に「自社ドメインを名乗れば、迷惑メールフィルターを通過できる」という抜け道を与えます。
この記事では、MailDataがDMARCの分析支援で確認した事例をもとに、なりすましメールが届く仕組みと、Proofpoint側とMicrosoft 365側で確認すべき設定を解説します。

この記事の要点：

1. MailDataが確認した事例

要点: 自社ドメインを名乗る外部からのメールが、ProofpointでDMARC failと判定されたうえで配送され、Microsoft 365ではDMARC passと判定されて受信トレイに届いていました。

MailDataが、DMARCの分析支援で、ある組織から「迷惑メールが届いたが、DMARCのポリシーを隔離（p=quarantine）にすれば迷惑メールフォルダーに入るか」という相談を受けました。
（2026年11月）
この組織は、MXレコードがProofpointを指し、メールボックスはMicrosoft 365という構成でした。
届いたメールのヘッダーから読み取れた事実は、次のとおりです。

次は、この事例のヘッダーから、説明に必要な部分を抜き出したものです。
ドメイン名とIPアドレスは例示用のものに置き換え、行の順序と形式を簡略化しています。
上ほど後に付加されたヘッダーで、下から上に読むと、メールがたどった経路の順になります。 


X-MS-Exchange-Organization-SCL: -1
Authentication-Results: spf=pass (sender IP is 192.0.2.177)
 smtp.mailfrom=example.co.jp; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=example.co.jp;
Received: from mx0a-0000000.pphosted.com (192.0.2.177) by
 (Microsoft 365のサーバー)
X-Proofpoint-Spam-Reason: orgsafe
Authentication-Results: (Proofpointのサーバー);
 spf=softfail smtp.mailfrom=support@example.co.jp;
 dmarc=fail header.from=example.co.jp
Received: from (攻撃者のサーバー) ([198.51.100.10]) by
 mx0a-0000000.pphosted.com
From: support@example.co.jp

Proofpointが付けた判定（下半分）はDMARC failです。
ところが、Microsoft 365が付けた判定（上半分）はDMARC passになっています。
DMARCのポリシーを変更するだけでは、このメールは止まらないと判断しました。

2. なりすましメールが通過する3か所

要点: ①Proofpointの組織セーフリスト、②Microsoft 365でのSPFの評価、③SCLを-1にするメールフロールールの3か所を、なりすましメールが通過しています。どれか1か所を直すだけでは、十分ではありません。

攻撃者が自社ドメインを名乗って送ったメールが、自社のProofpointでDMARC failと判定されたうえで組織セーフリストにより配送され、自社のMicrosoft 365ではProofpointのIPアドレスでSPFが評価されてDMARC passとなり、SCLを-1にするルールでフィルターも省略されて、自社の社員の受信トレイに届く流れを示した図。下段に、①から③のそれぞれへの対処を示している。
自社ドメインを組織セーフリストに登録している場合のなりすましメールの流れと、①〜③への対処

① Proofpoint：組織セーフリストによるスパム判定の省略

組織セーフリストは、管理者が組織全体に対して設定するセーフリストです。
Proofpointの管理画面では、「Email Protection」→「Spam Detection」の下にあります。
（KnowBe4「Whitelist in Proofpoint」。Proofpoint自身の資料ではありません。）
受信者ごとに設定する個人のセーフリストもあります。

WithSecureのMessaging Security Gatewayのサポート記事は、迷惑メールが受信者に届いた原因の1つとして、送信者のアドレスが組織または個人のセーフリストにあったために、スパムスコアが0に変更された例を挙げています。
この製品の管理画面にも、同じ「Email Protection」→「Spam Detection」→「Organizational Safe List」というメニューがあります。
（WithSecure「Spam message has passed through Messaging Security Gateway (MSG) to a recipient」）
これはProofpoint自身の資料ではありません。
Proofpoint on DemandやProofpoint Protection Serverの管理者向けドキュメントは、公開されている範囲では確認できませんでした。

X-Proofpoint-Spam-Reason: orgsafeの値の定義も、Proofpointの公開資料では確認できませんでした。
ただし、名前と上記の挙動から、組織セーフリスト（Organizational Safe List）に一致したため、スパム判定を省略して配送したことを示していると考えられます。
この事例のFromは自社ドメインのアドレスだったため、自社ドメインまたはそのアドレスが、組織セーフリストに登録されていた可能性が高いと判断しました。

Proofpointの中小規模向け製品であるProofpoint Essentialsの公式ドキュメントは、ドメイン全体をセーフリストに登録することは、ドメインのなりすまし対策を無効にするため推奨しない、と明記しています。
（Proofpoint Essentials「Safelisting Addresses」）
組織セーフリストは、Fromを詐称するだけで条件を満たせるため、攻撃者にとって最も簡単な抜け道になります。

この記事の「組織セーフリスト」は、Proofpoint on DemandやProofpoint Protection Serverなど、大規模向けの製品の機能を指しています。
中小規模向けのProofpoint Essentialsでは、管理画面の「Security Settings」→「Email」→「Sender Lists」にある会社全体のSafe Sender Listが、同様の機能に相当します。
Safe Sender Listには、メールアドレス、ドメイン、IPアドレスを登録でき、登録された送信者のメールは隔離されません。
ユーザーごとのSender Listもあり、ユーザーは隔離メールの通知（ダイジェスト）から登録でき、管理者は「User Management」→「Users」から確認できます。
（Proofpoint Essentials「How to edit Safe and Blocked Sender Lists」）
また、「Security Settings」→「Email」→「Filter Policies」で、Allowのアクションを持つ受信フィルターを作って登録する方法もあります。
（Proofpoint Essentials「Safelisting Addresses」）
製品と機能の名称は異なりますが、送信者のアドレスやドメインを条件にして判定を省略する点は同じです。
Proofpoint Essentialsでも、自社ドメインを条件にして登録すれば、同じ抜け道ができます。

② Microsoft 365：直前の中継サーバーのIPアドレスでSPFを評価する

SPFは、メールを受信するSMTPのやり取りの中で、接続してきたサーバーのIPアドレスを、MAIL FROMのドメインのSPFレコードと照合する仕組みです。
RFC 7208は、SPFの検査を、メールを受信するSMTPトランザクションの処理中に行うべきである（SHOULD）としています。
（RFC 7208 Section 2.5）
また、SPFの評価は、「最後に」送信したSMTPサーバーのIPアドレスに基づくため、途中に仲介者が入ると、仲介者のIPアドレスで評価されることも説明しています。
（RFC 7208 Section 10.3）

MXがProofpointを指している構成では、Microsoft 365に接続してくるのはProofpointのサーバーです。
Microsoft 365が、接続元のProofpointのIPアドレスでSPFを評価すると、元の送信元が攻撃者のサーバーであることは評価に反映されません。
自社のメールをProofpoint経由で送信している組織では、自社のSPFレコードにProofpointのSPFレコード（include:spf-○○○○.pphosted.comのような形式）を含めています。
そのため、Microsoft 365では、自社ドメインを名乗るなりすましメールでもSPF passとなり、MAIL FROMとヘッダーFromが同じ自社ドメインであれば、DMARC passとなります。

Microsoft Learnは、この構成のための機能として、コネクタの拡張フィルター処理（Enhanced Filtering for Connectors）を説明しています。
この機能は、ドメインのMXレコードがMicrosoft 365を指していないシナリオを対象としており、ソースIPアドレスと送信者情報を保持するとされています。
（Microsoft Learn「Exchange Onlineでのコネクタの強化されたフィルター処理」）

③ Microsoft 365：SCLを-1にするメールフロールール

SCL（Spam Confidence Level）は、Microsoft 365がメールに付ける迷惑メールの可能性の値で、-1はスパムフィルター処理を省略したことを示します。
前段のゲートウェイでスパム判定を済ませているという考えから、ゲートウェイ経由のメールのSCLを-1にするメールフロールール（トランスポートルール）を設定している組織があります。
この場合、前段のProofpointを通過したメールは、Microsoft 365の迷惑メールフィルターやなりすまし対策の判定を受けずに配信されます。
前段で組織セーフリストによって判定が省略されると、どこでもスパム判定を受けないまま、受信トレイに届くことになります。

Microsoft Learnは、コネクタの拡張フィルター処理を有効にした後は、そのコネクタを通過するメッセージに対してSCLを-1に設定するメールフロールールを無効にする必要があるとしています。
例外として、Microsoft Defender for Office 365の評価モードを使っている場合と、多層防御の構成を段階的に行っている場合が挙げられています。
（Microsoft Learn「Exchange Onlineでのコネクタの強化されたフィルター処理」）

3. DMARCのポリシーを強化しても止まらない理由

要点: Microsoft 365でDMARC passと判定されている限り、自社のDMARCのポリシーは適用されません。DMARCのポリシーの強化は、①〜③を直してから効果を持ちます。

DMARCのポリシー（p=quarantineやp=reject）は、DMARCで不合格になったメールの扱いを、ドメイン所有者が受信側に伝えるものです。
Microsoft 365でDMARC passと判定されたメールには、自社のポリシーは適用されません。
つまり、この構成のままDMARCのポリシーをp=quarantineにしても、このなりすましメールは、Microsoft 365の迷惑メールフォルダーには入りません。

では、Proofpoint側では、DMARCのポリシーに従って隔離や拒否が行われるでしょうか。
これは、Proofpoint側でDMARCのポリシーに従った処理がどのように設定されているかと、その処理と組織セーフリストのどちらが優先されるかによります。
この優先関係は、Proofpointの公開資料では確認できませんでした。
自社の設定で、DMARC failのメールがどの段階で、どのように処理されているかを、Proofpointの管理画面とログで確認してください。
なお、Proofpoint側で隔離した場合、メールはOutlookの迷惑メールフォルダーではなく、Proofpointの隔離領域に格納されます。

MailDataは、DMARCのポリシーをp=quarantineで止めずにp=rejectまで進めることを推奨しています。
ただし、この記事の構成では、ポリシーをp=rejectにする前に、①〜③を直しておく必要があります。
p=rejectへの進め方は、DMARCでp=rejectにするためのプロセスで解説しています。

4. 自社で想定される被害

要点: 自社ドメインからのメールは、社員が最も信用するメールです。社内の部署や役員を名乗るフィッシングやビジネスメール詐欺（BEC）が、迷惑メールの警告なしに受信トレイに届きます。

自社の組織セーフリストに自社ドメインが登録されていて、Microsoft 365側も上記の状態であれば、次のような被害が想定されます。

社内の部署を名乗るフィッシング
情報システム部門やヘルプデスクを名乗り、「パスワードの有効期限が切れます」「メールボックスの容量が上限に達しました」といった文面で、偽のログインページに誘導するメールが届きます。
差出人が自社ドメインで、迷惑メールの警告も表示されないため、社員が正規の社内連絡と区別するのは困難です。
役員を名乗るビジネスメール詐欺（BEC）
社長や役員のアドレスを名乗り、経理部門に至急の送金や、取引先の振込先の変更を指示するメールが届きます。
社内システムの通知を装ったマルウェアの配布
複合機のスキャン通知や、ワークフローシステムの承認依頼などを装い、悪意のある添付ファイルやリンクを含むメールが届きます。
組織セーフリストによってスパム判定が省略されると、迷惑メール以外の検査がどこまで行われるかは、製品と設定によります。
この点は、Proofpointの公開資料では確認できませんでした。

自社ドメインを使ったなりすましメールは、自社がDMARCを運用していれば、外部の受信側では拒否や隔離の対象になります。
ところが、この構成では、最も守るべき自社の社員宛てのメールだけが、DMARCの保護から外れます。

5. 自社が該当するかの確認方法

要点: 社員に届いた不審なメールのヘッダーで、Proofpointの判定とMicrosoft 365の判定を見比べます。あわせて、Proofpointの組織セーフリストと、Microsoft 365のコネクタとメールフロールールを確認します。

メールのヘッダーで確認する

社員に届いた、自社ドメインを名乗る不審なメールのヘッダーで、次の点を確認します。

メールのヘッダーは、無料のメールヘッダ診断で確認できます。
ヘッダーは、下から上に向かって、メールがたどった経路の順に読みます。
ProofpointとMicrosoft 365が、それぞれどの判定を付けたかを、区別して読んでください。

Proofpointのログで確認する

orgsafeの値の定義は、公開資料では確認できません。
ヘッダーの値だけで判断せず、Proofpointのログで、そのメールが組織セーフリストに一致したことを確認してください。
WithSecureのMessaging Security Gatewayのサポート記事では、「System」→「Smart Search」でメッセージを検索してSID（メッセージの識別子）を調べ、「Logs and Reports」→「Log Viewer」でそのSIDのフィルターのログを確認する手順が説明されています。
（WithSecure「Spam message has passed through Messaging Security Gateway (MSG) to a recipient」）
これはProofpoint自身の資料ではないため、メニューの名称や位置は、お使いの製品と版で確認してください。

設定を確認する

Proofpointの組織セーフリスト
自社ドメイン、自社のメールアドレス、自社ドメインのサブドメインが、送信者のアドレスやドメインを条件として登録されていないかを確認します。
管理画面の「Email Protection」→「Spam Detection」の下にある「Organizational Safe List」で確認できます。
メニューの名称と位置は、製品と版によって異なる場合があります。
詳細な手順は、Proofpointのサポートポータルの管理者向けドキュメントを参照してください。
Proofpointの個人のセーフリスト
社員が、自社ドメインや同僚のアドレスを、個人のセーフリストに登録していないかを確認します。
個人のセーフリストに一致した場合も、スパムスコアが0に変更されることがあります。
（WithSecure「Spam message has passed through Messaging Security Gateway (MSG) to a recipient」）
登録されていた場合は削除し、自社ドメインのアドレスを個人のセーフリストに登録しないよう、社員に周知してください。
Microsoft 365の受信コネクタ
Proofpointからの受信コネクタで、コネクタの拡張フィルター処理が有効になっているかを確認します。
設定は、Microsoft Defenderポータルの「Email & collaboration」→「Policies & rules」→「Threat policies」→「Enhanced filtering」で確認できます。
（Microsoft Learn「Exchange Onlineでのコネクタの強化されたフィルター処理」）
Microsoft 365のメールフロールール
Proofpoint経由のメールのSCLを-1にするルール（「スパム フィルター処理をスキップする」アクション）がないかを確認します。
あわせて、自社ドメインを条件にしてスパムフィルターを省略するルールがないかも確認します。

6. 対処法

要点: 優先度が最も高いのは、Proofpointの組織セーフリストから自社ドメインを削除することです。そのうえで、Microsoft 365側でProofpointより前の送信元IPアドレスを使って判定させ、SCLを-1にするルールを見直します。削除後は正規のメールが止まっていないかを監視し、テストメールで対処の結果を確認します。

(1) Proofpoint：組織セーフリストから自社ドメインを削除する

組織セーフリストから、自社ドメイン、自社のメールアドレス、自社ドメインのサブドメインを削除します。
これを行えば、この事例のメールは、Proofpointでスパム判定の対象になり、Proofpoint側の判定に従って処理されます。
3つの対処の中で、最も優先度の高い対処です。

社内システムの通知メールなど、確実に届けたいメールのために登録している場合は、ドメインではなく、そのシステムの送信元のIPアドレスで登録してください。
送信元のIPアドレスは、攻撃者が詐称できません。
登録するIPアドレスの範囲は、その送信元が使うものだけに限定します。
多くの組織が共用するクラウドサービスのIPアドレス範囲を登録すると、同じサービスを使う第三者からのメールまで、判定が省略されます。

さらに根本的な対処は、そのシステムのメールがSPFとDKIMでアラインし、DMARCに合格するようにすることです。
DMARCに合格する正規のメールであれば、セーフリストに頼らずに届けられます。
セーフリストへの登録は、認証の設定が終わるまでの一時的な措置と考えてください。
Proofpoint Essentialsの公式ドキュメントも、送信元の認証の問題は、送信ドメインの所有者がSPF、DKIM、DMARCのレコードを修正することが、長期的で恒久的な解決策であるとしています。
（Proofpoint Essentials「How To Bypass Anti-Spoofing Checks」）

自社ドメインを削除すると、これまでセーフリストによって届いていた社内システムの通知メールが、隔離や迷惑メールの判定を受けることがあります。
削除する前に、DMARCの集計レポートで、自社ドメインをヘッダーFromに使っている送信元を洗い出し、SPFとDKIMでアラインしていない送信元を確認してください。
削除した後は、しばらくの間、Proofpointの隔離領域とMicrosoft 365の検疫を確認し、正規のメールが止まっていないかを監視します。
止まった正規のメールがあれば、その送信元をSPFとDKIMでアラインさせ、それまでの間は、送信元のIPアドレスの狭い範囲で登録します。

(2) Microsoft 365：コネクタの拡張フィルター処理を有効にする

Proofpointからの受信コネクタで、コネクタの拡張フィルター処理を有効にします。
これにより、Microsoft 365は、Proofpointより前の送信元（この事例では攻撃者のサーバー）のIPアドレスでSPFを評価し、自社ドメインを名乗るなりすましメールは、Microsoft 365でもDMARCに不合格になります。
これは、Proofpointをすり抜けたメールに対する二段目の対策です。

スキップするIPアドレスの指定方法には、「最後のIPアドレスを自動的に検出してスキップする」と「コネクタに関連付けられているこれらのIPアドレスをスキップする」があります。
Microsoft Learnは、最後のメッセージソースだけをスキップすればよい場合に、前者を推奨しています。
ProofpointからMicrosoft 365に直接配送している構成では、通常は前者が該当します。
Proofpointとの間に別の中継サーバーを挟んでいる構成など、スキップすべきサーバーが複数ある場合は、後者でIPアドレスの一覧を指定します。
適用対象は、最初に少数のユーザーでテストし、問題がなければ組織全体に広げる方法が推奨されています。
解説と設定手順は、次のページに記載されています。
（Microsoft Learn「Exchange Onlineでのコネクタの強化されたフィルター処理」）

(3) Microsoft 365：SCLを-1にするルールを見直す

コネクタの拡張フィルター処理を有効にした後は、Proofpoint経由のメールのSCLを-1にするメールフロールールを無効にします。
（Microsoft Learn「Exchange Onlineでのコネクタの強化されたフィルター処理」）
この設定を行ったうえでDMARCのポリシーをp=quarantineにすると、Microsoft 365のフィッシング対策ポリシーの設定に従って、迷惑メールフォルダーへの移動または検疫が行われます。

また、送信者のドメインだけを条件にしてスパムフィルターを省略するメールフロールールも、見直してください。
Microsoft Learnは、スパムフィルターをスキップする条件として送信者ドメインのみを使うと、攻撃者が送信ドメインをなりすまし、すべてのスパムフィルター処理と送信者認証チェックをスキップして受信トレイに届けられる可能性が大幅に高くなる、と警告しています。
所有しているドメイン（承認済みドメイン）を、メールフロールールの条件として使わないようにとも記載されています。
（Microsoft Learn「クラウド メールボックスの送信者許可リストを作成する」）
Proofpointの組織セーフリストに自社ドメインを登録することは、Microsoft 365でこの警告に反するルールを作ることと同じ構造です。

(4) DMARCのポリシーをp=rejectまで進める

(1)〜(3)を行った後に、DMARCのポリシーをp=rejectまで進めます。
DMARCの集計レポートで正規の送信元を洗い出し、SPFとDKIMでアラインさせてから、ポリシーを強化します。
外部の受信側で自社ドメインのなりすましメールを止めるのは、DMARCのポリシーです。

(5) 対処後に確認する

対処後に、自社が管理する外部のメールサーバーから、自社ドメインをMAIL FROMとヘッダーFromに使ったテストメールを、自社の検証用のアドレスに送って確認します。
確認する点は、次のとおりです。

テストメールは、自社が管理するサーバーから、自社の検証用のアドレスにだけ送ってください。
第三者のメール送信サービスで他社のドメインを名乗ることは、そのサービスの利用規約に反する場合があります。

ヘッダーの判定だけで結論を出さない
この記事の説明には、ヘッダーの情報から推測した部分が含まれます。
実際に対処する前に、Proofpointの組織セーフリストの登録内容と、Microsoft 365のコネクタとメールフロールールの設定内容を確認してください。
メールリレーの経路そのものを変更する必要は、通常はありません。

7. よくある誤解

「DMARCのポリシーをp=quarantineにすれば、なりすましメールは迷惑メールフォルダーに入る」
受信側でDMARC failと判定されなければ、ポリシーは適用されません。
この記事の構成では、Microsoft 365がProofpointのIPアドレスでSPFを評価するため、なりすましメールがDMARC passになります。
Microsoft 365側でコネクタの拡張フィルター処理を有効にしないと、ポリシーを変えても迷惑メールフォルダーには入りません。
「自社ドメインからのメールは、社内から送られたものなので安全」
メールのFromとMAIL FROMは、誰でも詐称できます。
自社ドメインからのメールが社内から送られたものかどうかは、SPF、DKIM、DMARCの認証結果で判断します。
送信者のアドレスやドメインだけで信頼するセーフリストは、この判断を省略します。
「Proofpointで検知できているので、問題ない」
この事例では、ProofpointはDMARC failと正しく判定していました。
しかし、組織セーフリストによって配送され、後段のMicrosoft 365では判定がpassに置き換わっていました。
検知していることと、止めていることは別です。
「Microsoft 365側でSCLを-1にしていても、Proofpointで判定しているので二重に判定する必要はない」
前段のゲートウェイで判定が省略されたメールは、SCLを-1にするルールがあると、どこでも判定を受けずに届きます。
Microsoft Learnも、コネクタの拡張フィルター処理を有効にした後は、SCLを-1にするルールを無効にする必要があるとしています。

8. まとめ ― 確認チェックリスト

メールの判定が、前段のゲートウェイと後段のメールボックスのそれぞれでどのように行われるかは、MTAの多層フィルタを理解するで解説しています。
Microsoft 365を経由した自社ドメインのなりすましについては、Microsoft 365のExchange Onlineを使っている場合は「Direct Send」を無効化しましょうもあわせてご覧ください。

参考資料