A PTR record is the opposite of an A record. Instead of resolving a domain name to an IP address, it resolves an IP address to a domain name. The procedure of resolving a PTR record in SPF is as follows:

  1. The connecting IP address is taken and a reverse-mapping for it is made in “in-addr.arpa” format for IPv4 and in “ip6.arpa.” for IPv6 to find any domain names.

  2. For each domain name (has to be exact match or a subdomain of the target domain) returned, a forward lookup is made to find its IP address. 

  3. If the connecting IP address is among the returned IP addresses from the lookup then the domain name results in a match.

As it can be seen this mechanism is slow and not as reliable as other mechanisms. Therefore it should not be used as per RFC: https://tools.ietf.org/html/rfc7208#section-5.5 

Other mechanisms should be used instead, such as: "a", "mx", "ip4", "ip6", or "include".

Besides from being slow and unreliable some receivers may decide to skip a ptr mechanism or skip the whole SPF record which may lead to failures. Therefore, the ptr mechanism should not be used.

If you are using Dynamic SPF, we have enabled a feature that discounts these mechanisms from the SPF calculations but still leaves them at the end of the SPF record in case the receiver supports them. As a result you might get a warning when checking your SPF entry that it exceeds the 10 lookup limit, but this is not the case as the PTR mechanisms are mostly unsupported and at the end of the SPF chain.

Did this answer your question?