概要
電子メールはSMTPプロトコルが設計された1980年代から送信元の認証機能を持たず、なりすましが容易です。SPF・DKIM・DMARCはこの問題を解決するために策定されたDNSベースのメール認証技術です。フィッシング対策の技術的基盤として、SC試験でも頻出のテーマです。
SMTPの送信元偽装問題
正規の送信：
From: support@example.com （実際にexample.comのサーバから送信）
なりすまし：
From: support@example.com （全く別のIPアドレスから送信可能）SMTPは送信元IPとFromアドレスを照合する仕組みを持っていません。
SPF（Sender Policy Framework）
仕組み
送信ドメインが「このIPアドレスからメールを送ってよい」をDNSのTXTレコードで公開します。
example.com のDNS TXTレコード：
v=spf1 ip4:203.0.113.1 include:_spf.google.com ~all
解読：
v=spf1 → SPFバージョン1
ip4:... → このIPv4アドレスから送信を許可
include:... → Googleのサーバからも許可（Gmail経由等）
~all → 上記以外はソフトフェイル（受信側が判断）
-all → 上記以外はハードフェイル（拒否を推奨）SPFの限界
- 転送メールに弱い：メーリングリスト・自動転送を経由すると送信元IPが変わりSPFが失敗する
- Fromアドレスではなく送信サーバを認証する：Envelope FromとHeader Fromが異なるケースに対応できない
DKIM（DomainKeys Identified Mail）
仕組み
送信サーバがメール全体（ヘッダ・本文）に秘密鍵でデジタル署名し、受信サーバがDNSの公開鍵で検証します。
送信時：
1. メールにDKIM-Signatureヘッダを追加
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail;
h=from:to:subject:date; bh=<本文ハッシュ>; b=<署名値>
受信時：
2. 受信サーバがmail._domainkey.example.com からDNSで公開鍵を取得
3. 署名を検証 → 改ざん・送信元偽装を検知DKIMの特徴
| 項目 | 内容 |
|---|---|
| 転送に強い：転送されてもヘッダの署名は維持される | SPFより転送に強い |
| メール内容の完全性も保証 | 途中での改ざんを検知できる |
| セレクタ（s=） | 複数の鍵を使い分けるためのラベル |
DMARC（Domain-based Message Authentication, Reporting & Conformance）
役割
SPFまたはDKIMのどちらが合格したかを判定し、合格しない場合の**ポリシー（何をすべきか）**をドメイン所有者が指定できます。
example.com のDNS TXTレコード（_dmarc.example.com）：
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100
解読：
p=none → 何もしない（モニタリングのみ）
p=quarantine → 迷惑メールフォルダへ（段階的移行に使用）
p=reject → 拒否する（最も強力）
rua=... → 集計レポートの送信先
pct=100 → ポリシーを適用する割合（100%）SPF・DKIM・DMARCの連携
受信メールの処理フロー：
1. SPFチェック：送信元IPが正規か？
2. DKIMチェック：デジタル署名が有効か？
3. DMARCチェック：SPFまたはDKIMが合格かつFromドメインと一致するか？
4. DMARCポリシー適用：
- 合格 → 通常配信
- 不合格 + p=quarantine → 迷惑メールへ
- 不合格 + p=reject → 拒否DMARCレポート
| レポート種別 | 内容 |
|---|---|
| 集計レポート（RUA） | ドメインから送信されたメールのSPF/DKIM結果集計（XML形式、日次） |
| フォレンジックレポート（RUF） | 失敗したメールの詳細（プライバシー懸念で廃止傾向） |
その他のメールセキュリティ技術
| 技術 | 説明 |
|---|---|
| MTA-STS | メールサーバ間の通信をTLS必須にする |
| DANE | DNSSECと組み合わせてメールサーバの証明書をDNSに登録 |
| BIMI | DMARCが設定されたドメインにブランドロゴを表示（視覚的偽装防止） |
| S/MIME | メールを暗号化・署名するエンドツーエンドの標準 |
SC試験での頻出ポイント
- SPFが確認するもの：送信サーバのIPアドレスがDNSに登録された許可リストにあるか
- DKIMが確認するもの：メール全体のデジタル署名が正しいか（改ざん・送信元偽装の検知）
- DMARCの役割：SPF/DKIMの結果に基づき、失敗したメールをどう扱うかのポリシーを指定
- SPFが転送に弱い理由：転送時に送信元IPが変わるが、Fromアドレスは変わらないためSPFが失敗する
- p=reject の意味：DMARCポリシーで認証失敗メールを受信サーバが拒否すること
よくある誤問・ひっかけパターン
誤り① 「SPFだけ設定すればフィッシングを完全に防げる」→ 誤。SPFはFrom表示とEnvelopeFromが異なる場合に対応できません。DMARCと組み合わせる必要があります。
誤り② 「DKIMはメール本文を暗号化する」→ 誤。DKIMはデジタル署名（改ざん検知・真正性確認）であり、暗号化ではありません。メール内容は誰でも読めます。
誤り③ 「DMARCはSPFとDKIMの両方が合格しないと通過できない」→ 誤。DMARCはSPFまたはDKIMのどちらか一方が合格し、かつFromドメインと整合していれば通過します。
関連用語
- DNSセキュリティ — SPF・DKIMはDNS TXTレコードを使用
- フィッシング・ソーシャルエンジニアリング — メール認証で防止できる攻撃
- 公開鍵暗号（RSA）とデジタル署名 — DKIMはRSAまたはECDSA署名を使用
重要キーワード
| 用語 | 説明 |
|---|---|
| SPF | 許可された送信元IPをDNSに登録してなりすましを防ぐ |
| DKIM | 秘密鍵でメールに署名し、受信側が公開鍵で検証する |
| DMARC | SPF/DKIMの判定結果に基づいた処理ポリシーを指定する |
| p=reject | DMARCポリシーで認証失敗メールを拒否する最も強力な設定 |
| RUA | DMARCの集計レポート。送信統計をドメイン所有者に送付 |
| BIMI | DMARCが設定されたドメインに送信者ロゴを表示する拡張規格 |