Sender Policy Frameworkとは？ SPFメールを解説

Sender Policy Framework（SPF）認証方式は、特定のドメインに代わってメールを送信することを許可されたメールサーバーを識別する。SPF標準は、組織から送信されたメールの正規の送信元をどのように識別するかという問題の解決に役立つ。組織がSPFを設定すると、インターネットサービスプロバイダー（ISP）、メールセキュリティベンダー、その他のメールプロバイダーは、その組織のメール通信を検証し、認証済みの通信と、ドメインになりすまそうとするスプーフィングメールやフィッシング攻撃を区別できるようになる。

この記事では、次の内容を解説する。

• Sender Policy Frameworkの仕組み
• SPFの設定方法
• Sender Policy Frameworkのメリット
• Sender Policy Frameworkの制限
• Sender Policy Frameworkに関するFAQ
• まとめ：フィッシング排除に向けた重要な第一歩、SPF

Sender Policy Framework（SPF）の仕組み

SPFは、組織がメール送信に使用することを許可したドメインとインターネットプロトコル（IP）アドレスを定義する、メール認証の仕組みを提供する。SPFは、組織のドメインホスティングプロバイダーのドメインネームシステム（DNS）レコードに導入される。

メールを受信するサーバーは、メールヘッダーで送信元ドメインを確認し、DNSルックアップを実行して、送信元ドメインと一致するSPFファイルが存在するかどうかを調べる。SPFレコードの送信元ドメインがメールヘッダーの送信元ドメインと一致すれば、メールはSPFチェックに合格し、受信者に配信される可能性がある。SPFレコードが存在しない場合や、メールの送信元ドメインが公開されたDNSレコードと一致しない場合、メールは拒否されるか、迷惑メールフォルダーに送られる可能性がある。

SPFの基礎

SPFの仕組みを理解するには、SPFファイルの構造と各種オプションを理解することが重要だ。

SPFファイルの基本構造

「Internet Engineering Task Force（IETF）は、SPFとその標準に関する詳細情報を公開しており、最後に更新されたのは2014年である。SPFファイルの中核は、組織のドメインホスティングプロバイダーのDNSレコードにアップロードする単純な.txtファイルだ。また、SPFレコードは10個を超えるタグや255文字を含めることができないため、大規模な組織では大きな制約になり得る点にも注意が必要だ。

SPFファイルのオプション

基本的なファイル構造では、次の構文を使用する。

<version> <IP4 and/or IP6 address> <include: domain> <all tag>

• バージョンは常に「v=spf1」となる。他のSPFバージョンはすべて廃止されているためだ
• IPアドレス：
• • ドメインに代わってメールを送信することを許可されたIPアドレスとして、IPv4またはIPv6アドレスのいずれかを指定できる
  • 形式はip4:<ip4-address>、ip4:<ip4-network>/<prefix-length>、ip6:<ip6-address>、ip6:<ip6-network>/<prefix-length>となる
  • プレフィックス長は、IPv4では/32、IPv6では/128とみなされる。小規模な受信側への影響を避けるため、IPv4で/16未満のプレフィックス長は使用すべきではない
• Includeの構文は「include:senderdomain.net」となる。senderdomain.netは、組織に代わってメールを送信することを許可された第三者のドメインである。コマンドの前に「?」を付けると、送信元ドメインと一致したメールはpassではなくneutralとして扱われる
• すべてのタグは、SPFチェックに失敗したメールをどのように扱うべきかについて、他のサーバーに推奨事項を示す。
• • -all = SPFチェックに失敗したメールを拒否する
  • ~all = SPFチェックに失敗したメールを不審なものとしてマークする
  • ?all = SPFチェックに失敗したメールをどう扱うかは受信側サーバーが判断できる
  • +all = 任意のドメインが組織に代わってメールを送信できるようにする（推奨されない）

Sender Policy Frameworkには他にも多くのオプションがあるが、使用には危険が伴う場合がある。これらのオプションの利用を検討する組織は、正しい構文と使用方法を確実にするため、ベンダーやIT担当者と慎重に連携すべきだ。より高度なオプションの例には、次のようなものがある。

