SPF redirect 修飾子（Modifier）
概要
SPF redirect 修飾子（Modifier） は、SPF レコードの評価を別のドメインの SPF レコードに完全に委譲する仕組みです。RFC 7208（2014年）で定義されており、redirect=target.example.com の形式で記述します。
include メカニズムとの違いは、redirect がレコード全体の評価を置き換える点です。include は参照先のレコードを「追加の許可リスト」として評価しますが、redirect は「このドメインの SPF レコードの代わりにあちらのレコードを使え」という指示です。redirect が処理されると、元のレコードの all メカニズムは無視され、リダイレクト先の all が使われます。
複数のドメインで同じ送信インフラを共有する組織では、SPF レコードを 1 箇所で管理して他のドメインから redirect で参照するパターンが有効です。
仕組み
redirect は他のメカニズムがすべて不一致だった場合にのみ処理され、リダイレクト先の結果がそのまま最終結果になります。
評価フロー
SPF の redirect は、レコード内の他のすべてのメカニズムが一致しなかった場合にのみ処理されます。
- 受信サーバーが送信元ドメインの SPF レコードを取得する
- レコード内のメカニズム（
ip4:、include:など）を順番に評価する - どのメカニズムにも一致しなかった場合、
redirect=で指定されたドメインの SPF レコードを取得する - リダイレクト先のレコードで改めて評価を行い、その結果を最終結果とする
redirect はメカニズムではなく修飾子（modifier）です。レコード内に all メカニズムが存在すると、all が先に評価されるため redirect は処理されません。redirect と all を同じレコードに書くのは設定ミスです。
include との違い
| 項目 | include | redirect |
|---|---|---|
| 分類 | メカニズム | 修飾子 |
| 評価タイミング | 記述位置の順番で評価 | 他の全メカニズムが不一致の後 |
| 結果の扱い | 参照先で pass なら pass、fail なら次のメカニズムへ | 参照先の結果がそのまま最終結果 |
all との共存 | 共存可能 | all があると redirect は処理されない |
| DNS ルックアップ | 1 回消費 | 1 回消費 |
include は「このリストも許可に加える」、redirect は「ここに判断を丸ごと委ねる」と理解すると区別しやすくなります。
DNS ルックアップへの影響
redirect は DNS ルックアップを 1 回消費します。RFC 7208 が定める上限 10 回のカウントに含まれます。リダイレクト先の SPF レコードに include がさらに含まれていれば、そのルックアップも合算されます。
設定例
共通の SPF レコードを 1 つのドメインに定義し、他のドメインから redirect で参照するのが典型的な使い方です。
複数ドメインで共通の SPF を参照する
共通の送信インフラを _spf.example.com に定義し、他のドメインから参照します。
_spf.example.com. IN TXT "v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~all"example.com. IN TXT "v=spf1 redirect=_spf.example.com"example.net. IN TXT "v=spf1 redirect=_spf.example.com"example.com と example.net は同じ送信インフラを使うため、変更が発生したら _spf.example.com だけを更新すれば済みます。
自社メカニズムと redirect の組み合わせ
example.com. IN TXT "v=spf1 ip4:198.51.100.10 redirect=_spf.shared.example.com"198.51.100.10 に一致しなかった場合にリダイレクト先で評価します。この構成では ~all や -all を書いてはいけません。all を書くと redirect が処理されなくなります。
確認方法
SPF レコードの redirect= 修飾子は dig で確認できます。
dig TXT example.com;; ANSWER SECTION:
example.com. 3600 IN TXT "v=spf1 redirect=_spf.example.com"リダイレクト先の内容も確認します。
dig TXT _spf.example.com;; ANSWER SECTION:
_spf.example.com. 3600 IN TXT "v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~all"外部の視点からも確認したい場合は、Labee Dev Toolbox の Mail Auth API を使うと、外部の視点から見た結果を取得できます。
curl "https://labee.dev/api/mail-auth?domain=example.com"{
"success": true,
"data": {
"spf": {
"record": "v=spf1 redirect=_spf.example.com",
"exists": true
},
"dkim": { "record": null, "exists": false, "selector": "default" },
"dmarc": { "record": null, "exists": false },
"bimi": { "record": null, "exists": false }
},
"error": null,
"meta": { "responseTime": 123 }
}data.spf.record に redirect= が含まれていれば、リダイレクト先のドメインの SPF レコードも別途確認します。
よくある問題
redirect のトラブルは、all との併記、リダイレクト先の消失、include との役割の混同が中心です。
redirect と all を同じレコードに書く
example.com. IN TXT "v=spf1 redirect=_spf.example.com ~all"~all がすべての IP に一致するため、redirect は処理されません。redirect を使う場合は all メカニズムを削除します。
redirect 先のレコードが存在しない
リダイレクト先のドメインに SPF レコードが存在しない場合、SPF の評価結果は permerror になります。DMARC はこれを fail として扱います。リダイレクト先のレコードが正しく公開されているか定期的に確認します。
redirect のネストで DNS ルックアップ上限を超える
リダイレクト先の SPF レコードに include が多数含まれていると、ルックアップ合計が 10 回を超えることがあります。リダイレクト先のレコード構成を把握し、元ドメインのメカニズムと合わせたルックアップ総数を管理します。
include と redirect の使い分けを誤る
追加のメール送信サービスを許可リストに加えたいだけであれば include を使います。redirect はレコード全体の評価を委譲する場合にのみ使います。目的を間違えると意図しない SPF 結果になります。