「認証済み」「暗号化済み」だけでは安全とは判断できない送信ドメイン認証はドメインのなりすまし、暗号化は盗聴、無害化や検査は危険なコンテンツに対する対策です。それぞれの保護対象を押さえ、複数の対策を組み合わせます。

メールの流れと対策の位置

利用者がメールを送信サーバーへ渡す「投稿」と、メールサーバー同士が配送する「中継」を分けると、SMTP-AUTHやOP25Bの役割が見えてきます。次は代表的な構成を簡略化したものです。

  1. 送信端末
    メールを作成する。S/MIMEを使う場合は、ここで署名・暗号化する。
  2. 投稿
    送信サーバーへメールを渡す。SMTP-AUTHで利用者を認証し、TLSで接続を保護する。
  3. 中継
    送信側MTAから受信側MTAへ配送する。DKIM署名を付与し、受信側でSPF・DKIM・DMARCを検証する。
  4. 受信検査
    添付ファイルやURLを検査し、ポリシーに応じて隔離・無害化する。
  5. 受信端末
    メールを読む。S/MIMEを使う場合は復号・署名検証を行い、業務上の依頼内容も確認する。

MTA（Mail Transfer Agent）は、メールの配送・中継を担当するソフトウェアです。S/MIMEを端末間で利用する構成では、中継サーバーは暗号化された本文をそのまま扱います。

1. 送信ドメイン認証 ― ドメインのなりすましを見分ける

SPF：接続元IPアドレスが許可されているか

SPF（Sender Policy Framework）は、ドメイン管理者がDNSのTXTレコードで送信を許可するサーバーを示し、受信側が接続元IPアドレスを照合する仕組みです。

主に検証するのはSMTPの MAIL FROM で指定されるエンベロープFromのドメインです。これはメールソフトに表示されるヘッダーの From: とは別の情報です。SPFが成功しても、表示上の差出人ドメインが正しいとは限りません。HELO/EHLOのドメインを検証する場合もあります。仕様は RFC 7208 を参照してください。

通常の転送では、受信側から見た接続元が転送サーバーに変わるため、元の送信者が正当でもSPFが失敗することがあります。また、SPFは本文の改ざん検知や暗号化を行いません。

DKIM：ドメインの電子署名を検証する

DKIM（DomainKeys Identified Mail）は、送信側が秘密鍵でメールに署名し、受信側がDNSで公開された公開鍵を使って検証する仕組みです。DKIM-Signature ヘッダーの d= が署名ドメイン、s= が鍵を識別するセレクターを表します。

検証によって、署名ドメインの責任の下で付けられた署名であることと、署名対象の本文・ヘッダーが検証可能な状態で保たれていることを確認できます。署名は必ずしも全ヘッダーを対象にせず、個人の本人確認を直接行うものでもありません。署名ドメインと表示上のFromドメインが一致する保証も、DKIM単体にはありません。仕様は RFC 6376 を参照してください。

転送で接続元IPが変わっても、署名対象が保たれていれば検証できます。一方、配送途中でメーリングリストが件名や本文を変更すると、署名が検証できなくなる場合があります。DKIMは署名の技術なので、メール本文は暗号化されません。

DMARC：表示上のFromと認証ドメインを結び付ける

DMARC（Domain-based Message Authentication, Reporting, and Conformance）は、SPF・DKIMの結果に加えて、ヘッダーFromのドメインとの整合（アライメント）を確認する仕組みです。SPFまたはDKIMの少なくとも一方が成功し、その認証ドメインがFromドメインと整合していることが、DMARC成功の条件です。

整合の判定には、ドメインの完全一致を求めるstrictと、組織ドメインの一致を認めるrelaxedがあります。単に「SPFかDKIMがpassならDMARCもpass」と覚えると、整合の条件を見落とします。

例：ヘッダーFromが example.comDMARCの判断
SPFは成功したが、そのドメインは別組織の attacker.example.net。整合するDKIM署名もない失敗。SPFの成功だけでは、表示上のFromを裏付けられない
SPFは失敗したが、d=example.com のDKIM署名が成功した成功。DKIMで認証成功と整合の両方を満たす

ドメイン管理者は _dmarc.example.com などのDNS TXTレコードで、DMARCに失敗したメールの扱いを受信側に要求します。

ポリシー意味
p=noneDMARCによる隔離・拒否を要求しない。レポートを別途設定し、認証状況の把握に利用できる
p=quarantine不審なメールとして扱うよう要求する。迷惑メールフォルダーへの振り分けなど
p=reject受信を拒否するよう要求する

最終的な処理は受信側のローカルポリシーにも依存します。認証結果の報告を受け取る仕組みも含め、DMARCの基本は RFC 7489 で説明されています。

DMARCが成功しても、依頼内容の正当性は分からない正規アカウントの乗っ取りや、よく似た別ドメインを使った詐欺では、送信ドメイン認証に成功する場合があります。認証結果だけで添付ファイルや送金依頼を信用しないことが大切です。

