SPF ptr mechanism: how to replace it
The SPF ptr mechanism is slow, unreliable and discouraged by RFC 7208. What it does, why to remove it and what to replace it with.
By the Domain Health Hub team · Updated
- ptr allows any server whose reverse DNS name ends in your domain.
- RFC 7208 says it should not be used: it's slow, costs lookups and some receivers skip it.
- Replace it with the ip4:, ip6: or include: entries it was meant to cover.
What it means
The record contains ptr (or ptr: with a domain). To evaluate it, a receiver looks up the reverse DNS name of the sending server's IP address, then looks that name up again to confirm it points back to the same address, and passes the server if the name ends in your domain.
Why it matters
RFC 7208, section 5.5 says plainly that ptr should not be published. It needs several DNS lookups per message, it counts towards the limit of 10, and reverse DNS is often missing or slow, so the result is unreliable. Some large receivers skip it or treat a record that uses it with suspicion. Anything it allows can be allowed more simply another way.
It also hands control to whoever runs the reverse DNS for an address range, which is usually the hosting or broadband provider rather than you. If a provider gives a server a name under your domain, ptr lets it send as you, whether or not you meant it to.
Replacing it
- Work out which servers ptr was there for. Usually it's your own mail server or a hosting company's, named something like mail.example.com.
- Add those servers by address with
ip4:orip6:, or with the include the hosting company documents. - Remove ptr and check the domain again.
v=spf1 ptr include:_spf.google.com ~all v=spf1 ip4:203.0.113.25 include:_spf.google.com ~all
Microsoft 365 and Google Workspace
Neither needs ptr. Their includes cover their servers. If ptr is in a record for a domain on either, it was almost certainly left over from an old host and can go.
Questions
Will removing ptr stop any email?
Only if a server was relying on it and isn't listed any other way. Check DMARC reports for servers whose reverse DNS is under your domain, and list them by address first.
Is ptr ever the right choice?
Hardly ever. It was meant for organisations with large networks of their own whose servers all have reverse DNS under one domain. Even then, ip4: and ip6: ranges do the same job without a lookup.
Hear about it the day it breaks.
Daily checks on every client domain, alerts when something changes, and a monthly report card your clients will understand.