Is a ptr mechanism in an SPF record secure?

Question

If I understand the SPF Record Syntax correctly, any machine with an IP that points to my-domain.com can send email as if it's from my-domain.com if I'm using ptr in my SPF record.

Anyone can create a PTR record for his IP(s).

Then isn't it a security risk to use ptr in your SPF record? It essentially enables anyone to send mail as if it were from your domain.

According to the specification, it isn't recommended to use this mechanism, because it results in many DNS lookups. However, it doesn't say anything about security.

---

^{Background: recently, GMail has started marking email (manually sent) from my domain as spam on several accounts. I'm carefully going through my DNS records, server logs, etc., to find the cause and resolve this issue. I removed the mechanism already from my DNS records, but I'm still curious as to why this mechanism doesn't impose a security risk.}

Answer 1

PTR records are a security issue in my opinion, and I'm surprised it's not called out in either the Security Considerations or Eratta.

This is an opportunity for someone to submit such a security note regarding this.

Answer 2

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.