Skip to content
Inspect My DNS

Mail authentication

SPF avoids the ptr mechanism

mailauth.spf-ptr

ptr is deprecated and unreliable — some receivers ignore it outright.

What this check measures

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.

How to fix it

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.

References

Run this check on a domain

SPF avoids the ptr mechanism is one of 56 checks in every report, alongside delegation, mail authentication, TLS and registration.