• 「a」メカニズムは、すべてのレコードを照合する範囲としてドメインまたはネットワークアドレスを指定する
• 「mx」メカニズムは、メール交換用IPアドレスの一覧を指定する
• 「ptr」は、すべてのサーバーからメールを送信する組織が使用する。通常は使用されない
• 「exists」は、SPFレコードとの一致を探してドメインをクエリする

関連するメール標準

SPFは対象範囲の狭い認証を提供する。より堅牢なソリューションでは、DKIMとDMARCの認証フレームワークも併せて導入する。

DKIM： DomainKeys Identified Mail（DKIM）は、公開鍵暗号方式を使って、組織のドメインから送信されるメールにデジタル署名を付与できる。

DMARC： Domain-based Message Authentication Reporting and Conformance（DMARC）は、SPFやDKIMに失敗したメールをより直接的に制御でき、正規のメールとなりすましメールについて報告できる。

SPFの設定方法

Sender Policy Framework（SPF）は、簡単に設定・構成できる。最も基本的なレベルでは、SPFを機能させるためにドメインレコードを1行変更するだけでよい。多くのホスティング企業では、例えば次の手順を実行する。

1. ドメインレジストラーにログインし、DNS設定を管理または構成するためのオプションをクリックする
2. 「新しいレコードを追加」オプションを見つけてクリックし、「TXT」レコードを選択する
3. ホスト名のダイアログに、@またはドメイン名を入力する。
4. SPFオプションを定義するSPF情報を「値」にコピー＆ペーストする

理論上は簡単だが、多くの組織には追加のオプションや変更を必要とする固有の要件がある。例えば、GoogleとMicrosoftは、GmailやMicrosoft 365のメールサーバーをSPFファイルに含めるための具体的な手順を公開している。初期版のSPFを作成したら、組織はドメインホスティングプロバイダーや各種メールサービス（例：HubSpot、Mailchimp）にも確認し、SPFが正しく作成・構成されていることを確かめるべきだ。

追加の支援が必要な組織向けに、組織に代わってSPFの作成と有効化を行えるサービスが多数存在する。これらのサービスは単独で提供される場合と、DKIMおよびDMARCの導入とセットで提供される場合がある。

SPFの検証とトラブルシューティング

SPFを導入した後、DNSレコードがインターネット全体に伝播するまで数日かかることがある。ただし、伝播後はメールを送信し、メールヘッダーに「spf=pass」が含まれているか確認できる。

もちろん、SPFの導入を誤ることは容易だ。そのため問題が発生した場合、組織は次の点を確認すべきだ。

• 誤った構文余分なスペースや入力ミスなど
• メール送信元が10件を超えていること。これによりエラーが発生する。認証済みの送信元ドメインが10件を超える組織は、サブドメインを使って複数のSPFレコードを設定する必要がある場合がある。
• 255文字を超えていること。送信元ドメインとオプションのフラグの間がこれを超えると無効になるため、SPFを短縮・修正して再登録する必要がある。
• ベンダー情報が誤っていること。SPF failの原因になる可能性がある。ベンダーと協力し、SPFに記載する情報が、バウンスバックドメインやWebサイトのURLなどではなく、メール送信に使用する具体的なIPアドレスまたはドメインを反映していることを確認する。
• 不要な「a」および「mx」エントリー。これらは混乱やエラーの原因になる可能性がある。「a」アドレスは通常、送信メールサーバーのIPアドレスではなくドメインのWebホストIPアドレスを示し、「mx」ホストは通常、受信メールに使用されるためだ。

メール認証ベンダーdmarcianなどは、SPFレコードをすばやく分析し、組織の問題解決を支援する無料ツールを提供している。

SPFのメリット

適切に構成されたSPFは、なりすましの軽減とドメイン評価の向上という、2つの具体的なメリットをもたらす。ほとんどの組織にとって、これらのメリットは、数は多いものの軽微なデメリットを上回るはずだ。

なりすましの軽減

メールフィッシング攻撃の一種であるメールスプーフィングは、読者をだます可能性を高めるため、正規の組織になりすまそうとする。適切に構成されたSPFを導入すれば、組織になりすますことは難しくなる。

