標的型攻撃メール訓練で“ブロック”を回避するための技術と運用対策
近年、企業のセキュリティレベルが向上し、EDRや次世代ファイアウォール、メールゲートウェイなどの導入が進んだ結果、**「標的型攻撃メール訓練のメールが受信者に届かない」**という問題が増加しています。
📌 訓練メールが届かない＝訓練そのものが成立しない
このような状況を回避するためには、技術的配慮と社内連携の両面からの対策が必要です。
本記事では、訓練メールの配信障害が起こる主な原因と、それを防ぐための具体的な対策について解説します。
❗ なぜ訓練メールがブロックされるのか？
標的型攻撃メール訓練で送信するメールがブロックされる主な理由は、企業内のセキュリティシステムがそれを「脅威」と誤認識することです。以下のような要因がよく見られます。
🔒 主なブロック原因：
- ✉️ SPF/DKIM/DMARC 設定の不備
→ 正当な送信者と判定されず、迷惑メール扱いに
- 🔗 不審なURL（短縮URL、未認証ドメインなど）
→ URLフィルタやCloud App Securityが遮断
- 🚫 メール本文や件名に“危険性が高い”と見なされる語句を含む
→ 例：「パスワードを再設定してください」「至急対応」など
- 📥 送信元IPアドレスやドメインがブラックリストに登録されている
→ 例：「SPAMHAUS」などのブラックリストに登録されているなど
- 🔐 HTMLメール内のスクリプトやCSS構文が過剰に装飾されている
→ 例：セキュリティシステムがJavaScriptを不審なものとしてブロック
標的型攻撃メール対応訓練実施キットを提供している弊社には「貴社のサービスを使えば訓練メールはブロックされずに届きますか？」といった主旨のご質問をいただくことが少なくないのですが、メールがブロックされるのは受信側のセキュリティシステムが原因であることがほとんどで、こうしたセキュリティシステムによるブロックを突破して訓練メールを強制的に届かせるといった魔法のようなことは流石にできません。
もし、そのようなことができるのであれば、攻撃者もその方法を見逃すはずはありませんので、今、導入されているそのセキュリティシステムは、意味が無いものということになってしまいます。
ですので、受信側で確実に訓練メールを受け取ることができるよう、セキュリティシステムの設定を調整する以外に、こうすれば必ず訓練メールが届くようになるといった確実な方法は存在しないということをまず認識することが必要です。
🔍 訓練メールが届かないと起こる問題
- 📉 正確なクリック率・開封率の測定ができない
- 🔄 社員全体に訓練が行き渡らず、リテラシー差が広がる
- ⚠️ 訓練効果の測定・改善が困難に
特に「一部の社員だけ受信できなかった」といったケースでは、部門別比較や行動分析の妥当性が損なわれるおそれがあります。
とはいえ、模擬も含め、セキュリティシステムが不審なメールをブロックすること自体は正しいことであるので、現実解としては、セキュリティシステムとどのようにうまく付き合っていくか？を考えるしかありません。
✅ トラブルを防ぐための注意点と具体策
✔ 1. 送信基盤の技術対策
- SPF／DKIM／DMARCの整合性を事前に検証
SPFレコードの確認、DKIM署名の有効化、DMARCポリシーの適切設定を行う
- 信頼性の高いIPアドレス／サーバーを使用
- 海外フリーメールサービスや不明なリレーサーバーは避ける
- 海外フリーメールサービスや不明なリレーサーバーは避ける
- SMTP送信元ドメインのホワイトリスト申請（可能な場合）
会社のメールサーバがどのようなセキュリティポリシーに則って運用されているかを確認することは、訓練メールが届かないというトラブルを避けるためには必須の作業です。
例えば、貴社のメールサーバが、SPFレコードのチェックにより正規のメールサーバ以外から送られているメールはブロックする運用となっている場合は、SPFに対応した差出人アドレスが使用できるメールサーバから訓練メールを送信することが必要となります。
外部のサービスを利用して訓練を実施する場合は、SPF/DKIM/DMARCに対応した訓練メールを送信できるかどうかはチェックしておきたいポイントです。
ちなみに、弊社が提供している標的型攻撃メール対応訓練実施キットでは、SPF/DKIM/DMARCに対応した訓練用のドメイン名が使えるようになっています。
✔ 2. メールコンテンツの最適化
- HTMLや件名に“過度な不安を煽る語句”を避ける
→ 例：「【至急】システム障害のお知らせ」「口座凍結」など
- URLはHTTPS化し、有効なSSL証明書を導入
→ 例：URLにドメイン名の代わりにIPアドレスを記載するとブロックされるなど - ドメイン名は疑似フィッシングとしても怪しすぎない設計に
→ 例：本物の攻撃で使われているドメイン名をリンクに使用するとブロックされるなど
セキュリティシステムはメーカーによって設計コンセプトが異なりますので、ブロックするルールにはそれぞれ特徴があります。このため、Aというシステムではブロックされるが、Bというシステムではブロックされないといったこともあります。
例えば同じ内容のHTMLでも、JavaScriptを末尾に記述するようにしたらブロックされなくなったという例や、改行を含めたらブロックされなくなったという例など、メールの内容を工夫することでブロックを回避できることもあります。
但し、ブロックされるロジックについてはシステムによって差異があるのと、システムは常にアップデートを繰り返しているため、こうすれば確実にできるといったもの、また、未来永劫変わらずに使える手法といったものはありません。
訓練メールを作成する側からすると厄介な話ではあるのですが、”こうすればブロックされることを回避することができます”といった情報は開示されることは無い（もし開示されたらあっという間に悪用されてしまう）ので、実際に訓練メールを作成して手探りで試すしかないのは、致し方ないところかと思います。
✔ 3. 社内セキュリティチームとの事前調整
- 利用しているメールセキュリティ製品の設定確認（例：Microsoft Defender for Office365、Proofpoint、FortiMail、Cisco ESAなど）
- フィルタ設定やURLスキャンの一時解除依頼を行う
- 「訓練目的」であることを正式に伝達し、例外ルールの適用を事前申請する
訓練メールをブロックしているのは企業内に導入されているセキュリティシステムである以上、セキュリティシステム側で訓練メールを通すようにすることが最も確実な対応策です。
しかし、企業によっては、訓練メールを通してしまうことがセキュリティホールになり得るとして許容しないところもあるでしょう。このような場合は、セキュリティシステムにブロックされないよう、訓練メールの内容を工夫するといったことが、担当者にできうる対策ということになります。
なお、使い勝手の良し悪しはありますが、Office365のようにメールシステムと一体で訓練サービスが提供されているようなシステムでは、メールシステムに付属する訓練サービスを用いることでブロックの問題を回避しやすくなるということはあるかと思います。
🧪 本番前の“テスト送信”は必須
いきなり全社員へ一斉送信せず、以下のような段階的運用が安全です：
- 社内の協力者3〜5名に対してテスト送信
- 受信状況・迷惑メールフォルダ格納・URLブロックの有無を確認
- 問題が発生したレイヤー（送信元、ゲートウェイ、PC側セキュリティ）を特定
- 必要に応じてセキュリティポリシー調整 → 再テスト
このプロセスを丁寧に行うことで、本番時のトラブルを最小限に抑えることができます。
なお、最近のセキュリティシステムでは不審なメールの内容を動的に学習してブロックするといったことが行われていますので、テストの時はうまくいったが、本番を実施している最中にシステムが学習して、途中からブロックされてしまうことは可能性としてゼロでは無いということは注意点としてお伝えしておきます。
🛡 訓練成功のために必要な「技術 × 運用」の連携
| 観点 | 実施事項 |
|---|---|
| 技術対応 | SPF/DKIM設定、HTML最適化、HTTPSリンクの活用 |
| 組織連携 | セキュリティ部門との例外設定調整、訓練計画の共有 |
| 運用工夫 | テスト送信→段階展開→全社展開という流れの徹底 |
標的型攻撃メール訓練は、“受信されなければ始まらない”。
そのためには、セキュリティシステムの高度化に合わせた技術・運用の最適化が不可欠です。
メールシステム及びセキュリティシステムの運用を担当する方とも連携し、テストを繰り返しながら訓練を実施することは、面倒な作業ではありますが、自社で導入しているセキュリティシステムの長所・短所を知ることができる絶好の機会でもあると考えれば、あながち無駄な作業でもないと言えるのでは無いでしょうか。
