メール認証：SPF、DKIM、DMARC

SMTPの中核プロトコル（1970年代に設計されたもの）には、送信者認証が組み込まれていません。どのメールサーバーでも、任意のドメインからメールを送信したように見せかけることができます。この手法をメールスプーフィングと呼びます。攻撃者はこれを悪用し、正規の組織（銀行、CEO、既知の取引先など）から送信されたように見えるフィッシングメールを送ります。この問題に対処するため、DNSベースのメール認証標準としてSPF、DKIM、DMARCの3つが開発されました。それぞれがなりすまし問題の異なる側面に対処し、組み合わせて導入することで最も効果を発揮します。

SPFは、あるドメインに代わってメールを送信することを許可されたメールサーバーを指定するDNS TXTレコードです。受信側のメールサーバーがexample.comからのメールであると主張するメッセージを受信すると、example.comのSPFレコードを検索し、送信サーバーのIPアドレスが記載されているか確認します。IPアドレスが許可されていない場合、そのメッセージはスパムとしてマークするか、拒否できます。SPFが確認するのはエンベロープFromアドレス（SMTPのMAIL FROMコマンド）であり、ユーザーに表示されるFromヘッダーではありません。

SPFには2つの大きな制限があります。1つ目は、転送によってSPFが機能しなくなることです。メールが転送されると、転送サーバーのIPアドレスは元のドメインのSPFレコードに含まれていないため、正規に転送されたメールでもSPFが失敗します。2つ目は、SPFが認証するのはエンベロープFrom（ユーザーには表示されません）だけであり、メールクライアントに表示されるFromヘッダーではないことです。攻撃者は、SPFに合格するエンベロープFromを使用しながら、表示されるFromヘッダーをなお偽装できます。そのため、SPFだけでは不十分です。DKIMとDMARCがこれらの不足を補います。

DKIMは、送信メールに暗号学的署名を追加します。送信側のメールサーバーは秘密鍵を使用して特定のメールヘッダーと本文に署名し、DKIM-Signatureヘッダーを追加します。公開鍵は、セレクターのサブドメインにDNS TXTレコードとして公開されます。受信側サーバーは公開鍵を取得して署名を検証し、メールが転送中に改ざんされていないこと、また秘密鍵にアクセスできるサーバーから送信されたことを確認します。DKIM署名はメールヘッダーに含まれるため、SPFとは異なり、転送されても維持されます。

DKIMのセレクターを使用すると、1つのドメインで複数の公開鍵を同時に利用できます。これは、複数のメールサービス（Google Workspaceとマーケティングプラットフォームなど）を運用する場合や、サービスを中断せずに鍵をローテーションする場合に便利です。セレクター名はDKIM-Signatureヘッダーに含まれるため、受信側サーバーは検索すべきDNSレコードを特定できます。組織は、DKIM鍵を毎年、または鍵が侵害された疑いがある場合にローテーションする必要があります。鍵の長さについては、最低でも2048ビットのRSA鍵が推奨されます。1024ビット鍵は非推奨であり、最新の計算能力によって解読可能です。

DMARC（Domain-based Message Authentication, Reporting, and Conformance）は、SPFとDKIMを基盤として、次の機能を追加します。アライメントチェック（表示されるFromヘッダーのドメインが、SPFまたはDKIMで認証されたドメインと一致している必要があります）と、メッセージが認証に失敗した場合の処理を受信側サーバーに指示するポリシーです。DMARCポリシーには、none（監視のみ）、quarantine（迷惑メールフォルダーに配信）、reject（配信しない）があります。またDMARCでは、ドメイン所有者に送り返される集計レポート（RUA）とフォレンジックレポート（RUF）を利用でき、自分のドメインに代わって誰がメールを送信しているかを把握できます。

アライメントがあることで、DMARCはヘッダースプーフィングに対して強力に機能します。SPFアライメントでは、SMTPエンベロープのFromに含まれるドメインが、表示されるFromヘッダーのドメインと一致する必要があります。DKIMアライメントでは、署名に使用されたドメイン（DKIM-Signatureのd=）がFromヘッダーのドメインと一致する必要があります。厳格モードでは、ドメインが完全に一致しなければなりません。緩和モードでは、サブドメインも許容されます。SPFまたはDKIMのいずれかに適切なアライメントで合格すれば、メールはDMARCに合格します。両方に合格する必要はありません。この組み合わせにより、SPFだけでは防げない表示ヘッダーのスプーフィングの抜け道が塞がれます。

正規のメールを妨げないように、組織はDMARCを段階的に導入する必要があります。第1段階：すべてのメール送信経路にSPFとDKIMを導入します。第2段階：RUAレポートを有効にしたp=noneのDMARCレコードを公開します。レポートを分析し（ツール：DMARC Analyzer、dmarcian）、2～4週間かけて正規の送信元をすべて特定します。第3段階：p=quarantine; pct=10に移行し、pctを徐々に100%まで引き上げます。第4段階：すべての正規の送信経路が合格することを確認してから、p=rejectに移行します。すべてのメール送信経路を特定する前にrejectへ急いで移行すると、正規のメールまで拒否されます。

BIMIは、DMARCを基盤とする新しい標準です。ドメインのDMARCポリシーがquarantineまたはrejectの場合、メールクライアント（Gmail、Apple Mail）は、受信トレイで送信者名の横にブランドの認証済みロゴを表示できます。BIMIには、商標の所有権を確認する、承認された発行者によるVerified Mark Certificate（VMC）が必要です。BIMIはまだSecurity+試験の範囲ではありませんが、認証済みの送信者とスプーフィングされた送信者を一目で視覚的に区別できるようにする、メール認証の方向性を示しています。

この3つの標準によって、完全なメール認証システムが構成されます。SPFは、送信サーバーがドメイン所有者によって認証されているかを確認します。DKIMは、メッセージの完全性と、送信組織が秘密鍵を保有していることを確認します。DMARCは、両者を表示されるFromヘッダーに関連付け、失敗時のポリシーを適用し、レポートを提供します。単独で十分な標準はありません。SPFだけでは表示ヘッダーのスプーフィングを防げず、DKIMだけでは失敗時の拒否を義務付けられず、SPFやDKIMを使わないDMARCだけでは照合対象がありません。ドメインスプーフィングから完全に保護するには、3つすべてを組み合わせて導入する必要があります。

フィッシングやBECに対する実践的な多層防御策として、組織外から送信されたすべてのメッセージに外部メール警告バナーを追加する方法があります。このバナーは通常SEGによって挿入され、表示名が同僚や役員のように見える場合でも、メールが外部の送信者から届いたことを従業員に知らせます。バナーは、攻撃者が類似ドメインや表示名のスプーフィングを使用するBEC攻撃を見つけるうえで特に効果的です。バナーは視覚的に目立つようにし（色付きのヘッダーやフッターなど）、疑わしいメッセージの報告方法も記載する必要があります。

このレッスンで扱ったCompTIA Security+（SY0-701）の概念について、理解度を確認します。

このレッスンでは、次のことを学びました。SPFはDNS TXTレコードを使用して送信元IPを認証しますが、確認するのはエンベロープFromだけで、表示されるヘッダーは確認しません。DKIMは暗号署名を追加し、メッセージの完全性を検証するとともに、転送後も検証可能にします。DMARCは、アライメントチェックと適用可能なポリシー（none／quarantine／reject）、およびレポート機能によって、SPFとDKIMを表示されるFromヘッダーに関連付けます。次は、セキュアメールゲートウェイとスパム対策について学びます。