2. メールの暗号化と署名 ― 内容と通信経路を分ける

S/MIME：メールの内容を暗号化・署名する

S/MIME（Secure/Multipurpose Internet Mail Extensions）は、PKIの電子証明書を利用して、メールの本文や添付ファイルなどのMIMEコンテンツを暗号化・署名する技術です。端末間で利用すれば、送信者から受信者までのエンドツーエンドの保護ができます。

操作利用する鍵と目的
暗号化・復号本文を共通鍵で暗号化し、その鍵を受信者の公開鍵などで保護する。受信者は自身の秘密鍵を使って復号できる
署名・検証送信者の秘密鍵で署名し、受信者が送信者の証明書に含まれる公開鍵で検証する。署名者の確認と改ざん検知に使う

署名と暗号化は別の機能です。署名だけなら機密性は確保されず、暗号化だけでは送信者の署名を検証したことにはなりません。証明書の信頼性や有効性の確認も必要です。また、外側の配送用ヘッダーなど、メールの全情報が必ず暗号化されるわけではありません。仕様は RFC 8551 を参照してください。

STARTTLS：確立済みの接続をTLSへ切り替える

STARTTLSは、平文で開始したSMTPなどの接続を、途中からTLSで保護する仕組みです。SMTPでは、サーバーの対応を確認した後に STARTTLS コマンドを送り、TLSハンドシェイクを行います。暗号化されるのは、その接続区間です。SMTPでの仕様は RFC 3207 に定義されています。

メールが複数のサーバーを経由する場合、各区間のTLSは別々に確立されます。中継サーバーでは本文を読めるため、S/MIMEによる内容の暗号化とは保護範囲が異なります。

TLSが使えないと平文配送に戻るopportunistic TLSの運用では、暗号化は保証されません。TLSの必須化や証明書検証の扱いを確認する必要があります。また、465番ポートで使われるImplicit TLSは、接続の最初からTLSを開始する方式です。投稿・受信アクセスでの使い分けは RFC 8314 を参照してください。

3. サーバー・ネットワーク側の対策 ― 不正な送信を防ぐ

SMTP-AUTH：送信サーバーを利用するユーザーを認証する

SMTP-AUTHは、SMTPの AUTH コマンドなどで利用者を認証する拡張仕様です。メールソフトから送信サーバーへ投稿する際に、ユーザー名・パスワードやトークンなどで、送信サービスを利用できる相手か確認します。仕様は RFC 4954 を参照してください。

SPFが検証するのは送信ドメインとサーバーの関係、SMTP-AUTHが認証するのは接続してきた利用者です。SMTP-AUTHの利用だけで通信やメール本文が暗号化されるわけではなく、TLSも併用します。

OP25B：端末から外部への直接配送を遮断する

OP25B（Outbound Port 25 Blocking）は、ISPや組織のネットワークで、対象端末から外部のTCP25番ポートへの通信を遮断する対策です。マルウェアに感染した端末が、外部の受信メールサーバーへ直接スパムを配送することを抑えます。

通常の利用者は、指定された送信サーバーへ587番や465番ポートで認証して投稿します。そのサーバーが配送を担当するため、端末からの25番通信を制限してもメールを送れます。実施例は 東京大学生産技術研究所のOP25B解説 を参照してください。

TCPポート代表的な用途
25MTA同士の配送・中継。STARTTLSを使うこともある
587利用者から送信サーバーへの投稿。SMTP-AUTHとSTARTTLSを組み合わせる構成がある
465Implicit TLSによる、利用者から送信サーバーへの投稿

OP25Bが制限するのは対象ネットワークから外向きの25番通信です。受信メールの内容検査や、乗っ取られたアカウントによる認証済み送信を防ぐ機能はありません。

第三者中継の禁止：外部から外部への無許可の中継を拒否する

オープンリレーは、権限のない第三者から受け取ったメールを、無関係な外部宛先へ中継してしまう状態です。MTAで中継を許可するネットワークや認証済み利用者を制限し、スパムの踏み台になることを防ぎます。

ここで、自組織のメールアドレス宛てに外部から届くメールまで拒否してはいけません。「自組織宛ての受信」と「外部宛てへの中継」を区別し、後者に適切な権限を要求します。実装例は Postfixの中継・アクセス制御の解説 を参照してください。

4. メールを介した主要な攻撃 ― 何をさせようとしているか

BEC：業務上の信用を悪用して送金などを指示する

BEC（Business Email Compromise、ビジネスメール詐欺）は、経営幹部や取引先を装い、偽口座への送金などを促す詐欺です。メールアカウントを乗っ取ったり、似たドメインを使ったりして、本物のやり取りに紛れ込む場合があります。

マルウェアや不審な添付ファイルを使わず、文面だけで成立することもあります。振込先の変更や急な送金依頼は、メールに記載された連絡先をそのまま使わず、事前に登録した電話番号など別経路で確認し、複数人の承認を組み込みます。具体策は IPAのBEC対策 を参照してください。

