スパムメール、詐欺メール、フィッシングメールなど、メールにまつわるサイバー攻撃は常態化している。迷惑メールは無視すればいいだろうと、メールセキュリティを甘くみてはいけない。詐欺メールやフィッシングメールに騙される被害がなくならない理由は、攻撃者視点で考えると、攻撃成功率10％でも1000通メールを送れば100件のデータが集まる。そしてサイバー空間では10万件単位のメール送信など簡単である。

クラウドシステムにおいては、なりすましを含む不正アクセスが問題になっている。アカウントや権限の設定ミスも多いが、フィッシングメールでID・パスワードを盗まれることによっても発生する。盗んだアカウントでシステムにログインできればランサムウェアをはじめとしたマルウェアのインストールが可能だ。ランサムウェアに感染すると、システム停止、業務停止の影響がサプライチェーンまで及び、企業経営そのものに大ダメージを与える。

あるいは、メールに添付されたマルウェアや詐欺メールで攻撃サイトに誘導されランサムウェアをダウンロードしてしまうことにより被害が発生する場合もある。

サイバー攻撃だけではない。メールの誤送信によるトラブル、個人情報漏出といったインシデントもある。悪意はなく事故や不可抗力だとしても、対応コストや信頼棄損が企業にダメージを与える。

さらに、SPF、DKIM、DMARCといった送信ドメイン認証や暗号化など、適切なセキュリティ対策を施していないメールシステムから送られたメールは、クラウドサービスや企業システムによって不審なメール、リスクのあるメールとして分類されてしまう。正規のメールでも不達やフィルタリングではじかれてしまい、業務に支障がでる。2024年に高校受験のオンライン出願で、自治体の一斉通知メールがクラウドメールサービスにはじかれるという騒ぎが起きた。自治体側メールシステムが、Gmailの送信者ガイドラインに従っていなかったことが原因とされている。

メールセキュリティを考える上での大前提がひとつある。それは、

「インターネットメールのプロトコルにセキュリティ機能はない」

という点だ。初期のインターネットプロトコル全般に言えることだが、世界中に開放されたオープンネットワークを前提としているため、セキュリティ機能は必要最小限になっている。メール受信プロトコルであるPOP・IMAPはメールボックスにアクセスするためにID（ユーザー名）とパスワードを必要とする設計になっているが、送信のためのSMTPは、送信元の情報がでたらめでも（原理的には）送信可能だ。

もちろん、現在のSMTPやPOPにもセキュリティ機能の拡張はなされている。だが拡張機能でありすべてのシステムが同じレベルで実装されているわけではない。送信ドメイン認証などは、別プロトコルとしてメールサーバーやアプリで対応する必要がある。

この大前提を踏まえ、メールセキュリティで注意すべきポイントとして以下が考えられる。

コンプライアンスやBCPでは、これらに加えて障害時のバックアップシステム、誤送信対策といった機能も考えられる。

現在のメールシステムは、マルチメディアに対応しており、外部リンク、音声、画像、実行可能ファイルなどの多様な添付ファイル、メール機能を前提とした対策が求められている。ブラウザを利用するWebメールでは、一般的なメールプロトコル（SMTP/POP・IMAP4）ではなくHTTPSを利用しているものもある。

前述のポイントごとに具体的な対策やソリューション、注意点を見ていこう。

添付ファイル
添付ファイルは、標的PCやシステムにマルウェアを持ち込ませるために利用される。特定アプリのファイルを偽装したマルウェア、Officeツールのマクロ機能を利用したマルウェア（表面上はただの文書、表）、拡張子を偽装した実行可能ファイルなどが典型例だ。
添付ファイルはメールボックスなどストレージに保存されるので、通常のアンチウイルスソフトで検出できる場合もあるが、そもそも外部からくる添付ファイルは、汚染されている前提で検疫を行わなければ内部に保存すべきでない。

したがって、メールシステムもしくは、メールセキュリティシステムが、添付ファイルの素性や中身を受信と同時にチェックするほうが望ましい。

検知方法は、ファイル名やシグネチャ（マルウェアのハッシュ値）をブラックリストのデータベースと突き合わせて判別する方法、機械学習などAI技術を利用する方法（ブラックリストデータベースは必要ない）、サンドボックスで添付ファイルの振る舞いを調べる方法などがある。

添付ファイルは、セキュリティ上のリスクが高いとして、添付そのものをできないようにする考え方もある。ファイル共有サーバーなどを利用して、必要なファイルはクラウド経由でやりとりする。ファイル共有サーバー自体もリスクがあるので、メールセキュリティシステムが、添付ファイル専用のファイルサーバーを持つ場合もある。

このようなシステムでは、添付メールを送信すると、システムが自動的に添付ファイル部分を分離し、ファイルサーバー（クラウド）に移し替える。メール本文はID・パスワードで保護されたサーバー上リンクが追加される。これで正規メールサーバーのメールから、添付ファイルを排除できる。

不要・悪性メールの排除（フィルタリング）

スパムメールや詐欺、攻撃サイトへの誘導メールを排除するには、メールの送信元や本文、配信のルートに着目する。これらにマルウェアが添付されていることもあるが、悪性か攻撃意図があるかは、メールの内容や送信元のドメイン情報、転送径路情報から得ることができる。

