Yes and no. Technically, assuming a faithful implementation of the SPF specification, PTR should be secure but slow. It is therefore strongly discouraged.
The potential for abuse is that any network operator can specify any domain as the PTR record for an IP they control, and I have definitely seen IPs claiming to resolve to domains that they clearly have no affiliation with.
Enter RFC 7208 §5.5, "ptr" (do not use) (yes, the spec actually says that), which states:
The ip
's name is looked up using this procedure:
- Perform a DNS reverse-mapping for
ip
: Look up the corresponding
PTR record in "in-addr.arpa." if the address is an IPv4 address
and in "ip6.arpa." if it is an IPv6 address.
- For each record returned, validate the domain name by looking up
its IP addresses. To prevent DoS attacks, the PTR processing
limits defined in Section 4.6.4 MUST be applied. If they are
exceeded, processing is terminated and the mechanism does not match.
- If
ip
is among the returned IP addresses, then that domain name
is validated.
It is essential that the ptr
mechanism passes FCrDNS (the host in the IP's PTR record must actually point back to the IP). I suspect some implementations do not verify the FCrDNS and therefore attackers can simply alter their PTR records for rDNS that appears to pass SPF.
However, that's not the reason the ptr
mechanism is discouraged. The spec goes on to say:
Note: This mechanism is slow, it is not as reliable as other mechanisms in cases of DNS errors, and it places a large burden on the .arpa name servers. If used, proper PTR records have to be in place for the domain's hosts and the "ptr" mechanism SHOULD be one of the last mechanisms checked. After many years of SPF deployment experience, it has been concluded that it is unnecessary and more reliable alternatives should be used instead. It is, however, still in use as part of the SPF protocol, so compliant check_host() implementations MUST support it.
This is an older question and it refers to the original spec, RFC 4408 §5.5, which said "for each record returned, validate the domain name by looking up its IP address", so it required FCrDNS as well. When RFC 7208 obsoleted this spec, the ptr
mechanism was much more strongly discouraged. In addition to the "(do not use)" added to §5.5's title, RFC 7208 Appendix B, Changes in Implementation Requirements from RFC 4408, notes:
Use of the ptr mechanism and the %p macro has been strongly discouraged (Sections 5.5 and 7.2). The ptr mechanism and the %p macro remain part of the protocol because they were found to be in use, but records ought to be updated to avoid them.
ptr
requires a forward-confirmed DNS setup (IP → domain → IP), it isn’t sufficient for someone to just set up a PTR record. See the other answer.