auth.spf.ptr_mechanism

Deprecated PTR Mechanism

What we check

We scan the SPF record for the ptr mechanism (ptr or ptr:domain). RFC 7208 §5.5 states this mechanism SHOULD NOT be published — it is slow, unreliable across resolvers, and places a heavy load on the .arpa reverse-DNS name servers.

What this finding means

Your SPF record uses ptr. To evaluate it, a receiver has to reverse-look-up the connecting IP to a hostname, then forward-look-up that hostname to confirm it points back — a fragile, multi-query process. Many providers no longer support it well, and a brief reverse-DNS timeout can make legitimate mail fail SPF.

Why it matters

Unreliable results. The mechanism depends on reverse DNS that you often don't control; a slow or missing PTR can flip your SPF result unpredictably.
Lookup budget. ptr is one of the terms that count against the 10-lookup limit, and each evaluation can trigger several underlying queries — spending your budget fast.
Better options exist. After years of deployment experience the standard concludes ptr is unnecessary; direct ip4:/ip6: or include: are faster and dependable.

How to fix

Replace ptr with explicit mechanisms. For servers on static addresses, list the IPs directly (zero lookups); for third-party senders, use their include::
```
example.com.  IN  TXT  "v=spf1 ip4:203.0.113.0/24 include:_spf.your-provider.example -all"
```
Remove the ptr term entirely once the replacement mechanisms cover the same senders.

How it's graded

A deprecated ptr mechanism carries a 5-point deduction in the Authentication category. See Grading Methodology for the full scoring model.

Evidence example

$ dig +short TXT example.com
"v=spf1 ptr ~all"
        ^^^ RFC 7208 §5.5: "SHOULD NOT be published"

References

RFC 7208 — Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1