IPベースの送信者認可、3つのステップ
SPFを使えば、あなたのドメインのメール送信を許可するサーバーを宣言できます。受信側は、すべての受信メッセージを公開されたリストと照合します。
送信者が送信する
メールサーバーが、あなたのドメインを名乗るメッセージを配信するためにSMTP接続を開始します。接続してきたサーバーのIPアドレスが受信サーバーに記録されます。
受信側がSPFを確認する
受信サーバーは、あなたのドメインのSPF TXTレコードをDNSに問い合わせます。あなたが公開した許可済みIPアドレス、include、メカニズムのリストを取得します。
合格または失敗
接続してきたIPがSPFレコードと照合されます。許可されたメカニズムに一致すれば結果はPassです。一致しない場合、結果はallの修飾子によって決まります。ハードフェイル、ソフトフェイル、または中立のいずれかです。
SPFレコードは
DNSでどう見えるか
SPFレコードは、あなたのドメインの頂点に公開される単一のDNS TXTレコードです。v=spf1で始まり、include:やip4:のようなメカニズムを使って許可されたすべての送信元を列挙し、all修飾子で終わります。SPFレコードジェネレーターを使えば、有効なレコードを数秒で作成できます。
- ドメインが持てるSPFレコードは正確に1つ（複数のレコードはPermErrorを引き起こす）
- レコードは最初のメカニズムとしてv=spf1で始まる必要がある
- 各include:メカニズムは10ルックアップ制限に対して1回以上のDNSルックアップを要する
- ip4:とip6:メカニズムはDNSルックアップとしてカウントされない
- allメカニズムは最後に置き、デフォルトのアクションを定義する
example.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all"
v=spf1 include: ip4: -all include:_spf.google.com include:sendgrid.net include:spf.mailchimp.com include:spf.hubspot.com include:spf.freshdesk.com
なぜSPFは
10回のDNSルックアップで破綻するのか
RFC 7208のセクション4.6.4は、SPF評価を10回のDNSメカニズムルックアップに制限しています。これにより、SPFレコードがDNS増幅攻撃の手段として使われるのを防ぎます。include、a、mx、redirect、existsの各メカニズムはDNSルックアップを発生させます。4〜5個のメールサービスを使う組織は、この制限をよく超えてしまいます。
SPFフラット化はinclude:メカニズムを解決済みのIPアドレスに置き換え、DNSルックアップをなくします。姉妹製品のAutoSPFはフラット化を自動的に処理し、プロバイダーのIP変更を検出するために15分ごとに再スキャンします。
SPFレコードの構成要素
各メカニズムは、送信元IPアドレスを照合するためのルールを定義します。メカニズムは、一致が見つかるまで左から右へ評価されます。
ip4 / ip6 特定のIPv4またはIPv6アドレス、あるいはCIDR範囲を許可します。DNSクエリが不要なため、10ルックアップの制限にはカウントされません。
ip4:203.0.113.0/24 include 別のドメインのSPFレコードに認可を委譲します。受信側はそのレコードを取得して評価します。各includeは1回以上のDNSルックアップを要します。
include:_spf.google.com a 指定したドメインのAまたはAAAAレコードが返すIPアドレスを許可します。DNSルックアップを1回要します。
a:mail.example.com mx ドメインのMX（メール交換）サーバーのIPアドレスを許可します。DNSルックアップを1回に加え、MX解決のための追加ルックアップを要します。
mx redirect 現在のSPFレコードを別のドメインのレコードで完全に置き換えます。あるドメインの送信ポリシーが別のドメインと同一の場合に使用します。
redirect=_spf.example.com all 前のメカニズムで捕捉されなかったすべてのIPに一致します。常に最後に置きます。修飾子（+、-、~、?）が、一致しなかった送信元にどう対応するかを決めます。
-all +、-、~、?が配信にとって何を意味するか
修飾子は任意のメカニズムの前に付き、そのメカニズムが一致したときの結果を制御します。allメカニズムの修飾子が最も重要で、列挙されていないすべての送信元にどう対応するかを定義します。
IPは許可されています。修飾子を指定しない場合のデフォルトです。明示的に書かれることはほとんどありません。
+all（allと同じ） IPは許可されていません。受信側はメッセージを拒否すべきです。最も強い適用シグナルです。
-all IPはおそらく許可されていません。受信側は受け入れつつ疑わしいものとしてマークすべきです。導入初期に安全です。
~all IPについて何も主張しません。SPFの結果は情報を提供しません。実際にはほとんど使われません。
?all よくあるSPFの問題とその解決方法
SPFの失敗のほとんどは、ルックアップ制限、送信元の記載漏れ、あるいは適切なツールで簡単に見つけられる設定ミスから生じます。
DNSルックアップが多すぎる
SPFレコードがRFC 7208の10ルックアップ制限を超えています。include、a、mx、redirect、existsのすべてがカウントされます。SPFフラット化またはAutoSPFを使ってIPを静的に解決してください。
送信元の記載漏れ
正当なメールサービスがSPFレコードに列挙されていません。マーケティングツール、CRM、サポートデスクなどの新しいサービスを追加した後によく起こります。DMARC集計レポートを確認して、SPFに失敗している送信元を見つけてください。
ボイドルックアップの制限
RFC 7208はボイドルックアップ（NXDOMAINまたは空の応答）も2回に制限しています。もはや解決されない古いincludeドメインはボイドルックアップを発生させ、合計10ルックアップ未満でもPermErrorを引き起こすことがあります。
複数のSPFレコード
ドメインには正確に1つのSPF TXTレコードが必要です。複数のレコードはPermErrorを引き起こします。すべての許可された送信元を、v=spf1で始まる単一のレコードに統合してください。
ptrメカニズムの使用
ptrメカニズムは、遅く、信頼性が低く、DNSに過度の負荷をかけるため、RFC 7208で非推奨とされています。一部の受信側は完全に無視します。ip4/ip6またはincludeメカニズムに置き換えてください。
寛容すぎる+all
+allを使うと、インターネット上のあらゆるIPアドレスがあなたのドメインとして送信できるようになり、SPFの目的そのものが台無しになります。最後のメカニズムには必ず-all（ハードフェイル）または~all（ソフトフェイル）を使ってください。
SPFに関するよくあるご質問
SPFとは何ですか？
SPF（Sender Policy Framework）は、RFC 7208で定義されたDNSベースのメール認証プロトコルで、ドメイン所有者がそのドメインを代理してメールを送信することを許可されたIPアドレスとサーバーを公開できるようにします。受信側メールサーバーは、送信元IPを公開されたSPFレコードと照合し、許可されていない送信元からのメッセージを拒否またはフラグ付けします。SPFはDKIM、DMARCと並ぶ3つの基礎的なメール認証プロトコルの一つです。
SPFレコードはどのようなものですか？
SPFレコードは、ドメインの頂点（apex）に公開されるDNS TXTレコードです。典型的なレコードは次のようになります：v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all。v=spf1タグは必須で、最初に置く必要があります。includeメカニズムは別のドメインに認可を委譲します。ip4およびip6メカニズムは特定のIPアドレスを許可します。末尾のallメカニズムは、リストにない送信元に対するデフォルトのポリシーを定義します。-allはハードフェイル、~allはソフトフェイルを意味します。
なぜSPFには10ルックアップの制限があるのですか？
RFC 7208のセクション4.6.4は、SPFレコードがDNS増幅攻撃の手段になるのを防ぐため、SPF評価を10回のDNSメカニズムルックアップに制限しています。include、a、mx、redirect、existsの各メカニズムは、この制限にカウントされるDNSルックアップを発生させます。組織が複数のメールサービス（Google Workspace、SendGrid、Mailchimp、CRM、サポートデスク）を使用すると、ネストされたincludeによるルックアップの合計が容易に10を超えます。制限を超えるとPermErrorが発生し、そのドメインからのすべてのメッセージの認証が失敗します。
SPFの10ルックアップ制限を超えるとどうなりますか？
SPFレコードが10回のDNSメカニズムルックアップを超えると、受信サーバーはPermErrorの結果を返します。PermErrorはSPFレコードを評価できなかったことを意味し、ほとんどの受信側はそれを失敗として扱います。これは超過を引き起こした送信元のメッセージだけでなく、そのドメインから送信されるすべてのメールに影響します。解決策はSPFフラット化（includeメカニズムを解決済みのIPアドレスに置き換える）またはSPFマクロです。DMARC Reportの姉妹製品であるAutoSPF（autospf.com）は両方のアプローチに対応し、15分ごとに再スキャンします。
SPFの-allと~allの違いは何ですか？
-all修飾子（ハードフェイル）は、SPFレコードに明示的に列挙されていないIPアドレスからのメールを拒否するよう受信サーバーに指示します。~all修飾子（ソフトフェイル）は、メッセージを受け入れつつ疑わしいものとしてマークするよう受信側に指示します。実際には、DMARCの適用により多くの受信側は両者を同様に扱いますが、-allは最も強いシグナルを提供します。SPF導入初期には安全のために~allを使い、すべての正当な送信元を把握できたら-allに切り替えてください。
SPFはメール転送で機能しますか？
いいえ。メールが転送されると、転送サーバーのIPアドレスが元のドメインのSPFレコードに含まれていないため、SPFは失敗します。転送サーバーは自身のIPからメッセージを中継し、受信サーバーはそれを元のドメインのSPFレコードと照合して失敗と判定します。これがDKIMが存在する主な理由の一つです。DKIM署名はメッセージ自体に付与され、転送されても維持されます。DMARCはSPFかDKIMのいずれか一方が合格して整合すればよいため、DKIMが転送のギャップを補います。
SPFレコードはどうやってチェックしますか？
DMARC ReportのSPF Checkerツール（dmarcreport.com/tools/spf-checker/）を使って、SPFレコードを検索し、DNSルックアップ数を数え、構文エラーを確認し、すべての送信元が含まれているかを検証してください。このツールはすべてのincludeメカニズムを再帰的に解決し、SPFレコードが許可するIPアドレスの完全なリストを表示します。コマンドラインからnslookupやdigを使うこともできます。dig TXT example.comでSPFレコードが返されます。
セキュリティチームが語るSPF監視
Rated 4.8/5 on G2 · 469 verified reviews
Verified User in Information Technology and Services
"Best security tool for your own domains"
The weekly reports help me a lot to analyze quickly the emails sent from my domains and that gives me peace of mind.
Ryan C.
Director
"Control Centre for Email Security"
I like that we can see and check all reports on just 1 platform. We manage multiple domains, and monitoring them all in one place is essential.
eddy g.
Director
"A great solution to a common email problem."
I have been using them for the last month after my Google business email started giving DMARC errors. I didn't even know what it meant at that time. After a little googling I found that people can spoof it as well. So far so good — the best thing is it protects every email.