The SPF ptr mechanism: why it is discouraged and what to use instead

What the RFC actually says

RFC 7208 lists ptr among the designated sender mechanisms, and the section heading for it reads "ptr (do not use)". The body is equally direct: the mechanism SHOULD NOT be published.

At the same time, receivers MUST still support it. That combination explains why ptr is never a Critical finding. Your mail is not broken. Evaluation still works. You are relying on a mechanism the specification has publicly stepped back from, and paying a real cost for it.

How ptr evaluates

The mechanism is more expensive than it looks. For a connecting IP, a receiver:

1. Performs a reverse lookup for the address (querying in-addr.arpa for IPv4 or ip6.arpa for IPv6) and collects the PTR records returned.
2. For each name returned, does a forward lookup on that name to get its addresses. This step exists because PTR records are controlled by whoever owns the IP address - not by you - so an unverified PTR proves nothing.
3. Keeps only the names whose forward lookup includes the connecting IP. These are the validated names.
4. Checks whether any validated name matches the mechanism's target domain, or is a subdomain of it.

So a single ptr costs a reverse query plus a forward query for every name that comes back. The RFC also caps the address records queried per PTR at 10, and anything beyond the first 10 is ignored (it truncates, unlike the mx sub-limit which produces permerror).

The four problems

• It is slow. Reverse plus forward confirmation on every check. Receivers cap total evaluation time, so slow mechanisms eat headroom that other parts of your record may need.
• It is less reliable under DNS errors. If a DNS error occurs during the PTR lookup, the mechanism simply fails to match - it does not error out loudly, it just silently stops authorizing the sender.
• It puts load on the .arpa nameservers. Every SPF check with a ptr sends traffic to the reverse DNS tree, which serves the whole internet and gets nothing back from your use of it.
• It costs one of your 10 lookups. If your record is anywhere near the limit, a mechanism the spec tells you not to use is an obvious thing to reclaim.

The %{p} macro carries the same warning

If your record uses the %{p} macro anywhere, it resolves the validated domain name through exactly the same procedure and carries the same SHOULD NOT advice. Its PTR queries also count against the 10-lookup limit. If you are removing ptr, check for %{p}in the same pass.

How to fix it

Work out what the ptr was covering.

Almost always it was shorthand for "our own mail servers, whatever their addresses happen to be." The author wanted something that would keep working through renumbering. Pick the replacement based on how often those hosts change:

• If the sending addresses are stable, list them directly with ip4 and ip6. Costs nothing against the lookup limit and evaluates instantly.
• If the hosts get renumbered occasionally, use a against a name you control - a dedicated name whose address records list exactly the sending hosts, and point a at it. One lookup, and you update addresses in one place without touching the SPF record.
• If the hosts belong to a provider, use their published include.

Do the swap before the removal. Add the replacement, confirm the sending IPs are covered, then delete the ptr. The order matters if the record is live.

How this is rated

This is the one SPF finding whose severity depends on the rest of your record. A lone ptr in a healthy record that is comfortably under the lookup limit causes little harm in practice: most receivers still evaluate it, and the genuine downsides are edge cases. DNSAudit rates it Informational in that situation - a note that the mechanism is discouraged and could be cleaned up, not an alarm.

Where ptr actually bites is lookup pressure. When the record is at or near the 10-lookup limit and the ptr is spending one of those lookups, it is rated Warning, because removing it is part of getting the record back under the cap. It is not an exposure finding and it does not break your mail by itself, so it never rates Critical.