送信ドメイン認証（SPF・DKIM・DMARC）の仕組みと違いを完全図解｜なりすましメール対策と過去問要点
電子メールは設計当初（SMTP策定時）に送信者の身元を検証する仕組みがなかったため、ヘッダの送信者アドレス（From:）を容易に偽装できます。これを防ぐための現代の業界標準が「送信ドメイン認証（SPF・DKIM・DMARC）」の3技術です。
情報処理技術者試験では、基本情報技術者（FE）から情報処理安全確保支援士（SC）まで、各認証プロトコルの動作原理、DNSレコードへの記述内容、およびメール転送時の弱点が繰り返し問われます。
1. 3大送信ドメイン認証の比較まとめ
技術名 | 認証の対象 | 検証の仕組み | メール転送時の耐性 | DNSレコードの種類 |
|---|---|---|---|---|
SPF (Sender Policy Framework) | 送信元メールサーバのIPアドレス | 送信ドメインのDNSに登録されたSPFレコード（許可IPリスト）と、接続元IPを照合 | × (転送時に送信元IPが変わるため失敗する) | TXTレコード (v=spf1 ip4:... ~all) |
DKIM (DomainKeys Identified Mail) | メール本文および主要ヘッダ | 送信サーバが付与した電子署名を、送信ドメインのDNSに公開された公開鍵で検証 | ○ (本文・ヘッダが改変されなければ成功する) | TXTレコード (セレクタ._domainkey.example.com) |
DMARC | SPF/DKIMの検証結果とHeader-Fromの一致（アライメント） | 認証失敗時のメールの扱い（none / quarantine / reject）とレポート集計 | ○ (SPFまたはDKIMのいずれかが成功すればパス) | TXTレコード (_dmarc.example.com) |
2. 各技術の動作メカニズム詳細
① SPF（IPアドレスベースの認証）
- DNS TXTレコードの記述例: v=spf1 ip4:192.0.2.1 include:_spf.google.com ~all
- クオリファイア（末尾の記号）の意味: -all（Fail: 不一致は受信拒否）、~all（SoftFail: 不一致でも受信し不審マーク付与）、?all（Neutral: 判断保留）、+all（Pass: 全許可・非推奨）。試験では「-all」と「~all」の挙動差が問われます。
② DKIM（電子署名ベースの認証）
- 署名と公開鍵の配置: 送信メールサーバはメール送信時に秘密鍵でヘッダ・本文のハッシュ値に電子署名を付与（DKIM-Signatureヘッダ）。受信サーバは送信ドメインのDNSからセレクタ名を使って公開鍵を取得し、署名を検証します。
- メリット: 途中のメール中継・転送が行われても、メール本文や署名対象ヘッダが書き換えられない限り署名検証に成功します。
③ DMARC（認証結果の統合とポリシー強制）
- DMARCポリシーの3段階: 1. p=none（何もしない・モニタリングログのみ受信） 2. p=quarantine（隔離・迷惑メールフォルダへ振り分け） 3. p=reject（受信拒否・バウンス）
- DMARCアライメントの重要性: SPFで検証したエンベロープFrom（Return-Path）やDKIM署名ドメインが、ユーザーがメールソフトで目にする「Header From」と同一ドメインであるかを厳密に照合します。
3. 試験で差がつく頻出過去問ポイント
- 「送信者を自社メールサーバで認証する技術」と「受信者が送信元を検証する技術」の区別: クライアント（従業員）が自社のSMTPサーバに接続する際に本人確認を行うのは「SMTP-AUTH」です。一方、外部の受信メールサーバが送信元ドメインの正当性を検証するのが「SPF / DKIM / DMARC」です。この主語の違いを設問文から見落とさないようにしましょう。
- メール転送サービスにおけるSPFの誤判定リスク: メーリングリストや転送サービスを経由すると送信元IPアドレスが転送サーバのIPに変わるため、SPFのみだとSoftFail/Failになります。DKIMを併用することで転送時でもなりすまし判定を回避できます。
この記事に関連する教科書用語
おすすめの関連記事
編集・検証について
編集・検証：IT資格ラボ編集部
IPAが公開する試験要綱・シラバス・過去問題と、各技術の公式資料を優先して内容を確認しています。制度変更や誤りを確認した場合は、記事を見直して更新します。
編集方針・情報源・訂正方針を見る