SPFレコード確認：SPFレコードは正しく動作している？
メールが迷惑メールフォルダーに入る、あるいはサービスからSPFが無効だと言われた。そんなときは、下にドメインを入力してください。このチェッカーはSPFレコードを取得し、すべてのincludeをたどり、DNSルックアップを上限の10回と照らして数え、修正すべき点を平易な言葉で一覧にします。
受信サーバーはSPFレコードをどう使うか
メッセージが届くと、受信サーバーはエンベロープ送信者のドメインを確認し、そのドメインのSPFレコードを取得します。これはv=spf1で始まるTXTレコードです。次に、今接続してきたサーバーのIPアドレスが、そのリストに含まれているかを確認します。結果はpass、fail、softfail、neutralのいずれかで、受信側は他のシグナルと合わせて評価し、メッセージを受信トレイに入れるか迷惑メールフォルダーに入れるかを決めます。
SPFが確認するのは、メールアプリで人が目にするFromアドレスではなく、エンベロープ送信者です。このずれを埋めるのがDMARCの役割です。
SPFの項目の早見表
| 項目 | 役割 |
|---|---|
| ip4:192.0.2.0/24 | IPv4アドレスまたは範囲を許可する |
| ip6:2001:db8::/32 | IPv6アドレスまたは範囲を許可する |
| a | ドメイン自身のAレコードとAAAAレコードのアドレスを許可する |
| mx | ドメインのメールサーバーのアドレスを許可する |
| include:_spf.example.net | そのドメインのSPFレコードが許可するものも、あわせて許可する |
| exists:name | その名前のDNS検索でアドレスが返る場合に許可する |
| ptr | 非推奨。逆引きDNSで照合するため、使うべきではない |
| all | すべてに一致するため、最後に置き、既定の結果を決める |
項目の前に付く修飾子は、一致したときの結果を決めます。+はpass（既定）、-はfail、~はsoftfail、?はneutralです。よく使われる末尾は、記載のない送信者を疑わしいものとして扱う~allと、受信側に拒否を求める-allです。
サービスを1つ追加しただけでSPFが壊れる理由
SPFでは、レコードの評価中にDNSルックアップを発生させる項目は、最大10個までです。include、a、mx、ptr、existsが数えられ、redirectモディファイアも同様です。ip4、ip6、allは数えられません。includeされたレコード内のルックアップも、同じ合計に加算されます。
正常だったレコードがだめになるのは、このためです。ニュースレターツール、ヘルプデスク、CRM、請求システムを追加すると、それぞれが自分のincludeを持ち、その中にさらにincludeを含むものもあります。10を超えると、SPFは永続的なエラーを返します。すると受信側は、すべてのメッセージを、そのドメインにSPFがないものとして扱うことがあり、誰もそれを知らせてくれません。
- 使っていないサービスのincludeを削除します。
- プロバイダーのアドレスが安定しているなら、includeをip4とip6の範囲に置き換えます。
- ptrは絶対に使わないでください。
- 可能であれば、送信サービスごとに専用のサブドメインを割り当てます。名前ごとに、それぞれ10回の上限が適用されます。
- includeをアドレスに展開（フラット化）する場合は、プロバイダーが範囲を変更することを忘れないでください。フラット化したレコードは、定期的な更新が必要です。
SPFポリシーを安全に設定する方法
- 名前ごとに、SPFレコードをちょうど1つだけ公開します。2つあると永続的なエラーになります。
- 正規の送信者がすべて記載されていることを確認する間は~allにしておき、確信が持てたら-allに移行します。
- SPFは継承されないことを覚えておいてください。メールを送信するサブドメインには専用のレコードが必要で、メールを送信しないサブドメインはv=spf1 -allを公開できます。
- SPFは、DKIMとDMARCポリシーと組み合わせてください。それぞれが、他の弱点を補います。