1

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?

  • They have two internet connections at their office, and the Exchange server is reachable on both IP addresses. - Can you give us more detail on what that means? The MX records point 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, 2.2.2.2 address is not under their control. - Do the MX records have the same priority/preference? – joeqwerty Mar 23 '17 at 14:30
  • @joeqwerty: Clarified in question: both IP addresses can be used (from the outside) to reach the mail server, and they currently have one MX record, not two. But the domain name mentioned in that MX record resolves to two IP addresses. – Jan Fabry Mar 23 '17 at 15:12
  • OK. Now I understand. I had mistakenly thought that you were dealing with two different servers. At this point the easiest thing to do would be to have the ISP for the 2.2.2.2 ip address create the PTR record to match that of the 1.1.1.1 ip address (mail.example.com). After that's done see if the problem persists. – joeqwerty Mar 23 '17 at 15:19
  • I would check first their routing setup and second - their arrangements with their ISPs. I suspect the issue may be that the connection comes to one of their addresses and response is routed back through the other ISP. The other ISP may be dropping this response. The most important question to check if their have BGP peering (they probably should) and if not - if they use policy based routing (they likely should if not BGP). I suspect the delays last at least that long as their main internet connection is down. – Tomek Aug 1 at 15:17
0

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:

dig A $(dig -x 209.85.202.27 +short) +short
209.85.202.27
66.102.12.27
216.239.32.27

Additionally autogenerated PTR records are always marked invalid/bad.

2-2-2-2.static.their-isp.com = autogenerated/generic1
  • This "double dig" works for both addresses (1.1.1.1 and 2.2.2.2). How would someone know that the ISP records are auto-generated, and mark them as invalid? Via regexes in spam filters? But even then: does this also affect delivery to this SMTP server, and not only sending mails from these servers? (That's what I understood from other answers: you want your PTR records, so others will not mark mails sent from your servers as spammy, but this is the other way around.) – Jan Fabry Mar 23 '17 at 15:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.