Monday, October 02, 2006

Mail: Mail delayed when sending to – part 2

It looks like is now requiring that reverse DNS lookups on incoming mail contain the fully-qualified domain name (FQDN) of the sending organization, and no longer just the IP address. This appears to be a change from when I first came across the policy during my original post on the Mail Delayed to AOL topic.

You can find the details of the policy here:

“Reverse DNS must be in the form of a fully-qualified domain name. Reverse DNS containing are not acceptable, as these are merely placeholders for a valid PTR record. Reverse DNS consisting of IP addresses are also not acceptable, as they do not correctly establish the relationship between domain and IP address.”

You’ll note that this is more specific than what we recently saw with the SORBS issue, and having the PTR “look static enough”.

I wonder how other SBSers handle this… Do you have the client's ISP set up reverse DNS to respond with the FQDN as part of your deployment procedure? Should it be part of your procedure? Or are you just reacting?


Anonymous said...

I've contacted numerous ISP's both local telcos, cable providers for business and good local ISP's and so far I found ZERO providers that will create a PTR record. All of them just insist I'm setting up incorrectly or just tell me to use a smart host, even when on a static connection.

Nick said...

An ISP provided smart host would be a good alternative. That said, I havn't had any problem with local ISPs not configuring reverse DNS to respond with a host name for clients that have static IPs. What kind of local market do you have (size, number of ISPs, etc.).

Side note - I always start my requests with the WHOIS technical or abuse contact for the ISP. Starting with the customer support desk would probably take too much time, and not provide you with good information. Also, having a customer rep at the ISP/local telco to act as your go-to person might be helpful as well.

Nick said...

I did a follow-up post on working with your ISP to justify the need for making changes to the PTR record. Check it out here: