The ptr mechanism is at commonly seen in SPF records and there is a reason for this. According to RFC 7208 section 5.5, it ‘SHOULD NOT’ be used. According to RFC 2119, SHOULD NOT means NOT RECOMMENDED which means that there may still be valid reasons and it is still allowed but the implications should be weighed up before implementing.
In order to explain why the ptr mechanism shouldn’t be used, we’ll need a better understanding of how the ptr mechanism works.
The ptr mechanism is specified using one of the below methods:
- ptr
- ptr:domain.com
How does it work?
When you specify a ptr mechanism in your SPF record, the below process takes place:
- The receiving mail server does a reverse lookup on the sending mail server’s IP.
- Once a list of domain names is found, a check is done to see if they match the sending email domain or the specified domain if using ptr:domain.com or are a subdomain of the sending email domain or the specified domain if using ptr:domain.com.
- A forward lookup is then done on each domain name to get a list of IPs. The sending mail server’s IP is then checked against this list of IPs and if there is a match then the sender is permitted.
Why shouldn’t it be used?
The first problem here is that there the receiving mail server needs to do a large number of DNS lookups which takes time and reduces performance.
The second problem is that the IP owner is the one who owns and manages the PTR records which means that the owner of the domain doesn’t always have control over the number of lookups that are involved when specifying the PTR mechanism.
What should be done instead?
Other mechanisms should be used. You can use either ip4, a or mx mechanisms to specify multiple IPs or the subnets of these IPs or you can use include to include another SPF record if you have a large number of IPs that are permitted senders.