email delays from Google
We have been experiencing delays / failures receiving email from domains hosted by Google and *only* domains hosted by Google. This is happening to customers for whom we host the authoritative DNS servers. For some reason, Google is not able to look up the MX and/or A record *sometimes* from our servers. Customers are getting an error like this: --BEGIN DNS Error: 49391460 DNS type ‘mx’ lookup of responded with code NOERROR 49391460 DNS type ‘’ lookup of mail.internetpro.net <http://mail.internetpro.net>. responded with code SERVFAIL 49391460 DNS type ‘a’ lookup of mail.internetpro.net <http://mail.internetpro.net>. responded with code SERVFAIL --END In the above case, Google is saying they can't find our mail server. There is no record, so that part is normal. However, we have other customers who are hosting their own mail servers or are using relay services such as Trend Micro who are also having a similar issue. The only thing these customers have in common is our DNS and the fact that Google is trying to send email to them. I can query Google's public servers at 8.8.8.8 and 8.8.4.4 and they always give the correct answers, but it seems that internally, Google is unable to make these lookups. Reaching out to their support agents online, the agents confirm that the correct entries are in place and that *some* of Google's servers can't do the resolution resulting in sporadic email delivery. They suggest that we reach out to the DNS provider to find out why (Grrr) We've also had reports from customers that the failures seem to be location oriented with western US emails being held up and eastern US emails coming through. I can't independently confirm that, though. A full 100% of the email delivery issues have been Google hosted domains. It seems that every other ISP can do the lookups just fine, but getting in touch with someone at Google who can troubleshoot this is impossible for a small ISP like us. If anyone can point me to somone at Google who could help me out, I'd be very thankful. Trey Nolen
problems sending to prodigy.net hosted email
We are having issues with domains hosted on prodigy.net email servers including att.net, bellsouth.net, and scbglobal.net. We are being rejected for bad reverse DNS, but DNS is setup correctly. The error we are receiving is: Remote host said: 550 5.7.1 Connections not accepted from servers without a valid sender domain.flph829 Fix reverse DNS for 74.252.14.252 I leave it up to the reader to test the validity of 74.252.14.252, but every test we've done looks good. The MX records for these domains indicate this (identical on the three domains mentioned above): ;; ANSWER SECTION: att.net. 175 IN MX 5 al-ip4-mx-vip1.prodigy.net. att.net. 175 IN MX 5 ff-ip4-mx-vip2.prodigy.net. att.net. 175 IN MX 5 ff-ip4-mx-vip1.prodigy.net. att.net. 175 IN MX 5 al-ip4-mx-vip2.prodigy.net. Everything we can find on the postmaster pages, forums, etc. point to emailing abuse_...@abuse-att.net. We have done this and received their autoresponder. We've waited the requisite 48 hours and emailed again for an escalation only to receive another autoresponder with another ticket number attached (even though we emailed with a ticket number in the message). This has now been ongoing since at least March 4, when we received our first complaint and we have yet to hear anything from AT We don't currently have any direct contacts for Prodigy.net. I will say that the 75.252.14.0/24 netblock is owned by AT and I'm wondering if that might be causing the issue. For instance, they are trying to do a local lookup of the PTR record instead of contacting the delegated servers. I'm hoping someone here has a point of contact which I might reach out to in order to correct this issue. Any help would be appreciated. Trey Nolen
contact ATT
We have a managed router which AT has put in place. Because it is managed, we do not have control over the router. It is going down every 5 to 6 days. We were assured that it was a known issue for the model we have and worked for over 2 weeks to get the firmware updated. The update did not fix the problem and we desperately need to find someone at AT who has the authority to replace this router. If someone can contact me off list to help me get this accomplished, I'll be glad to furnish the tickets for circuit history and such. Thanks. Trey Nolen
