SPFについて

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

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

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

SPFの解説

SPFとは何ですか？

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

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

DMARCの始め方

SPFの仕組み

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

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

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

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

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

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

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

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レコードを再利用しようとしたことで、当時はさらに混乱が加速することとなりました。

DMARCの始め方