メインコンテンツへスキップ

SPFについて

SPFはドメインの評価を高め、メールの配信率を向上させます。

SPFは、ドメインのなりすましやメールのなりすましを防止し、ブランドの価値を守ります。

SPFは、DMARCにおけるメール認証の基礎となる重要な手法の一つです。

SPFの解説

SPFとは何ですか?

SPF(Sender Policy Framework)は、メールの送信者を認証するために使われる仕組みです。
SPFレコードを設定しておくことで、受信側のインターネットサービスプロバイダー(ISP)は、特定のメールサーバーがそのドメインに代わってメールを送信する権限を持っているかどうかを検証できます。
具体的には、SPFレコードとは「自ドメインを代表してメールを送信することが許可されたIPアドレスの一覧」が記載された、DNSのTXTレコードのことです。

昨今、どの送信インフラが自ドメインの代わりにメールを中継(リレー)できるかを検証することは、極めて重要になっています。メールにSPFを導入することは、組織にとって非常に大きなメリットをもたらします。

SPFの仕組み

SPFを活用するには、まずDNSにSPFレコードを公開します。このレコードには、そのドメインに代わってメール送信を許可されたすべてのIPアドレスがリストアップされています。

SPFのメカニズムでは、メールの「Return-Path(リターンパス)」アドレスにあるドメインを使用して、照会すべきSPFレコードを特定します。

1. 送信者がメールを受信サーバーに引き渡そうとすると、受信サーバーはその送信者が対象ドメインの「許可された送信者リスト(SPFレコード)」に含まれているかを確認します。

2. リストに含まれていれば、そのメールとドメインの間に「認証の結びつき(リンク)」が確立されます。

3. 含まれていない場合、受信サーバーはひとまずこの結びつきがないものとして、通常通りメールの処理を続行します(結びつきがない理由は一概に特定できないためです)。

なぜ結びつきがないだけで拒否しないのか?
メールの内容は本物であっても、公開されている送信者リストが最新ではない(不正確な)可能性があります。また、正規のメールが「転送」された場合、メールは全く関係のないサーバーから届くことになるため、事前に用意した送信者リストではカバーしきれません。あるいは、単純にメールが偽物(迷惑メール)である可能性もあります。

このように、リストにない場合の理由(結果)が多岐にわたるため、「SPFによる結びつきがない」という事実だけで一概に判断を下すのは困難です。DMARCの技術フレームワークにおいて、このSPFの隙間を埋め、メールとドメインを紐付けるもう一つのアプローチとして機能するのが DKIM です。

SPFの仕組み

SPFのフォーマット(記述形式)について

SPFレコードの具体的な記述形式や、お使いのドメインへの追加方法についての詳細は、以下のガイドを参照してください。

📄 [SPFレコードの作成と追加方法]

すでにSPFレコードを運用されている場合は、理解をさらに深め、弊社の無料診断ツール「SPF Surveyor」が検知した問題のトラブルシューティングに役立つ、構文の包括的なガイドもご用意しました。

📄[SPFレコードの構文(Syntax)解説]

 

メールにおけるSPFとDMARCの関係

SPF自体は、個々のメールをドメインに関連付けることができます。DNSレコードが設定されている場合、DMARCはSPFの結果をメールの内容、具体的にはメールの「Return-Path」または「From:」ヘッダーに記載されたドメインと結びつけます。DMARCの文脈でSPFが正しく機能するためには、「Return-Path」アドレスが「From:」ヘッダーのドメインと一致している必要があり、これがDMARCのアラインメントを成立させる鍵となります。

SPFレコードを確認するにはどうすればよいですか?

ドメインのSPF設定を確認するには、dmarcianの [SPF Surveyor] をご利用ください。SPFレコードをグラフィカル(視覚的)に表示する診断ツールで、どのサーバーがドメインに代わって送信を許可されているかを一目で素早く把握できます。

「SPFだけ」では安全とは言えない理由

簡単に言うと、インターネット上では日常的に「メールの自動転送」が行われますが、SPFの仕組みは転送処理を越えることができません。

例えば、あなたが [email protected] 宛にメールを送り、その受信者が [email protected] という別の受信箱に自動転送を設定していたとします。この場合、最終的な受信サーバー(SAMPLE.NET)から見ると、あなたのメールは「あなたとは全く無関係のインフラ(EXAMPLE.ORGのサーバー)」から送られてきたように見えてしまうため、SPFは失敗(Fail)します。

一方、DKIM署名は転送されても維持されます。 ドメインにDKIM設定が施されていれば、dmarcianのプラットフォームはそれが「転送されたメールである」とより正確に検知できます。ドメイン所有者が世の中のあらゆる転送サーバーを事前にリスト化することは不可能なため、転送の文脈においてSPFは機能しなくなります。

SPFに関するよくある誤解

B2Bサービスを提供する企業(ベンダー)の間でも、SPFの仕組みが誤解されているケースが多々あります。よくあるのが、ベンダーが顧客企業に対し「弊社のSPFレコードを、御社のDNSに include してください」と指示するケースです。

しかし、もしそのベンダーが、エラーメールの返送先(バウンスアドレス / Return-Path)にベンダー自身のドメインを使用している場合、この設定は全く意味をなしません。 受信サーバーがメールを処理する際に見に行くのは、Fromの顧客ドメインではなく、Return-Pathにある「ベンダー側のSPFレコード」だからです。

この誤解によって、以下の2つの望ましくない問題が発生します。

  • 不必要な include の追加: 顧客側のSPFレコードが肥大化(無駄に文字数やDNSルックアップ数が消費)し、管理上の課題が生じます。
  • DMARC展開の混乱: DMARCを導入するためにとりあえずSPFを設定したものの、結果として「SPFはパスしているのに、DMARCは失敗(Fail)する」というアライメントエラーの事態を招きます。

