4

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.

3
  • A PTR-Record is assigned to an IP-Address with a [Fully qualified Domain Name][1] as value. So you need to set a PTR-Record for your IP to anything.example.com to be a designated sender for example.com. However, you don't have the rights to do that. Only the holder of the IP can set the PTR and he has to check if you are allowed to do that. Is your question about how easy it is to set up a malicious PTR?
    – sebix
    Feb 17, 2015 at 17:16
  • @sebix yes to the last question: if somedomain.com has ptr in its SPF record, I can setup a PTR record on my IP to point to somedomain.com and send mail from that domain without any problems, right? Why is this not an issue?
    – user21287
    Feb 17, 2015 at 17:35
  • 1
    The accepted answer is wrong. 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.
    – glts
    Oct 31, 2022 at 10:03

2 Answers 2

2

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.

1

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.

2
  • Upvoted, though I wonder what your (emphasised!) suspicion is based on. As you note yourself, ptr has for ever required a forward-confirmed PTR record. The ptr mechanism, while deprecated for certain (frankly, hand-wavy) reasons has never had the problem of being insecure as far as I know. Cheers.
    – glts
    Oct 31, 2022 at 17:54
  • I'm in anti-spam and have written and reviewed SPF interpreters. That doesn't mean any of those made it to production without the extra DNS query for FCrDNS, but other implementations probably have. This is only insecure if there is no FCrDNS check. The slowdown comes from the ARPA servers used for the reverse check (and the fact that it's one entry with two DNS queries out of the allotted ten).
    – Adam Katz
    Oct 31, 2022 at 19:27

You must log in to answer this question.