Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a client whose ISP recently switched their circuit and static IP to an IP that was already blacklisted for SPAM (nice).

The client is running Windows SBS 2003 with Exchange 2003 and DNS for the mail system is managed by GoDaddy.com.

When I ran the smtp test at http://mxtoolbox.com (MXTB) I was receiving a warning 'Reverse DNS does not match SMTP Banner' after the IP switch and updating the hosted DNS records (A, MX, etc...) at GoDaddy. I was able to squash that warning by setting the FQDN and Masquerade domain on advanced delivery options for the SMTP service in Exchange to the value returned on reverse DNS at MXTB (i.e., pool-##-###-###-##.fairpoint.east.myfairpoint.net - guess who gave us a dirty IP). I also added an SPF record for all A records on the GoDaddy account. It's been about 12 hours since these changes were made but my client's domain is still showing on a couple blacklists, spamrats in particular and when I use their delist form it still complains about a failed reverse DNS lookup.

Here are the lookups I get in terminal (obfuscated): nslookup 66.###.###.53

Non-authoritative answer: 53.###.###.66.in.addr.arpa name = pool-66-###-###-53.man.east.myfairpoint.net

nslookup clientdomain.com

Non-authoritative answer: Name: clientdomain.com Address: 66.###.###.53

Not being an Exchange expert I could use some direction and/or a sanity check: 1 - should FQDN and masquerade in Exchange be set to the long form name noted (pool-##-###-###-##.fairpoint.east.myfairpoint.net) or just mail.clientdomain.com? 2 - is this likely a propagation problem and I just need to be more patient? 3 - shouldn't the ISP be able to resolve the reverse lookup correctly for us since they own the IP?

Right now client users are being bounced by some (not all) mail servers on send related to being listed.

Many thanks.

share|improve this question
1  
per my answer: just talk to your isp and have them fix the reverse dns record for your ip address to match the hostname you configured with godaddy –  username May 12 '11 at 19:28
add comment

3 Answers

A couple of things I would recommend. In my opinion this may be the easiest way to set things up without getting in to a lot of unneccessary details. For more info than I'm providing, follow the link that SmallClanger posted in his answer.

  1. You don't need to set the masquerade domain but you should set the FQDN on the SMTP virtual server in Exchange.

  2. Set the FQDN in Exchange to match the name you're going to set in your MX record. This is probably going to be something akin to mail.clientdomain.com.

  3. Set your SPF record to "v=spf1 mx -all".

  4. Ask the ISP to create or modify the PTR record to match the FQDN that you set on Exchange.

This is a very simple answer that does not consider any additional variables or a more complex set up or requirements.

share|improve this answer
    
Thanks for that. Very concise list of exactly what was needed and finally done. –  bchesley May 13 '11 at 11:04
add comment

Sorry if i haven't read your post carefully enough, but you realize the reverse record is 'owned' by your ISP? You say you changed some record at GoDaddy... just wondering if you're getting your forward and reverse records confused. If so, contact your ISP and have them set their DNS for the IP to your FQDN

What i'm trying to say is that where DNS is concerned...

  • you have the right to tell the world: "foodomain.com." points to "1.2.3.4"

but

  • your ISP is the one who can tell the world: "1.2.3.4" points to "foodomain.com."

If both records don't match, it causes problems with certs, etc

share|improve this answer
    
Thanks for that. The ISP has now created the required PTR record. –  bchesley May 14 '11 at 9:47
    
nice, glad to hear it's sorted. it's not very sophisticated of me (as a Mac guy i should be opening Terminal and using something like "host 1.2.3.4" if i don't trust "changeip -checkhostname"), but to be honest i often check that forward and reverse are okay using a web service. lookupserver.com etc –  username May 14 '11 at 18:46
add comment

Often it just takes time for blocklists to drop IPs from their lists. Depending on their implementation it could be 24 hours, or it could be a month. Each list's own FAQ should tell you how long. They often have a removal request system you can go through if the delay is going to be too long. (Some will even charge for express de-listing, as if this wasn't a massive conflict of interest.)

It isn't necessary for the PTR record for your IP to match either the SMTP EHLO or the mail domain. It wouldn't hurt, but in many cases (especially if you don't have a static IP), it's impossible. I don't recommend going the other way and setting your EHLO greeting to match the PTR record, since that certainly won't match your mail domain, which is certain to result in more dropped mail than you're currently seeing.

Any recipient that blocks because the PTR doesn't match is broken.

share|improve this answer
    
ISP finally revealed that they can set a PTR on their end (4 hours of effort later) and once done delisting was successful for one BL. –  bchesley May 13 '11 at 11:03
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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