応用情報技術者 2016年 秋期 午前2 問43

SPF（送信元ドメイン検証）【午前2解説】

正解の理由

解法ステップ

1. SPFの目的を思い出す：送信元ドメインの詐称（なりすまし）検出。
2. SPFの実装方法を確認：送信ドメインのDNS（主にTXTレコード）に許可する送信元を列挙する。
3. 受信側の動作を考える：SMTPで接続してきた送信元のIPアドレスを、MAIL FROM（Return-Path）やHELO/EHLOで使われるドメインのSPFレコードと照合する。
4. 選択肢を比較：DNSBL参照や受信者PCでのハッシュ照合はSPFの手順に該当しないため除外する。

選択肢別の誤答解説

• ア: 「送信元IPから送信元ドメインを検索してDNSBLに照会」
  誤り。DNSBL（IPのブラックリスト）はスパム判定に使われることがあるが、SPFの検証手順は「送信元ドメインのDNSにあるSPF（TXT）レコードと送信元IPを照合する」ことであり、DNSBL参照を必須とするものではありません。
• イ: 正しい。受信側メールサーバが接続元IPと送信元ドメインのDNSに記載された許可IP（SPFレコード）を照合する動作を述べています。
• ウ: 「送信元ドメインから送信元メールサーバのIPを検索してDNSBLに照会」
  誤り。SPFはドメイン側に許可IPを置き、受信側が接続IPと照合する方式です。DNSBL照会は別処理であり、SPFの本質を外しています。
• エ: 「受信者のPCがドメインから算出したハッシュ値と受信メール添付のハッシュを照合」
  誤り。メッセージの署名やハッシュ照合はDKIMに近い概念ですが、DKIMでは送信側が秘密鍵で署名し、受信側（通常は受信メールサーバや検証エージェント）が送信元ドメインのDNSに公開された公開鍵で署名を検証します。受信者のPCが必ず照合するわけではありませんし、これはSPFの動作ではありません。

よくある誤解

• SPFは「From: ヘッダ」を検証すると思っている
  → 実際は主にSMTPのMAIL FROM（Return-Path）やHELOドメインを基に検証します。メールクライアントの表示用FromヘッダはSPFの検証対象とならないため、表示上の差異に注意が必要です。
• SPFがあればメール偽装は完全に防げると思う
  → SPFは有効ですが、転送を受けると元の送信IPと転送先の接続IPが異なり検証が失敗することがあります（転送問題）。そのためDKIMやDMARCと組み合わせて運用するのが実務的です。
• DKIM検証は必ず受信者PCが行うと思っている
  → DKIMの署名検証は通常受信メールサーバや検証エージェントが行います。送信側が秘密鍵で署名し、検証は受信側がDNSにある公開鍵で行う点を押さえてください。

補足コラム

• SPFレコードの例（DNS TXTレコード）

v=spf1 ip4:203.0.113.5 include:_spf.example.com -all

• v=spf1: バージョン指定
• ip4:許可するIPv4アドレス
• include: 他ドメインのSPFを参照
• -all: これ以外は拒否（fail）
• SPFの結果には一般に pass / fail / softfail / neutral などがあり、受信側ポリシーによって扱い（受信拒否・隔離・受信許可など）が異なります。
• DKIMはメッセージの改ざん検出に向き、署名は送信者側の秘密鍵で行い、公開鍵は送信ドメインのDNSに公開され、受信側で検証されます。DMARCはSPFとDKIMの結果を利用して送信ドメインのポリシー（処理方法）を指定します。

FAQ