主なポイント
- SCL -1 は、スパムフィルターが完全に回避されたことを意味し、メールが安全であることを示すものではありません。
- Microsoft 365は、メールの処理方法を決定するために、-1から9までのSCLスコアを割り当てます。
- 同一テナント内では、内部認証済みメールは自動的にSCL -1を取得します。
- 「スパムフィルタリングをバイパス」を設定するメールフロー規則が、SCL -1 の最も一般的な原因です。
- Outlookの安全な送信者リストは、特定のアドレスに対してSCL -1を引き起こす可能性があります。
- 広範なIPホワイトリストとコネクタベースのバイパスルールは、フィッシングリスクを高める。
- DMARC Passは、攻撃者が自身のドメインを認証できるため、SCLを-1に設定する正当な理由とはならない。
高度なフィッシング詐欺の罠がCEOの受信箱に届く場合、その背景にはSCL -1タグが付与されていることが多々あります。このタグは、送信者をあらゆるセキュリティチェックポイントを素通りさせるVIPパスのデジタル版とも言えるものです。 Microsoft 365において、SCL -1は安全の証ではなく、スパムフィルターの完全なバイパスを意味します。本来は信頼できるトラフィック向けに設計されていますが、誤設定された許可ルールやコネクターが意図せず攻撃者に赤じゅうたんを敷く結果となり、悪意のあるコンテンツを最も機密性の高いユーザーに直接届けてしまうのです。
スパム信頼度(SCL)とは何か?
スパム信頼度レベルとは、メッセージがMicrosoftのフィルタリング層(Exchange Online ProtectionまたはMicrosoft Defender for Office 365)によって処理された後に割り当てられる値であり、そのメッセージがスパムである可能性を示すものです。
SCLスコアの活用方法
このサービスは、送信者の信頼性、コンテンツ分析、認証ステータスなどの様々なシグナルを用いてメールをスコアリングします。そのスコアに基づき、組織のスパム対策ポリシーに従ってメッセージの処理方法が決定されます。
典型的なSCLスコア範囲
| SCLスコア | 意味 | 実施された措置(標準) |
|---|---|---|
| -1 | バイパス | フィルタをスキップしました;メッセージは受信トレイに配信されました。 |
| 0, 1 | スパムではありません | メッセージが受信箱に配信されました。 |
| 5, 6 | スパム | メッセージが迷惑メールフォルダに送信されました。 |
| 9 | 高信頼度スパム | メッセージが迷惑メールフォルダに送信されたか、隔離されました。 |
SCL -1とは何を意味しますか?
SCL -1 をバイパスインジケーターとして
SCL値が-1であることは、内容分析に基づく「スコア」ではないという点で独特です。これはポリシー主導のステータスであり、メッセージが内容スキャナーによる評価が行われる前にスパムフィルタリングの対象から除外されたことを示します。
SCL -1は良いのか悪いのか?
- 良い点:重要な内部通信や安全性が確認済みの自動アラート(サーバー通知など)が誤って削除されることがない。
- 悪い点:巨大なセキュリティ上の死角を生む。攻撃者がなりすましや誤設定された「許可」リストの悪用によってSCL -1バイパスを成功させた場合、その悪意のあるペイロードは一切の審査を経ずにユーザーの受信トレイに直接到達する。
なぜ今これが重要なのか:現代の攻撃者は、AI生成のフィッシングメールや 侵害されたパートナードメインからの認証済みスパムを「正当な」ものに見せかけるためにますます利用している。こうした高度な罠がSCL -1バイパスに到達すると、ビジネスメール詐欺(BEC)を阻止するために必要な行動分析を回避する。人間がメールの偽造に気づく頃には、「信頼された」バイパスが既に侵害への道を開いているのである。
無料のドメインヘルススキャンで、現在ドメインにこれらの脆弱性があるかどうかを確認できます。
メールがSCL -1バイパスを受ける理由
いくつかの管理設定がSCL -1値を引き起こします:
信頼済みまたはホワイトリスト登録済み送信者
- 安全な送信者リスト:Outlookで個々のユーザーがアドレスを「安全な送信者」リストに追加すると、SCL -1がトリガーされる可能性があります。
- 転送ルール(メールフロールール):最も一般的な原因です。管理者が「送信者がXの場合、SCLを-1に設定する」というルールを作成します。
認証とポリシーベースのバイパス
- 認証済み内部メール:同一テナント内のメールボックス間で送信されるメールは自動的に信頼され、SCL -1 が割り当てられます。
- DMARC/SPF/DKIM: これらを通過したからといって自動的にSCL -1が保証されるわけではありませんが、多くの管理者はDMARCを通過したドメインに対してフィルタリングをバイパスするルールを誤って設定しています。設定ミスを避けるため、自動化されたSPFレコード生成ツールと DKIM生成ツールを使用し、レコードが有効であることを確認してください。
サードパーティおよびコネクタベースのシナリオ
- パートナー接続: パートナー組織と安全な接続を設定している場合、その経路を経由するメールはフィルタリングをバイパスする可能性があります。
- メールゲートウェイ:メールがMicrosoft 365に到達する前にサードパーティ製セキュリティゲートウェイを使用している場合、二重フィルタリングの問題を防ぐため、そのゲートウェイのIPアドレスに対してEOPフィルタリングをバイパスするルールを設定している可能性があります。
SCL -1はセキュリティ上のリスクか?
SCL -1はセキュリティリスクである場合もあれば、そうでない場合もある。
SCL -1が予想される場合
以下の場合、SCL -1 となるのは全く正常です:
- 社内人事発表。
- 内部サーバーからのシステムアラート(認証済みSMTPを使用)
- 認証済みで高セキュリティなパートナーコネクタからのメッセージ。
SCL -1が危険な場合
外部メールがこのスコアを保持している場合、リスクとなります。攻撃者は 表示名のなりすましや 類似ドメインを頻繁に利用します。メールフローのルールが広範すぎる場合(例:トップレベルドメイン全体をホワイトリスト登録)、攻撃者は防御を容易に突破できます。
- 警告:「バイパス」とは、メールがスパムフィルタリングを回避することを意味しますが、特定のDefender設定によっては、ゼロアワー自動パージ(ZAP)またはマルウェア対策エンジンによるスキャンが行われる可能性があります。ただし、バイパスされたメールに対する二次防御として、これらを絶対に頼りにしてはいけません。
DMARCとメール認証がSCLに与える影響

