今更ながらSender Policy Frameworkについて調べてみた

はじめに

最近、DMARCという単語を聞くことが増えてきたので、調べた中で何気なく使用している電子メールの認証技術について理解が浅いなと思い、勉強してきた記事です。
電子メールの基礎技術について知ることが出来る？と思います。

電子メール認証技術の成り立ち

いまや世界中で手足のように使われている電子メール。
電子メールは、「誰もが好きな送信元アドレスを名乗ることができる」 という特性を持っている。
ただ、これを利用した悪意のある送信者が企業や金融機関、友人になりすまして詐欺やマルウェアへ感染させようとする問題が多発したため、送信元を確認し認証する技術として Sender Policy Framework(以下、SPF) が生まれた。

Sender Policy Frameworkとは

SPFはMeng Weng Wong（モン・ウェン・ウォン）氏が2000年代初頭に提唱した技術が原型。
ドメインのDNSレコードを利用して送信者サーバのIPアドレスが、そのドメインの所有者によって許可されたものであるか確認する技術である。

SPFの基本的な仕組みと動作原理

DNS TXTレコードの利用

SPFの中心となる部分は、ドメインのDNS TXTレコードである。
ドメインの管理者は、自らのDNSサーバに「このドメイン名(例:example.com)のメールは、このIPアドレス群からしか送りませんよ」という情報をTXTレコードとして記述する。
このTXTレコードが、後の発展技術となるDKIM,DMARCでも活用されている。

例:　example.com. IN TXT "v=spf1 ip4:192.0.2.1/24 include:_spf.google.com ~all"

SPFの動作フロー

1. メール送信: 送信側のMTA（Mail Transfer Agent、メールサーバー）が、受信側のMTAへメールを送信する。

この時、SMTP通信の段階で「エンベロープFrom」として[e-mail]のようなアドレスが伝えられる。

1. 受信側のMTAがドメインを特定: 受信側のMTAは、SMTP通信で伝えられたエンベロープFromのドメイン（この例ではexample.com）を特定する。
2. DNSにSPFレコードを問い合わせ: 受信側のMTAは、特定したドメイン（example.com）のDNSサーバーに対し、「SPFレコード」を問い合わせを行う。これは、example.comのTXTレコードを検索することで行われる。
3. SPFレコードの解析と認証： 受信側MTAはDNSから返ってきたSPFレコードを解析し、SPFレコードに記述された「許可された送信元IPアドレス」のリストに含まれているかを確認する。
4. 結果： 検証結果に基づき、受信側MTAはメールをどのように扱うか決定。

SPFレコードの構造、主な要素

SPFレコードとは、v=spf1 で始まりその後に複数のメカニズムと修飾子を組み合わせて記述される。

※v=spf1:SPFレコードのバージョンを示す(現行バージョンは1)

メカニズム

• ip4:192.0.2.1/24: 指定されたIPv4アドレスまたはネットワーク範囲からの送信を許可。
• ip6:2001:db8::/32: 指定されたIPv6アドレスまたはネットワーク範囲からの送信を許可。
• a: ドメインのAレコード（IPアドレス）からの送信を許可。
• mx: ドメインのMXレコード（メールサーバー）からの送信を許可。
• ptr: (非推奨) PTRレコードを用いた逆引き検証。セキュリティリスクやパフォーマンス問題から非推奨。
• exists:example.com: 指定されたドメインのAレコードが存在すれば許可。
• _include:spf.google.com: 別のドメインのSPFレコードを読み込み、その許可設定も適用。主にGmailやOffice 365などのクラウドサービスで利用される。
• redirect=example.com: 自身のSPFレコードではなく、指定されたドメインのSPFレコードを完全に参照する。

修飾子（Qualifiers）

各メカニズムの前に付けることで、結果がどうであった場合の処理方法を指示。

• +(Pass): 許可（デフォルト値なので通常は省略）
• -(Fail): 不許可。ポリシー違反として受信拒否や破棄を強く推奨。
• ~(SoftFail): 不許可だが、やや許容的。ポリシー違反だが、スパム判定などにとどめ、受信を推奨。
• ? (Neutral): 許可も不許可も宣言しない。どちらでもない。
• all: 最後に記述されるデフォルトポリシーで、上記のメカニズムのいずれにもマッチしなかった場合の挙動を定義します。
• -all: 指定されたメカニズムに一致しない送信元はすべて拒否。最も厳格。
• ~all: 指定されたメカニズムに一致しない送信元はソフトフェイル。やや寛容。
• ?all: 指定されたメカニズムに一致しない送信元はニュートラル。最も緩やか。

SPF認証の結果とその意味

受信側MTAがSPF認証を行った結果返ってくる内容は、以下のようになっている。

• Pass: 送信元IPアドレスがSPFレコードで許可されている。
• Fail (-all): 送信元IPアドレスがSPFレコードで明示的に不許可とされている。
• SoftFail (~all): 送信元IPアドレスはSPFレコードで不許可とされているが、Failよりは緩やかな扱い（スパム判定など）。
• Neutral (?all): SPFレコードが「許可も不許可も宣言しない」と指定している。
• None: ドメインにSPFレコードが存在しない。
• PermError (permanent error): SPFレコードの構文に誤りがあるなど、恒久的なエラー。
• TempError (temporary error): DNSクエリの一時的なタイムアウトなど、一時的なエラー。

SPFのメリットとデメリット

メリット

• 送信元詐称の抑止: 許可されていないサーバーからの送信を検知し、ブロックすることで、スパムやフィッシングメールの対策に貢献している。
• ドメインの信頼性向上: SPFを正しく設定することで、自社ドメインからのメールが「なりすましではない」と証明でき、受信者側のメールサーバーからの信頼性が高まり、メールの到達率が向上。
• シンプルな導入設計: DNSレコードの追加・編集だけで導入できるため、多くのメールサービスプロバイダが設定方法を案内している。

デメリット

• エンベロープFromのみを対象: SPFは「エンベロープFrom」のドメインを認証するものであり、ユーザーが見る「ヘッダFrom」の詐称には直接対応できない。

例えば、[e-mail]が送信→
エンベロープFromはmalicious.comで正しく認証→
ヘッダFromをFrom: [e-mail]と詐称することが可能。

• メール転送（フォワーディング）の問題: メールが一度別のメールサーバーに転送されると、転送元のサーバーのIPアドレスで送信されるため、SPF認証に失敗（SoftFailやFail）する可能性がある。

• DNSルックアップ回数の制限: SPFレコードの評価には、includeやmx、aなどのメカニズムで参照される外部DNSクエリの回数に10回という制限があるため、これを超えるとPermErrorとなり、SPF認証が機能しなくなる。

• 設定ミスによるメール不達: SPFレコードの設定を誤ると、正規のメールまで拒否されてしまうリスクがある。

最後に

SPFは認証技術としてメールの普及、標準化に大きな貢献をした技術だと思っています。
ただ、その一方でデメリットとして挙げていた問題が残っていることがあったため、フィッシングなどの詐欺被害などもあの手この手で仕掛けてきている現状なのかな、と。

次回以降の記事として、DKIMとDMARC等のSPFから発展した認証技術についても調べたことを基に触れていきたいと思います。
説明不足な点、間違っている所等があれば教えていただけると助かります。

P.S
技術って凄いなぁ…