SPF glossary
What does the ptr mechanism do in an SPF record (and why is it deprecated)?
By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 15, 2026
The ptr mechanism matches a sender by reverse-DNS lookup of its IP address — and RFC 7208 says do not use it. It's slow, unreliable, and heavy on DNS, and in practice some receivers skip or fail it, so mail authorized only by ptr can fail anyway. Replace it with ip4:, ip6:, or include:.
ptr at a glance | |
|---|---|
| Tag | ptr (mechanism) — deprecated |
| Valid values | ptr · ptr:<domain> — but RFC 7208 says publishers should not use it at all |
| Default | Bare ptr validates hostnames against the current domain. |
| Where it goes | Nowhere, ideally — if it's in a record you manage, plan its removal. |
How ptr works
ptr works backwards: the receiver takes the sending IP, does a reverse-DNS (PTR) lookup to get hostnames, then resolves those hostnames forward to confirm they really map back to that IP. If a validated hostname falls under the target domain, the mechanism matches. That's several DNS round-trips to establish what an ip4: term states in zero.
RFC 7208 is unambiguous: the mechanism is slow, unreliable when DNS errors occur, places a heavy load on the .arpa reverse-DNS servers, and should not be used. And because publishing guidance has said so for years, real-world evaluation is inconsistent — some receivers skip the mechanism or limit it, so a record that depends on ptr authorizes your mail at some receivers and not others.
The replacement is whatever the ptr was standing in for: ip4:/ip6: terms for your own servers, include: for providers. A ptr in a record you inherit is a fossil from the 2000s — identify what actually sends, authorize it explicitly, and remove it.
Correct record vs common mistake
Correct
v=spf1 ip4:192.0.2.10 include:_spf.google.com -allWhat a ptr term should become — explicit addresses for your own servers, includes for providers.
Common mistake
v=spf1 ptr -allRFC 7208 says not to publish ptr: slow, unreliable, and inconsistently evaluated. Mail authorized only by ptr can fail at receivers that skip it.
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 ptr
| Issue | Likely cause | Fix |
|---|---|---|
| Intermittent SPF failures with ptr in the record | Reverse-DNS lookups time out, or the receiver skips the mechanism | Don't debug it — replace ptr with ip4/ip6/include and the intermittency goes with it |
| Inherited record contains ptr | A legacy template from before the guidance changed | Identify real senders from the DMARC reports, authorize them explicitly, remove ptr |
| Checker warns about ptr but mail is delivering | Your current receivers happen to evaluate it successfully — for now | Treat the warning as the to-do it is; swap in explicit terms proactively, not mid-incident |
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
A ptr lurking in inherited client records makes SPF nondeterministic across your fleet: the same message can pass at one receiver and fail at another, which turns into unreproducible delivery tickets nobody can close. Sweep for it across all 50–200 tenants once, replace it with explicit terms, and that whole class of weirdness disappears.
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
Enforce it — don't just monitor it
Replacing `ptr` starts with knowing what actually sends for each domain — which is exactly what DMARC reports show. Palisade reads them for every client domain, so you can authorize each real source explicitly, drop the fossil, and keep every tenant moving toward `p=reject`.
Free 15-day trial · No credit card · Your own domain free forever (NFR)