標的型攻撃メール：特定組織の業務を装って侵入する

標的型攻撃メールは、特定の組織や担当者を狙い、取引、採用、会議、請求などに関係するように見せたメールです。添付ファイルの実行や悪意あるリンクへのアクセスを促し、マルウェア感染や情報窃取につなげます。

本文の自然さや、知っている相手の名前だけでは判断できません。予期しない添付ファイルやマクロの有効化要求を受けたら、送信元へ別経路で確認し、不審なメールを報告できる手順を用意します。

Emotetはメール経由で感染を広げたマルウェアの例ですが、Emotetのメールをすべて標的型攻撃と分類するのは適切ではありません。広範囲への配布にも使われ、過去のメールを悪用した返信風の文面なども確認されています。過去の攻撃例は JPCERT/CCのEmotetに関する注意喚起 で確認できます。

フィッシング：偽サイトなどで認証情報を盗む

フィッシングは、正規サービスを装ったメールなどから偽サイトへ誘導し、ID・パスワードやカード情報などを入力させて盗む攻撃です。「アカウント停止」「支払い失敗」といった文面で操作を急がせる場合があります。

メールのリンクからログインするのではなく、登録済みのブックマークや公式アプリから確認します。多要素認証も有効ですが、ワンタイムコードまで盗む手口があるため、対応サービスではパスキーなどフィッシング耐性のある認証方式も活用します。認証方式ごとの耐性は CISAのフィッシング耐性のある多要素認証の解説 を参照してください。

BEC・標的型攻撃・フィッシングは、必ずしも排他的な分類ではありません。標的型のフィッシングでアカウントを奪い、そのアカウントをBECに使うように、組み合わされることもあります。

5. 受信側の防御・検査 ― 危険なコンテンツを減らす

メール無害化：危険な機能を除去・変換する

メール無害化は、HTMLメールのテキスト化、URLリンクの無効化、添付ファイルの画像化、マクロの除去などによって、受信者が危険な機能を実行する機会を減らす対策です。ファイルの構造を解析し、許可した要素で再構成するCDR（Content Disarm and Reconstruction）も使われます。

CDRはウイルス名の検出だけに依存せず、不要なアクティブコンテンツを取り除く考え方です。実装例は FortinetのCDR技術資料 を参照してください。

変換によってレイアウトや業務で使う機能が失われる場合があります。また、文面だけの送金詐欺や、画像内のQRコードなどまで自動的に安全になるわけではありません。原本が必要な場合の確認手順も決めておきます。

サンドボックス解析：隔離環境で動かして振る舞いを見る

サンドボックス解析は、添付ファイルなどを隔離された環境で実行し、不審な外部通信、ファイルの生成、システム設定の変更などを観察する手法です。既知の特徴と照合する検査に加え、未知のマルウェアの検知にも役立ちます。

ただし、実行を遅らせる、解析環境を見分けて動作しない、特定の操作がないと発症しない、といった回避があるため、検知漏れは起こり得ます。隔離環境で動かなかったことは、安全の証明にはなりません。検知回避の例は Fortinetのサンドボックス技術資料 でも扱われています。

手法基本的な考え方
無害化・CDR危険につながる機能や構造を取り除き、利用できる内容を届ける
サンドボックス隔離環境で実際に動かし、観察した振る舞いから危険性を判断する

S/MIMEで暗号化された内容は、復号できない受信ゲートウェイでは検査できません。また、署名対象を無害化で変更すると署名検証に影響します。暗号化・署名を使う場合は、どこで復号・検証・無害化するかも設計上の論点になります。

試験で混同しやすいポイント

用語の説明には「対象」と「仕組み」を入れると、似た技術との違いが明確になります。問題文で何が起きているのかを確認し、対応する対策を選びます。

着目する情報・目的対応する技術と説明の要点
接続元IPとDNS上の送信許可SPF。エンベロープFromなどのドメインについて送信元を検証する
DNSの公開鍵とドメインの署名DKIM。署名ドメインと署名対象の完全性を検証する
Fromの整合と認証失敗時の扱いDMARC。SPFまたはDKIMの成功に加え、ドメインの整合を求める
メール内容の暗号化・署名S/MIME。証明書と鍵を使い、内容の機密性や署名者・改ざんを確認する
確立済み接続をTLSへ切り替えるSTARTTLS。接続区間を暗号化する
送信サービスを利用する人の認証SMTP-AUTH。投稿時に利用者を認証する
端末から外部25番への直接通信OP25B。ネットワークで外向きの通信を制限する
無関係な外部同士の配送依頼第三者中継の禁止。MTAで無許可のリレーを拒否する
危険な機能を取り除く／動きを観察する前者は無害化・CDR、後者はサンドボックス解析

公開鍵と証明書の基礎は サーバ証明書の基本、TLS接続の流れは TLSハンドシェイクの基本 も参照してください。