メールサーバーがスプーフィングメールを受信すると、送信元IPアドレスをSPFファイルと照合し、組織のメールサーバーから送信されていないスプーフィングメールを拒否する。これにより、組織のブランドを悪用しようとする迷惑メールをブロックし、企業の評判を守ることができる。さらに、組織の従業員、例えばCEOになりすまそうとするフィッシング攻撃もブロックできる。

ドメイン評価の向上

組織がSPFを設定していない場合、その組織のメールを受信するメールサーバーは、ドメインの真正性を検証できないため、メールにフラグを付けたり拒否したりする可能性がある。SPFを設定すると、組織のドメイン評価が向上し、正規のメールの到達率も改善する。

Sender Policy Frameworkの制限

SPFはスパム、スプーフィング、フィッシングメールから保護し、世界中のメールセキュリティを強化する。しかし、比較的小さいものではあるが、多くの制限も抱えている。

維持管理が難しい

組織は、ベンダーがメールサーバーを変更した場合や、組織がISPプロバイダーを変更した場合、あるいはマーケティング部門が新しいメールニュースレターサービスを追加した場合でも、SPFレコードを常に更新しなければならない。変更内容を関係者全員と確認するには時間と手間がかかるため、DNSを定期的に更新することは難しい。

不適切なメール転送で機能しなくなる

転送されたメールでは送信元IPアドレスが変更されることが多く、その結果SPFチェックに失敗する。組織は、転送メールが正しい情報を保持するようサーバー設定を修正すべきだが、実際には修正されていないケースも多い。

不完全なソリューション

SPFはメールヘッダーの送信元ドメインのみを検証し、ユーザーに表示される「From」メールアドレスとは照合しない。フィッシング攻撃者が独自の送信元ドメインで独自のSPFファイルを設定すれば、SPFチェックは有効として通過する。より堅牢な対策とするには、SPF、DKIM、DMARCを組み合わせて使用し、組織の評判と検証済みメールを保護すべきだ。

大規模組織が抱える問題

組織の規模が大きくなるほど、その組織のためにメールを送信するサーバーやサービスの数も増える可能性が高い。255文字の上限とDNSルックアップ10回という制限があるため、大規模な組織はすべての送信元IPアドレスを1つのSPFレコードに公開できない。そのため、SPFの制限を回避するためにサブドメインを使用する必要がある。

ROIの測定が困難

組織は評判の向上やメールの到達性向上を認識できるものの、これらのメリットを投資対効果の測定で数値化するのは難しい。さらに、主なメリットを享受するのは一般に、メールを受信してSPFレコードを確認し、スパムやフィッシングメールをブロックするメールサーバーやメールセキュリティツールなど、他者である。SPFの導入コストは低いが、無形のROIとメリットが、導入がそれほど高くない理由を説明している50%.

なりすましに悪用される可能性

SPFは、悪意のある攻撃者やスパマーを含め、あらゆる組織が導入できる。SPFチェックではメール本文の「From」情報を確認しないため、悪意のある攻撃者は独自ドメインの情報を使って独自のSPFファイルを公開し、なりすましメールやスパムを認証できる。そのうえで、メールソフト上で表示される「From」欄には、メール受信者にまったく別の情報を表示できる。

適切なメールサーバー設定が必要

SPFは、SPFチェック用に設定されたメールサーバー、または同じ作業を行うメールセキュリティツールを使用するサーバーでのみ機能する。サーバーはSPFチェックを簡単にスキップできるため、スパムやスプーフィングメールが蔓延する可能性がある。

SPF FAQ：

まとめ：フィッシング排除に向けた重要な第一歩、SPF

フィッシングは、サイバーセキュリティにおける主要な攻撃経路であり、ネットワーク攻撃でもある。なりすましメールがあまりにも多く、検出されないまま残っているためだ。SPFは、SPF、DKIM、DMARCによるメール認証プロセスの第一歩であり、十分な数の組織がDKIMやDMARCと併せてSPFを導入すれば、フィッシングメールの大半をブロックできる可能性がある。維持管理には手間がかかるものの、SPFは導入コストが低いため、すべての組織が世界中でメールフィッシングと戦うための第一歩として導入すべきだ。少なくとも、自組織のドメインを装ったフィッシングから自らを守るべきである。