インターネットの黎明期から存在するDNSとメール（SMTP）は、今日の私たちのコミュニケーションに不可欠な基盤ですが、その設計の古さからセキュリティ上の多くの課題を抱えています。特に、DNS応答の偽装（キャッシュポイズニング）や、メール送信者のなりすましは、フィッシング詐欺やマルウェア感染の温床となってきました。
情報処理安全確保支援士試験では、これらの古典的でありながら今なお深刻な脅威に対し、どのような技術で対策するのかが問われます。DNSSEC, SPF, DKIM, DMARCといったアルファベット4文字の用語が頻出しますが、それぞれの役割と関係性を正確に理解できているでしょうか？
本記事では、まずDNSの応答をいかにして信頼できるものにするか（DNSSEC）を解説し、それを土台として、なりすましメール対策の三種の神器である「SPF」「DKIM」「DMARC」がどのように連携して機能するのかを体系的に解き明かします。
この記事を読めば、各技術がパズルのピースのように組み合わさり、DNSとメールという古くからのプロトコルの信頼性を高めていく全体像が見えるようになるでしょう。
目次
DNSの応答を信頼できるものにする│DNSSECによるキャッシュポイズニング対策
メールセキュリティを語る前に、その根幹を支えるDNS（Domain Name System）のセキュリティを理解する必要があります。DNSは、www.example.comのようなドメイン名を192.0.2.1のようなIPアドレスに変換する、インターネットの住所録のような役割を担っていますが、この応答が偽装されると、利用者は気づかないうちに偽サイトへ誘導されてしまいます。
DNSの脆弱性：キャッシュポイズニング
DNSへの代表的な攻撃がDNSキャッシュポイズニングです。これは、DNSサーバ（キャッシュDNSサーバ）に偽のDNS応答を送りつけ、汚染された情報をキャッシュ（一時保存）させる攻撃です。一度キャッシュが汚染されると、そのサーバを利用する全てのユーザが、正規のドメイン名を入力しても攻撃者の用意した偽サイトのIPアドレスを教えられてしまいます。
身近な例え ☎️
あなたがスマホの電話帳（キャッシュDNSサーバ）で「A銀行」を検索したとします。攻撃者が事前にあなたの電話帳に侵入し、「A銀行」の電話番号を「詐欺グループの電話番号」に書き換えていたらどうなるでしょう？あなたはA銀行に電話しているつもりで、詐欺グループと話してしまうことになります。これがキャッシュポイズニングです。
対策の要：DNSSEC
このDNS応答の「正しさ」を保証する拡張機能がDNSSEC（DNS Security Extensions）です。DNSSECは、PKI（公開鍵基盤）と同様のデジタル署名の仕組みをDNSに導入します。
DNSSECが導入されたドメインでは、DNSの各レコード（IPアドレスなどの情報）に、そのレコードが正当であることを証明するデジタル署名が付与されます。キャッシュDNSサーバは、受け取ったDNS応答の署名を検証することで、その応答が「途中で改ざんされていない」かつ「正規の権威DNSサーバから来たものである」ことを確認できます。
仕事での利用例 🏢
企業のセキュリティ担当者は、自社のドメイン（example.com）にDNSSECを設定し、自社のWebサイトやメールサーバのDNS情報が偽装されないように対策します。これにより、顧客がフィッシングサイトに誘導されたり、偽のメールサーバにメールを送信したりするリスクを低減できます。
DNSSECによってDNS応答の信頼性が担保されて初めて、後述するSPFやDKIMといったメールの送信ドメイン認証技術も、その真価を発揮することができるのです。
なりすましメールの温床│SMTPの仕組みと送信ドメイン認証が必要な理由
なぜ、迷惑メールやフィッシング詐欺は、あたかも実在する企業や知人から送られてきたかのように見せかけることができるのでしょうか？その根本的な原因は、メール送信プロトコルであるSMTP（Simple Mail Transfer Protocol）のシンプルな設計にあります。
SMTPの性善説に基づいた設計
SMTPが作られた当初のインターネットは、ごく限られた研究者などが利用する、性善説に基づいた世界でした。そのため、SMTPには送信者の正当性を検証する仕組みが組み込まれていません。
身近な例え 📮
これは、手紙やハガキの仕組みに似ています。手紙を送る時、差出人欄に「内閣総理大臣」と書いたとしても、郵便局はそれを検証することなく、宛先に配達してくれます。SMTPもこれと同じで、メールのヘッダに書かれているFrom:アドレス（送信元アドレス）を、送信サーバが自由に設定できてしまうのです。
2種類の「From」
厳密には、メールには2種類の送信元情報があり、この違いがなりすましを理解する上で重要です。
| 種類 | 説明 | 例えるなら |
|---|---|---|
| ヘッダFrom | メールソフトで受信者が「差出人」として目にするアドレス。自由に設定可能。 | 手紙の便箋に書かれた「〇〇より」という署名 |
| エンベロープFrom | サーバ間でメールを配送する際に使われるアドレス。宛先不明時の返送先。 | 封筒に書かれた「差出人住所」 |
攻撃者は、受信者が目にするヘッダFromを偽ることで、受信者を簡単に騙すことができます。
送信ドメイン認証の登場
このSMTPの根本的な弱点を補い、「そのメールが、本当にそのドメイン（例: @example.com）から正当に送信されたものか」を受信側で検証できるようにする技術が送信ドメイン認証です。
具体的には、これから解説する以下の3つの技術（SPF, DKIM, DMARC）をDNSと連携させることで、なりすましメールを検知し、ブロックすることが可能になります。
送信元IPアドレスを検証する「SPF」の仕組みと限界
送信ドメイン認証技術の第一歩がSPF（Sender Policy Framework）です。これは、「私のドメイン（@example.com）からのメールは、このIPアドレスのサーバからしか送りませんよ」という宣言を、ドメインの所有者がDNSに公開しておく仕組みです。
SPFの仕組み
受信側のメールサーバは、メールを受け取ると、そのメールを送信してきたサーバのIPアドレスと、送信元ドメインのDNSに公開されているSPFレコードを照合します。
身近な例え 🤵♂️
これは、有名人（ドメイン）が、自身の公式サイト（DNS）に「私からの公式なメッセージは、この公認のSP（送信サーバ）を通じてのみ発表します」とリストを公開するようなものです。
メディア（受信サーバ）は、メッセージを持ってきたSPが公式サイトのリストに載っているかを確認します。リストにないSPからのメッセージは、偽物の可能性が高いと判断できます。
（SPFレコードの例）
example.com. IN TXT "v=spf1 ip4:192.0.2.1 -all"
これは、「example.comからのメールは192.0.2.1から送信します。それ以外はすべて不正です (-all)」という意味です。
SPFの限界：ヘッダFromは見ていない
SPFは非常に有効な技術ですが、重大な限界があります。それは、SPFが検証するのは、サーバ間の通信で使われるエンベロープFromのドメインであり、受信者が目にするヘッダFromのドメインは一切検証しないという点です。
そのため、攻撃者はエンベロープFromを詐称せず、受信者を騙すためのヘッダFromだけを有名な企業（例：From: info@your-bank.com）に偽装することができてしまいます。この場合、SPF認証は成功（Pass）するにもかかわらず、受信者はなりすましメールに騙される、という事態が起こりえます。
また、メールが転送されると、転送サーバのIPアドレスがSPFレコードに記載されていないために認証に失敗してしまう、という問題もあります。このSPFの弱点を補うために、次に解説するDKIMが必要となるのです。
電子署名で改ざんを検知する「DKIM」の仕組み
SPFが送信元サーバの「場所」（IPアドレス）を検証するのに対し、DKIM（DomainKeys Identified Mail）はメールそのものにデジタル署名を付与することで、「送信者（ドメイン）の正当性」と「メール内容の完全性（改ざんされていないこと）」を証明する技術です。
DKIMの仕組み
DKIMでは、送信ドメイン側が事前に公開鍵と秘密鍵のペアを作成しておきます。
- 鍵の準備: 送信ドメインは、公開鍵をDNSにTXTレコードとして公開し、秘密鍵を自社の送信メールサーバに厳重に保管します。
- 署名の付与: 送信サーバは、メールを送信する際に、メールのヘッダや本文から算出したハッシュ値を秘密鍵で暗号化します。これが「デジタル署名」となり、メールヘッダ（
DKIM-Signature）に付与されます。 - 署名の検証: 受信サーバは、メールに付与されたデジタル署名を、送信元ドメインのDNSから取得した公開鍵を使って復号します。そして、受信したメールから自身で計算したハッシュ値と比較します。
- 結果: 両者が一致すれば、「このメールは確かにそのドメインから送信され、かつ途中で改ざんされていない」と判断できます。
身近な例え 📜
これは、差出人が特殊な判子（秘密鍵）で封蝋をした手紙に似ています。
- SPF: 配達人が、差出人の会社が認めた公式の配達人かどうかをチェックする。
- DKIM: 手紙そのものに、差出人の会社しか持っていないはずの社判が押されているか、そして封蝋が破られていないかをチェックする。
SPFの弱点を補完
DKIMは、SPFが抱える2つの大きな問題を解決します。
- ヘッダFromの検証: DKIMの署名は、受信者が目にするヘッダFromを含む主要なヘッダ情報を対象にできるため、SPFではできなかった送信者名のなりすましを検知できます。
- メール転送への耐性: 署名はメール自体に含まれているため、途中でメールが転送されても署名は維持されます。これにより、SPFでは認証失敗となっていたメーリングリストなどを経由したメールでも、正しく検証できます。
このように、SPFとDKIMはそれぞれ異なる側面からメールの信頼性を検証する技術です。両者を組み合わせることで、なりすましメール対策はより強固になります。そして、この2つの技術を統合的に扱うのが、次に解説するDMARCです。
SPFとDKIMを統合し、受信ポリシーを宣言する「DMARC」
SPFとDKIMによって、受信サーバはメールがなりまされている可能性を検知できるようになりました。しかし、それだけでは不十分です。「認証に失敗したメールを、受信サーバにどう扱ってほしいのか」を送信側が指定できなければ、対策は受信側の裁量に委ねられてしまいます。
この最後のピースを埋めるのがDMARC（Domain-based Message Authentication, Reporting, and Conformance）です。
DMARCの2つの役割
DMARCは、送信ドメインの所有者がDNSにDMARCレコードを公開することで、受信サーバに対して以下の2つを伝えます。
- ポリシーの宣言: SPFかDKIM、いずれかの認証に失敗したメールをどう扱うか（何もしない・隔離・拒否）を指示する。
- 結果の報告: 認証結果の統計レポートを送ってもらうための宛先を指定する。
身近な例え 📦
これは、メーカー（送信ドメイン）が、税関（受信サーバ）に対して出す「偽ブランド品の取り扱い指示書」です。
「弊社製品を名乗る荷物が届いたら、まず正規の輸送業者（SPF）か、製品の封蝋（DKIM）を確認してください。どちらか一方でも怪しい点があれば、この指示書に従ってください。指示書には『偽物は即座に破棄（ポリシー: reject）』とあります。また、どのような偽物が見つかったか、月末に報告書（レポート）を送ってください」
DMARCレコードの主要なタグ
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:report@example.com"
| タグ | 意味 | 説明 |
|---|---|---|
p |
ポリシー (Policy) | 認証失敗時のアクションを指定。none（何もしない）, quarantine（迷惑メールへ隔離）, reject（受信拒否）の3段階がある。 |
rua |
レポート宛先 | 認証結果の集計レポート（XML形式）を受け取るメールアドレスを指定する。 |
アライメント：最後の砦
DMARCが強力なのは、アライメント（Alignment）という概念があるからです。これは、SPFやDKIMで検証されたドメインと、受信者が目にするヘッダFromのドメインが一致していることを要求するものです。これにより、SPFやDKIMの認証をパスしつつヘッダFromだけを偽装する、巧妙ななりすましも防ぐことができます。
DMARCは、SPFとDKIMを補強し、送信ドメイン認証を完成させるための司令塔の役割を担っているのです。
まとめ：3つの技術を連携させ、メールの信頼性を高める
本記事では、DNSとメールというインターネットの根幹を支えるプロトコルのセキュリティについて解説してきました。DNS応答の信頼性をDNSSECで担保した上で、送信ドメイン認証の3つの主要技術を見てきました。
- SPF: 送信元サーバのIPアドレスを検証する
- DKIM: メールの電子署名を検証する
- DMARC: 上記2つの結果に基づき、メールの取り扱いポリシーを指示する
これらの技術は、単体で使うのではなく、組み合わせて多層的に防御することで真価を発揮します。
なりすましメール対策の全体像
3つの技術の関係性を、VIP向けの厳重なセキュリティチェックに例えてみましょう。
- SPFチェック
「会場に到着したリムジンが、事前に届け出のあった公認車両リストに載っているか？」
（サーバの正当性をチェック） - DKIMチェック
「招待状に、特殊なインクで押された本物の紋章があり、封が破られていないか？」
（メールの正当性と完全性をチェック） - DMARCポリシー
「車両リストにないか、招待状が偽物だった場合、その人物は門前払いとし、警備日誌に記録せよ」
（ポリシーの適用と報告）
このように、複数の異なる観点から検証を行うことで、巧妙になりすました攻撃者を見破ることができるのです。
送信ドメイン認証技術の早見表
| 技術 | 検証対象 | 検証方法 | 例えるなら |
|---|---|---|---|
| SPF | 送信サーバのIPアドレス | DNSに公開されたIPリストとの照合 | 公認の配達人リスト |
| DKIM | メールの内容と送信元ドメイン | DNSに公開された公開鍵による電子署名検証 | 差出人の特殊な判子が押された封蝋 |
| DMARC | SPF/DKIMの検証結果とドメインの一致性 | DNSに公開されたポリシー（拒否/隔離）の適用 | 偽造品に対する取り扱い指示書 |
午後試験では、これらの技術がどのように連携し、どのような攻撃を防ぐのかを問う問題が頻出します。それぞれの役割と関係性をしっかり整理しておきましょう。