One of our partners receives our mails with noticeable delays. The same mail sent to two addresses under their domain are sometimes delivered at their server hours apart (checked in the actual server logs, not just the user mailboxes). I suspect a mismatch in the reverse DNS setup is causing this issue, but I'm not sure that would result in these errors.
We are using G Suite (Google Apps for Business), they are using Exchange on their own premises (not sure what version). They have two internet connections at their office, and the Exchange server is reachable on both IP addresses (so from the outside I can telnet 1.1.1.1 on port 25 and 2.2.2.2 on port 25 and get the same responses).
Let's say the domain is example.com. The MX record points to mail.example.com, and mail.example.com resolves to 1.1.1.1 and 2.2.2.2. 1.1.1.1 is under their control, the PTR record for 1.1.1.1 resolves to mail.example.com. The 2.2.2.2 address is not under their control, the PTR record points to 2-2-2-2.static.their-isp.com. The SMTP mail server has a banner of mail.example.com.
I am mentioning these PTR records because tools like MXToolBox mention this SMTP header mismatch, but after reading similar questions here it's not clear to me whether that only applies to sending mail from that domain (and spam filters on the receiving side), or also receiving mail there.
In the past their DNS setup was different: they has two MX records, pointing to mail.example.com and mail2.example.com, with mail.example.com resolving to 1.1.1.1 and mail2.example.com resolving to 2.2.2.2. The SMTP banner was still just mail.example.com. Many mails were delayed but still received after a while. For one mail I got the following warning from Google:
Technical details of temporary failure:
The recipient server did not accept our requests to connect. Learn more at https://support.google.com/mail/answer/7720
[mail.example.com. 1.1.1.1: timed out]
[mail2.example.com. 2.2.2.2: unable to read banner]
I interpreted this as meaning that the connection via 1.1.1.1 was down, the connection via 2.2.2.2 was up, but Gmail refused to deliver the message because the SMTP banner (mail.example.com) did not match either the PTR record of 2.2.2.2 (2-2-2-2.static.their-isp.com) or the DNS record used to find 2.2.2.2 (mail2.celds.com). After I mentioned this to them, they changed to the setup mentioned above.
But today I compared this to the MX setup of G Suite, and their setup is similar:
– MX record: ASPMX.L.GOOGLE.COM
– which resolves to 209.85.202.27
– which reverses to dg-in-f27.1e100.net
– SMTP banner is mx.google.com
MXToolBox also mentions this SMTP Banner Check as a possible issue, but I assume Google knows how to configure their servers 🙂
So, what I want to know: can any of the settings above cause the issues we see: Google only being able to deliver some messages to their servers after a big delay? Or are there other obvious places where we should be looking?
Best Answer
The standard is the ptr points to an A record that points to the ip of the ptr. The mx records and their destinations aren't in play.
So the query is from the IP, pull the PTR record, from the A record, pull the IP.
Here's how you test it:
Additionally autogenerated PTR records are always marked invalid/bad.