Sender Policy Framework

Sender Policy Framework (SPF) とは

Sender Policy Framework（SPF）は、電子メールにおける送信ドメイン認証技術の一つであり、メールの差出人アドレスが詐称されていないかを検証する技術です。SPFは、メールの送信元IPアドレスが、そのドメインの正当な送信元として許可されているかをDNSレコードを参照して確認します。

背景

インターネットのメールシステムで広く使われているSMTPプロトコルは、送信者が自由にメールアドレスを名乗れるという構造的な欠陥がありました。このため、迷惑メール送信者（スパマー）は、企業や政府などのメールアドレスを詐称し、フィッシング詐欺などの悪質な行為を繰り返してきました。この問題を解決するため、メール送信元の認証技術としてSPFが登場しました。

SPFの仕組み

SPFは、ドメインの所有者がDNSサーバーに「SPFレコード」と呼ばれる情報を登録することで機能します。このレコードには、そのドメインからメールを送信することが許可されているサーバーのIPアドレスが記述されています。メールを受信するサーバーは、送信されてきたメールの送信元IPアドレスと、SPFレコードに記述されたIPアドレスを比較し、送信元が正当なものであるかを検証します。この仕組みにより、なりすましメールをある程度防ぐことが可能になります。

SPFの限界

SPFは、メールの送信元アドレスが詐称されていないかを検証しますが、すべての迷惑メールを完全に防ぐことはできません。SPFは、あくまで「差出人アドレスに記載されたドメイン名」が正しいメールサーバーから送信されているかを確認するものであり、差出人アドレスを詐称していない迷惑メールは検出できません。また、同一ドメイン内でのアカウントの詐称も検出できません。さらに、SPFをパスするようなスパム送信サービスも存在するため、過信は禁物です。

SPFレコードの設定

SPFレコードは、DNSのTXTレコードに記述します。以下に一般的なSPFレコードの例を示します。


v=spf1 ip4:203.0.113.1 ip4:203.0.113.2 -all


この例では、「203.0.113.1」または「203.0.113.2」からのメール送信は許可しますが、それ以外のIPアドレスからのメールは拒否することを意味します。

SPFレコードには、他にも以下のような要素を指定することができます。

a: ドメインのAレコードに登録されているIPアドレスからのメール送信を許可する
mx: ドメインのMXレコードに登録されているサーバーからのメール送信を許可する
include: 指定したドメインのSPFレコードを参照する
redirect: 他のドメインのSPFレコードを適用する
all: すべてのメールを許可、または拒否する

SPFレコードは、古いDNSサーバーとの互換性を保つために、450文字以内に収めることが推奨されます。また、TXTレコードは1行あたり255文字までしか記述できないため、必要に応じて複数行に分割して記述する必要があります。

SPFの動作原理

SPFは、DNSのTXTレコードに定義された送信ポリシーに基づいて、メール送信元を検証します。メールを受信するサーバーは、メールを受け取る前に、送信元IPアドレスとSPFレコードの内容を照合します。もし、送信元が許可されていないIPアドレスからのメールであれば、そのメールは拒否されます。この動作原理は、DNSブラックリスト（DNSBL）と似ていますが、SPFはドメイン所有者が自ら送信ポリシーを定義できる点が異なります。

SPFは、メールのReturn-Pathヘッダーを保護します。Return-Pathヘッダーは、エラーメールの通知先を示すもので、Fromヘッダーとは異なる場合があります。SPFは、このReturn-Pathヘッダーの詐称を防止し、送信者に不必要なエラーメールが送られないようにします。

ただし、スパマーは、SPF認証をパスするような送信元からメールを送信することが可能です。そのため、SPFだけで迷惑メールを完全に防ぐことはできません。しかし、SPFは、迷惑メールの身元を特定する上で重要な情報を提供し、他の迷惑メール対策技術と組み合わせることで、より効果的な対策を実現できます。

検証不合格とメール転送

SPFの検証に不合格となるメールは、配送先サーバーで拒否されることがあります。ただし、メーリングリストのように、転送元サーバーがReturn-Pathを書き換えない場合は、転送先サーバーでSPFの検証に失敗し、メールが届かないことがあります。このような問題に対処するために、センダー・リライティング・スキーム（SRS）と呼ばれる技術が利用されます。

HELO試験