DMARCの文脈でSPFを正しく機能させるには、バウンスアドレス(Return-Path)が From: ヘッダーのドメインと一致(アライメント) していなければなりません。残念ながら、他社に代わってメールを配信するベンダーの中には、顧客がバウンスアドレスを自社ドメインに変更することを許可していないところがまだ多く存在します。

この状況は徐々に改善されつつありますが、まずはベンダー側がSPFの基本を理解する必要があります。弊社では、他社に代わってメールを送信する企業向けに、DMARCに準拠した配信を行うためのリソースも提供しています。

📌 補足:SenderIDについて
過去に「SenderID」と呼ばれる、SPFに似たチェックを(Return-Pathではなく)From: ヘッダーのドメイン等に対して行う古い技術が存在しましたが、現在は廃止されています。SenderIDが既存のSPFレコードを再利用しようとしたことで、当時はさらに混乱が加速することとなりました。

SPFとは何か、送信者ポリシーフレームワークを理解するための道筋。dmarcian

SPFについてさらに学ぶ

dmarcianでは、DMARCのさまざまな側面を解説する短期の技術解説ビデオシリーズをご用意しています。弊社の高度なトレーニングコースのエッセンスを凝縮したもので、どなたでも無料で、いつでもお好きな時間にご視聴いただけます。

よくある質問

Sender Policy Framework(SPF)とは何ですか?また、どのように機能するのでしょうか?

Sender Policy Framework(SPF)は、電子メールの送信者を認証するために使用されます。これを行うには、DNSにSPFレコードを登録します。SPFレコードとは、そのドメインに代わって電子メールを送信することが許可されているすべてのIPアドレスのリストです。DMARCは整合性を確認するため、いずれかの認証方法に合格し、かつ整合性が取れていれば、そのメッセージは全体として通過することができます。

SPFとDKIMの違いは何ですか?

SPFは送信者が名乗っている人物そのものであることを確認し、DKIMはメッセージが転送中に改ざんされていないことを確認します。DMARCは、メールの検証に失敗した場合の対応を決定し、レポート機能を提供します。これら3つを組み合わせることで、ドメインのなりすまし、フィッシング、およびメールによるなりすましを防止することができます。

DKIMを導入している場合、SPFは必要ですか?

はい、SPFとDKIMの両方が必要です。これらはそれぞれ異なる、かつ同等に重要なメール認証チェックを行うためです。SPFは、SPF、DKIM、DMARCを含むメールセキュリティ戦略の一環として組み込むべきです。

SPFフラットニングとは何ですか?また、それは必要なのでしょうか?

SPFフラットニングとは、間接的なインクルード文を直接的なIPアドレスに置き換えることで、SPFレコードのDNSルックアップ制限(10回)を回避するための手法です。SPFフラットニングは必須ではなく、攻撃対象領域を拡大してしまうため、ベストプラクティスとは見なされていません。

SPFは合格しているのに、なぜDMARCは不合格になるのでしょうか?

DMARCのアライメント不備により、SPFの検証に合格してもDMARCの検証に失敗することがあります。SPFおよびDKIMの検証に成功した場合でも、DMARCの検証に失敗する可能性があります。これは、DMARCがドメインのアライメントを強制する一方で、SPFやDKIMだけではこの要件を満たせないためです。要するに、DMARCは、SPFおよびDKIMで使用されているドメインが、メールの「From」ヘッダーに表示されているドメインと一致していることを保証するものです。

SPF(DNS)の10件の検索制限とは何ですか?

SPF 10のルックアップ制限は、メールサーバーが送信者を検証する際に、10回を超えるDNSチェックを行わないようにするものです。各ルックアップは、10回という制限にカウントされます。10回のDNSクエリで送信元IPが見つからない場合、DNSの過負荷、サービス拒否(DoS)、および分散型サービス拒否(DDoS)攻撃からDNSを保護するため、SPFはpermerrorエラーを返して失敗となります。

「SPFルックアップが多すぎます」というエラーをどのように修正すればよいですか?

「SPF Too Many Lookups」を修正するには、SPFレコードを点検して、使用されていないベンダーやメカニズムを削除し、専用のサブドメインを活用してください。各サブドメインには個別に10件のルックアップクォータが割り当てられているためです。

DNSルックアップの回数を減らすための方法をいくつかご紹介します:

  • 継続的なドメイン管理の一環として、当社のSPFチェッカーおよびバリデータツールを使用してSPFレコードを定期的に監査し、重複しているエントリを特定して、使用されていないSPFエントリを削除してください。
  • SPF認証のために、ベンダーからのトラフィックをサブドメインに移行します。サブドメインによるセグメンテーションを行うことで、特定のメールストリーム専用の新しいドメインが作成され、そのドメインには独自のDNSルックアップが10件割り当てられます。
  • SPFの整合設定ができないベンダーのレコードを削除してください。
    dmarcianアカウントをお持ちの場合は、Detail Viewerに表示される送信元のうち、「SPF非対応」であり、SPF合格率が0%となっているもののSPFレコードを削除してください。
    – dmarcianアカウントをお持ちでない場合は、dmarc.ioを参照して、ベンダーのSPF対応状況を確認することができます。
  • 「a」および「mx」のエントリは避けてください。これらのメカニズムは多くの場合役に立たず、SPFレコードに含めるべきではありません。
  • 重複するSPFメカニズムを削除します。

ドメインのDMARC準拠を進めましょう。
dmarcianを無料でお試しください!