Querying every nameserver directly — this takes a few seconds.
Querying every nameserver directly — this takes a few seconds.
ptr mechanismmailauth.spf-ptr
ptr is deprecated and unreliable — some receivers ignore it outright.
The ptr mechanism asks the receiver to look up the reverse DNS for the connecting address, then forward-resolve each name it gets back to see whether any of them land on that address and match your domain. It is the only SPF mechanism that requires the receiver to do work proportional to somebody else's DNS configuration.
It is formally discouraged. RFC 7208 says it SHOULD NOT be used: it is slow, it puts load on reverse DNS infrastructure that the domain owner does not run, and its result depends on rDNS records that are frequently wrong or missing. Some receivers skip it entirely, which means a record relying on ptr can pass at one destination and fail at another for reasons you cannot observe.
It also spends one of your ten lookups, and often more, for a result you cannot depend on.
Replace it. If the hosts you were trying to describe have stable addresses, list them with ip4 and ip6, which cost nothing against the lookup limit and are unambiguous. If they belong to a provider, use that provider's include.
If ptr was there to cover "our own servers, whatever they are", that is a sign the sending estate is not written down anywhere. DMARC aggregate reports will tell you what is actually sending, and the answer is usually a short and stable list.
SPF avoids the ptr mechanism is one of 49 checks in every report, alongside delegation, mail authentication, TLS and registration.