SPF glossary
What does the exp modifier do in an SPF record?
By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 15, 2026
exp= points to a TXT record whose text becomes the human-readable explanation a receiver *may* attach when your mail fails SPF. In practice almost no receivers display it, and DMARC reporting has made it effectively obsolete — failure visibility now comes from aggregate reports, not explanation strings. Safe to omit.
exp= at a glance | |
|---|---|
| Tag | exp (modifier) |
| Valid values | exp=<domain> — a domain whose TXT record holds the explanation text (macros allowed) |
| Default | Optional. If absent or broken, receivers just use their own default message — no error. |
| Where it goes | Anywhere after v=spf1; at most one per record. Most records rightly have none. |
How exp= works
When a message fails SPF, a receiver that honors exp= looks up the TXT record at the named domain, expands any macros, and includes the resulting text in its rejection — in theory giving the sender a custom, helpful error like “see https://example.com/spf for help.”
In practice, the theory never landed: almost no receivers fetch or display the text, so the modifier mostly adds one more DNS name to keep alive for an audience that isn't looking. The visibility problem it tried to solve is now handled properly by DMARC aggregate reporting, which shows you every failing source in structured data. If you're deciding whether to add exp= — don't. If you find one in an old record, removing it changes nothing.
Correct record vs common mistake
Correct
v=spf1 ip4:192.0.2.10 -allNo exp at all — the modern record. Failure visibility comes from DMARC reports, not explanation strings.
Common mistake
v=spf1 ip4:192.0.2.10 -all exp=explain._spf.example.comNot invalid — just pointless. Almost no receivers display the text, and it's one more DNS name to keep alive forever.
Troubleshooting exp=
| Issue | Likely cause | Fix |
|---|---|---|
| The exp target TXT record was deleted — did anything break? | Nothing — receivers that would use exp simply fall back to their own default message | Take the opportunity to remove the exp modifier from the record too |
| Bounce messages don't show the custom text | Most receivers never fetch or display exp — expected behavior | Use DMARC aggregate reports for failure visibility instead of explanation strings |
| A checker flags exp as unnecessary | It is — the modifier is effectively obsolete in practice | Remove it; smaller records have fewer things to maintain and fewer ways to confuse the next reader |
Why it matters for MSPs
Harmless, but it's clutter — and at 50–200 tenants, clutter compounds: every exp= in a client template is an extra DNS name to keep alive and an extra line for the next tech to puzzle over, purchased for a message no receiver shows. Strip it from your templates; spend the attention on the parts of the record that decide delivery.
Trusted by MSPs
“Their responsive support, agent task lists, white-label reporting, and centralized dashboard make managing our customer domains, effortless.”
Bobby Ghoshal — CEO, dupe.com
DMARC software that does the work
The visibility `exp=` promised is what DMARC reports actually deliver. Palisade reads them for every client domain — every failing source, in structured data — and turns that evidence into safe policy advancement to `p=reject`, which no explanation string ever did.
1 domain free up to 1,000 emails/month
Questions readers ask