HELO/EHLOコマンドで指定されるドメイン名（HELOアイデンティティ）も、SPFによる検証の対象となります。これにより、送信サーバーの正当性をより厳密に検証できます。HELOアイデンティティによるSPF検証は、エラーメールの通知先を保護する上で重要な役割を果たします。

SPFの実装

SPFの実装は、大きく分けて2つの部分から構成されます。1つは、ドメイン所有者がDNSにSPFレコードを設定する部分、もう1つは、メールサーバーが受信メールのSPFを検証する部分です。SPFレコードは、標準的なDNS構文で設定されます。メールサーバーは、DNSクエリを使用してSPFレコードを取得し、その内容を解釈します。

SPFの機構と限定子

SPFレコードには、メール送信を許可する条件を記述する「機構」と、その条件に対する評価を定める「限定子」が使用されます。

機構:
a: ドメインのAレコードに登録されているIPアドレス
mx: ドメインのMXレコードに登録されているサーバー
ip4: IPv4アドレス、またはIPアドレス帯域
ip6: IPv6アドレス、またはIPアドレス帯域
include: 指定したドメインのSPFレコードを参照
redirect: 他のドメインのSPFレコードを適用
exists: 指定したドメイン名が存在するかどうかで判定
all: すべてのメールを許可、または拒否

限定子:
+: 検証の合格（省略可能）
?: 検証の中立
~: 弱い失敗
-: 失敗

SPFのエラー処理

SPFレコードの文法エラーが検出された場合は、恒久的エラー（PermError）として評価が中断されます。また、DNSへの問い合わせが過剰に発生するのを防ぐため、SPFレコードには問い合わせ回数に制限が設けられています。

SPFの注意点

SPFは、送信元アドレス（Return-Path）のドメインを検証するものであり、送信者の正当性を保証するものではありません。また、共有サーバーを使用している場合は、複数のドメイン名を使用できるため、注意が必要です。

SPFの検証不合格による拒否

SPFの検証に不合格となるメールを拒否することは、効果的な迷惑メール対策となる一方で、正当なメールも拒否してしまう可能性があります。そのため、検証不合格となったメールを完全に拒否するのではなく、迷惑メールの可能性が高いものとして扱ったり、SoftFailのような段階的な設定を行うこともあります。

SPFの検証地点

SPFの検証は、メール交換サーバー（MXレコードで指定されるサーバー）で行うことが推奨されます。メール交換サーバーの後ろでSPF検証を行うことは可能ですが、検証に失敗したメールを拒否するのは難しく、削除しかできないという制限があります。

SPFのDoS攻撃の可能性

SPFに関するDNSクエリの規模によっては、DoS攻撃の手段となる可能性が指摘されています。この問題は、SPFに関するRFCでも言及されています。

SPFの歴史

SPFの概念は、2003年にポール・ヴィクシー氏によって提唱されました。その後、複数のプロトコルの融合を経て、Sender Policy Frameworkとして標準化されました。当初は「Sender Permitted From」の略称でしたが、後に現在の名称に変更されました。2006年には、RFC 4408として正式にRFC化されました。

SPFに関する論争

SPFは、その設計や実装に関して、いくつかの論争がありました。例えば、TXTレコードの使用や、携帯メールアドレスに対する影響などについて議論されました。また、電子メールのRFCとの矛盾を指摘する意見もありました。

SPFの普及状況

SPFは、多くのメールサービスプロバイダーや迷惑メール対策ソフトウェアで採用されており、広く普及しています。日本でも、携帯電話会社を中心に、SPF認証を導入する動きが広がっています。

SPFの実効性

SPFは、迷惑メール対策に一定の効果がある一方で、その実効性には疑問の声もあります。SPF認証をパスするスパムメールが増加していることも報告されており、SPFだけで迷惑メールを完全に防ぐことはできません。また、携帯電話会社におけるSPF認証の仕組みでは、スパム送信者用のドメインを利用したメールを許可してしまうという問題点も指摘されています。

日本におけるSPFの普及

現在、日本の主要な携帯電話会社では、SPF認証が導入、または導入予定です。ただし、その実装は標準とは一部異なり、検証の対象や条件は各社で異なります。

まとめ

SPFは、メールの送信元を認証する上で重要な技術ですが、万能ではありません。SPFの限界を理解した上で、他の迷惑メール対策技術と組み合わせることで、より効果的な対策を実現することが重要です。

参考情報:
RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
SPF homepage and news
Mailing list archives
* SPF Testing site

もう一度検索