フィルタのかけ方は、システムの機能や用途によってさまざまだ。セキュリティ要件が高いほど、ホワイトリストによって許可された送信元だけしか受信を許さない設定となる。たとえば安全な国からと思われるIPアドレスのみ許可する。把握している正規ドメイン名のメールアドレス以外を排除するといった運用だ。通常は、スパムメールや攻撃者が使うメールアドレスのデータベース（ブラックリスト）で、廃棄するメールを選別する。

メール本文からスパムメールや攻撃メールを判別する方法は、古くから存在する。機械学習など最近のAI技術を用いずとも、統計的な手法やエキスパートシステムで悪性判定をする技術は確立されている。

フィッシングメールは、フィッシングメールだけを集めたデータベースが存在する。PhishTank（https://phishtank.org/）は、コミュニティによって運営されているフィッシングの検証システムだ。フィッシングメールは、本文に誘導先の偽サイトのURLリンクが埋め込まれている。このURLやドメイン名がフィッシングメールで利用されているものか、されたものかを調べることができる。

フィッシングの誘導先（つまり偽造サイト）、マルウェアをダウンロードさせるページが、サーバー証明書によって署名されていることが当たり前になってきた。証明書があるかという基準で良性と判断することはできない。ドメインの発行元や証明書の認証局が、過去のサイバー攻撃に利用されているかという基準で判定することもある。

送信元の真正性（OP25B、送信ドメイン認証）

OP25Bは、大量のスパムメールを送信するためにプロバイダーのメールサーバーを踏み台にさせないための手法だ。原理的に送信元の詐称が簡単なメールプロトコルにおいて、この対策だけではすでに十分ではなく、より厳密に送信元の正しさを担保する必要がある。

現在、上場企業などを中心に、DMARC（Domain-based Message Authentication Reporting and Conformance）によって送信元がなりすましでないことを認証する技術が主流となりつつある。DMARCはSPFという送信元の証明書技術と、DKIMというメール本文の電子署名をベースとして、なりすましが疑われる場合、認証に失敗した場合のメールの処理、報告方法が規定されている。

これらの送信ドメイン認証技術は、メールサーバーだけで実現できず、DNSの設定レコード（MXレコード）に書き込まれた情報を利用している。逆にいえば、送信ドメイン認証を有効にするには、自分のメールサーバーを管理するDNSに適切な認証情報を設定しなければならない。

メールボックス保護（暗号化・整合性・証跡）

メールボックスは、プライバシーや個人情報保護の観点から適切な管理が求められる。外部からのアクセスは当然として、正規ユーザーだとしても、権限のない情報にアクセスできないようにしなければならない。

障害やトラブル発生時に、メールが消失する事態も防ぐ必要がある。メールボックスの適切なバックアップを行う。バックアップはランサムウェア被害からの復旧方法としても重要なので、アーカイブ保存ではなくリカバリを前提としたシステムが望ましい。

改ざんされていないことの証明が必要な場合もある。システムのデータはすべて整合性が保たれている状態が基本ではあるが、サイバー攻撃の解析（フォレンジック）や内部犯行を含むサイバー犯罪の捜査において、データの整合性やログなどの証跡が必要になる。メールシステムのセキュリティ機能として考えておきたい。

メールシステムによっては、To：欄に大量のメールアドレスが列挙されると、このまま送っていいか確認する機能がある。送信履歴や連絡帳のデータを利用して、宛先メールアドレスの入力中に、送信先の候補を表示してくれることもある。

これらは、メールの誤送信を防ぐための機能だ。送信ボタンを押してから間違いに気づいたときのために、実際の送信をキャンセルできる機能もある。誤送信防止や取り消しが確実にできるわけではないが、トラブル回避のため検討してもよい機能だ。

メールシステムやサービスの中に、添付ファイルメールを作成すると、自動的に添付ファイルをパスワード付ZIPでアーカイブし、パスワードだけを記載した別メールを作成して自動送信してくれる機能がある。このような機能は、できれば無効化しておきたい。

添付ファイルをパスワード付ZIPにして、パスワードは別メールで送る（PPAPなどとも呼ばれている）方式は、以前は安全に添付ファイルを送る方法として多くの企業が採用していた。だが、現在この方法は手間がかかる上、セキュリティ上意味がないとされ、むしろ非推奨の送信方法となっている。

添付ファイルが悪性かどうかを判定したいとき、添付ファイルが暗号化されていると、システムは自動的なチェックができない。また、攻撃者は添付ファイルの中身がチェックされることを知っているので、攻撃メールではあえて暗号化したファイルを添付してくることがある。PPAPを逆手にとってマルウェアを送り付けるわけだ。

当時は安全な添付ファイル送信方法として広がった。そのためメールセキュリティシステムが、機能として自動化するようになったのだが、セキュリティ要件や対策ソリューションは時代とともに変化する。PPAPの回避、DMARCなど送信ドメイン認証の設定、メール以外の連絡ツール（Slack、Teams、Zoom、その他メッセンジャー）の確保といった、状況や技術に応じた対策のアップデートも欠かせない。