SPF glossary
What does redirect= do in an SPF record?
By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 15, 2026
redirect= is an SPF modifier that replaces your entire evaluation with another domain's record — v=spf1 redirect=_spf.example.com means that record's result, including its -all, becomes *your* result. Unlike include:, nothing of your own record remains in play. It's how one central SPF policy serves many domains.
redirect= at a glance | |
|---|---|
| Tag | redirect (modifier) |
| Valid values | redirect=<domain> — note the equals sign, not a colon |
| Default | Ignored if the record also contains an all mechanism; permerror if the target has no SPF record. |
| Where it goes | Conventionally the last term, in place of all, e.g. v=spf1 redirect=_spf.example.com |
How redirect= works
redirect= hands the whole evaluation to another domain: the receiver fetches the target's SPF record and evaluates the sender against it as if it were yours. Whatever that record returns — pass, fail from its -all, anything — becomes your domain's result. That's the key contrast with include:, which only ever *matches on pass* and leaves your own record in charge of everything else.
Two rules to know: if your record also contains an all mechanism, the redirect is ignored — all matches everything first, so the redirect never runs. And if the target domain publishes no SPF record, the result is a permerror. Like include, a redirect costs one of the 10 DNS lookups.
Its natural use is centralization: publish one policy at _spf.example.com, and give every other domain a one-line record that redirects to it. Change the central record once and it applies everywhere — exactly the multi-domain, multi-tenant pattern an MSP managing dozens of client domains needs.
Correct record vs common mistake
Correct
v=spf1 redirect=_spf.example.comThe whole policy is delegated — no all needed; the target record's -all applies as this domain's result.
Common mistake
v=spf1 redirect=_spf.example.com -allWith an all mechanism present, the redirect is ignored entirely. The -all takes over and the redirect never runs — probably not what was intended.
Generate your SPF record
Build a correct SPF record for your domain — add your senders, copy the TXT record. Free, no signup.
Who sends email for this domain?
Each service adds its documented include mechanism.
From your provider's docs, e.g. spf.example-esp.com — commas or spaces between multiple. Some services (Klaviyo, HubSpot, Mailchimp Transactional) authenticate through their own CNAME records instead of a shared include — check their DNS settings page.
How should receivers treat everyone else?
Your SPF record
0/10 DNS lookupsPublish as a TXT record at the domain root. One SPF record per domain — if one exists, merge into it instead of adding another.
yourdomain.com (or @)
v=spf1 ~all
Record type: TXT · ip4/ip6 mechanisms don't count against the 10-lookup limit.
After you publish
- Add the TXT record at your DNS host.
- Verify it with the free SPF checker.
- SPF alone doesn't stop spoofing — pair it with DKIM and a DMARC policy. Generate one with the DMARC record generator.
Troubleshooting redirect=
| Issue | Likely cause | Fix |
|---|---|---|
| SPF broke on many domains at once | All of them redirect to one central record, and that record has an error | Fix the central target — and treat it as shared production: test changes before publishing |
| redirect appears to do nothing | The record also contains an all mechanism, which makes receivers ignore the redirect | Remove the all (the target's all applies) — or remove the redirect if all was the intent |
| permerror on a redirect-based record | The target domain publishes no SPF record, or the name is misspelled | Confirm the target resolves to a valid v=spf1 TXT record before pointing domains at it |
See this on your own domain
Enter your domain — the check runs instantly on the next page. Free, no signup.
Why it matters for MSPs
Redirect is the multi-tenant pattern done right — one central record, every managed domain pointing at it — but it concentrates risk the same way it concentrates control: an error in the central record breaks SPF for every domain redirecting to it, simultaneously. Across 200 tenants that's one DNS edit away from a fleet-wide incident, so the central record deserves change control.
Trusted by MSPs
“We increased our meetings booked by 21% and slept better at night knowing our emails are now secured”
Marc-André Campagna — CEO, gaiia (YC 2021)Read the case study →
Enforce it — don't just monitor it
Centralizing policy across many domains is the same instinct Palisade productizes: every client domain managed from one place, with DMARC report evidence per tenant and PSA integrations for the workflow — and each domain advanced safely to `p=reject` instead of just sharing a TXT string.
Free 15-day trial · No credit card · Your own domain free forever (NFR)