On 03/09/2018 01:23 PM, Trey Nolen wrote:
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 220.127.116.11
I leave it up to the reader to test the validity of 18.104.22.168, 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.
(Cavaet: it's been a long, LONG time since I have sent ANY mail to
prodigy.net, att.net, bellsouth.net, or sbcglobal.net. So I don't have
any advice specific to sending mail to servers hosting domains on those
services. Rather, I've concentrated on what I understand to be Best
Practice for mail admins.)
[satch@c74-admin ~]$ dig +short -x 22.214.171.124
[satch@c74-admin ~]$ dig +short mail.internetpro.net.
OK, forward and reverse match.
One interesting point: When I did the full reverse lookup of the IP
address (without the +short), this was part of the ADDITIONAL SECTION:
ns2.internetpro.net. 5999 IN A 126.96.36.199
I would suspect that some people would look at you oddly when your mail
server is also one of your authoritative name servers. I know it's
stupid, but mail admins have for years been trying to figure out
behavioral habits and stigmata of spammers. Are you short of IP
addresses, or stingy with servers?
(I know in my consulting practice I strongly discourage having ANY other
significant services on DNS servers. RADIUS and DHCP, ok, but not mail
or web. For CPanel and PLESK web boxes, have the NS records point to a
pair of DNS-dedicated servers, and sync the zone files with the ones on
the Web boxes.)
That said, I think I see a potential set of problems. The TTL on your
PTR record is too short. Best Practices call for the TTL to be at least
86400, if not longer. Snowshoe spammers tend to have short TTLs on DNS
records so that it's easy to shift to cleaner IP addresses when the
current IP address' reputation is sullied by ne'er-do-well customers or
6000 is only 1.5+ hours. In all the formulas I've seen published, the
accepted TTL was NEVER less than 14400, or four hours.
And your name server record TTLs should be MUCH longer, like 864000 (10
days). Too short a TTL for NS (and SOA) records can be a big red flag
for some mail operators.
What does SPF say for the domains in question? Also, what is the TTL on
the TXT records?