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 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 ~allClick the record to select all of it.
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 |
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
“Palisade allowed our team to deploy DMARC on our domains in minutes instead of hours and making sure our clients are compliant with cutting edge security recommendations from Microsoft.”
Alvin Kalli — CSIO, MSP Corp
DMARC software that does the work
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.
1 domain free up to 1,000 emails/month
Questions readers ask