強力な認証シグナル(例: SPF、DKIM、DMARC 信頼の基盤です。
- DMARCアラインメント:メールが「DMARC Pass」となる場合、送信者が自称する本人であることを証明します。
- 罠:管理者は「DMARC = Pass の場合、SCL = -1 を設定する」というルールを設定する誤りをよく犯します。これは危険です。スパマーが正当なドメインを乗っ取り、DMARCを完璧に設定して「認証済み」スパムを送信できるからです。DMARC集計レポートをリアルタイムで監視し、「認証済み」スパムによるレピュテーションの悪用を阻止しましょう。
注:DMARCおよびメール認証プロトコルはスパムフィルターに代わるものではないことを理解することが重要です。DMARCはドメインのなりすましを防止しますが、悪意のあるコンテンツから保護することはできません。
PowerDMARCのようなソリューションを利用することで、「拒否」ポリシーを実現し、許可された送信者のみが自社ドメインを使用できるようにします。PowerDMARCは自社ドメインのなりすましを防止する予防策として機能しますが、受信コンテンツ分析のためのMicrosoftのスパムフィルタリングの必要性を代替するものではありません。
SCL-1メールの調査方法
メッセージヘッダーの確認
メッセージがバイパスされた理由を確認するには、メッセージヘッダー(Microsoft Message Header Analyzerを使用)を表示する必要があります。以下の項目を探してください:
- X-MS-Exchange-Organization-SCL: -1
- X-Forefront-Antispam-Report: SFV:SKN(スパムフィルタリング判定:スキップ)またはSFV:SKI(内部スキップ)タグを探してください。
朗報です。ヘッダーを即座に分析できます。PowerDMARCメールヘッダーアナライザーを使用すれば、SCLスコアとセキュリティ判定を数秒で解読できます。
メールフロー規則の確認
Exchange 管理センター (EAC) > メールフロー > ルールに移動します。アクションが「スパム信頼度レベル (SCL) を…に設定する」で「スパム フィルタリングをバイパスする」となっているルールを検索します。
SCL-1バイパス悪用の防止方法

SCL -1値は例外的なケースであるべきであり、常態化すべきではありません。外部送信者に対してこのバイパスが頻繁にメールフローヘッダーに表示される場合、事実上「玄関のドア」が開けっ放し状態です。正当なメールをブロックせずにセキュリティを強化するには、以下のベストプラクティスに従ってください:
1. 広範なIPアドレスおよびドメインのホワイトリスト登録を避ける
管理者が犯す最も一般的な過ちの一つは、一時的な配信問題を解決するためにIP範囲全体やトップレベルドメインをホワイトリスト登録することです。これは攻撃者にとって格好の標的です。攻撃者がホワイトリスト登録したプラットフォーム(共有ESPや侵害されたパートナーサーバーなど)からメールを送信した場合、SCL -1バイパスによりフィッシング攻撃がマイクロソフトのフィルターをすり抜けてしまいます。
- 修正方法: 広範なトランスポート ルールではなく、Microsoft Defenderポータル内のテナント許可/ブロック リストを使用して特定の送信者を管理します。
2. 「コネクタの高度なフィルタリング」を有効にする
メールが Microsoft 365 に到達する前にサードパーティのメールセキュリティゲートウェイを使用している場合、Microsoft がゲートウェイの IP をブロックしないようバイパスルールを設定している可能性があります。ただし、これにより元の送信者の実際の IP が隠蔽されることがよくあります。
- 修正方法:コネクタの拡張フィルタリング(別名: スキップリスト)を有効化します。これにより、Microsoftがゲートウェイを「透過」して元の送信元IPを認識できるようになり、技術的にバイパスが設定されている場合でもレピュテーションチェックが確実に機能します。
3. PowerDMARCで厳格なDMARCポリシーを実施する
攻撃者はしばしば自社内部ドメインを偽装し、メッセージを「内部」と認識させることで自動的にSCL-1をトリガーさせます。厳格なDMARCポリシーがなければ、Microsoftは自社のCEOとハッカーを見分けられない可能性があります。
- 修正方法:PowerDMARCを使用してドメインをp=rejectポリシーに移行します。これにより、認証に失敗したドメインを装ったメールは即座にブロックされます。自社ドメインを保護することで、「内部」信頼の悪用による危険なSCL -1バイパスを防止できます。
4. 「最小限の信頼」構成を使用する
完全なバイパスではなく、より細かい制御を使用してください。特定のパートナーのメールがスパムとして捕捉されている場合、単にそのSCLを-1に設定するだけではいけません。
- 修正方法:送信者を「安全」とマークするメールフロールールを作成し、Microsoftのゼロアワー自動削除(ZAP)とマルウェアスキャンを実行可能にします。あるいは、その送信者向けに一括メール閾値(BCL)を調整し、スパムとしてフラグ付けされないようにしつつ、脅威の有無を検査します。
まとめ
ヘッダーにSCL-1が表示されるのは、受信箱への「VIPバックステージパス」を誰かに渡すようなものです。社内のメモが迷惑フォルダに入らないようにするには有効ですが、外部メールでこれが発動すると重大なセキュリティ上の抜け穴となります。
広範な「許可」ルールや古いホワイトリストを設定している場合、それはMicrosoft 365に「目を閉じて運を天に任せる」よう指示しているようなものです。攻撃者はこうした回避策を見つけることを好みます。なぜなら、フィッシングリンクがユーザーの目に直接届く「フリーパス」を得られることを意味するからです。
ハッカーがドメインを偽装してこれらの「信頼された」バイパスをトリガーするのを防ぐ最善の方法は、厳重な DMARCポリシーを確立することです。
PowerDMARCは、リスクの高い「許可」リストから脱却し、確実に機能する「拒否」ポリシーへの移行を支援します。DMARC、SPF、DKIMの管理を自動化することで、本物の「あなた」だけがVIP待遇を受けられる一方、なりすましはSCLスキャナーに到達する前にゲートで阻止されます。
メールボックスに届く送信者を推測する日々に終止符を打ちませんか? 今すぐPowerDMARCの無料トライアルを開始し、メール認証を「たぶん」から「確実に」へ変えましょう。
よくあるご質問
SCL -1はメールが安全であることを意味しますか?
いいえ。それは単にスパムフィルターが回避されたことを意味するだけです。メールには依然としてフィッシングリンクや悪意のある添付ファイルが含まれている可能性があります。
攻撃者はSCL -1バイパスを悪用できるか?
はい、特にドメイン名に基づく広範な「許可」ルールや、設定が不十分なコネクタがある場合には特にそうです。
送信者からSCL -1を削除するにはどうすればよいですか?
セキュリティとコンプライアンス センターでメール フロー ルールまたは「テナントの許可/ブロック リスト」内のエントリを見つけ、削除または変更します。
外部メールにSCL -1を設定すべきか?
稀です。信頼できる第三者セキュリティ監査機関や緊密に連携したSaaSパートナーなど、特定のケースに限られます。

- Gmailで安全なメールを送信する方法:ステップバイステップガイド - 2026年4月7日
- Outlookで安全なメールを送信する方法:ステップバイステップガイド - 2026年4月2日
- SPF圧縮:SPFのDNSルックアップを削減し、SPFレコードを最適化 - 2026年3月25日


