Here's the scenario...
You're managing several domains on one IP address (beevis.com, butthead.com, and LakersSuck.com), using host headers with your web server in order to do so successfully. If you're unfamiliar with what "using host headers" means, it's a cryptic way of saying that "whenever a user arrives at your web server, check to see what the URL is and redirect them to the appropriate subdirectory based on that value". In our scenario, you're also managing your own email server, perhaps using something like Smartermail, so each of your domains can have their own email addresses (info@beevis.com, info@butthead.com, info@LakersSuck.com).
The Challenge...
Everything's working great for you. User's are being redirected to the appropriate subdirectories on your web server, and you're sending and receiving emails via each of those email addresses just fine. Oh, wait...SOMETIMES the email you send out doesn't arrive at its destination! A glitch in the system? A random gremlin in the processor? A rogue process? After many hours of re-doing settings, checking settings, system restarts, and hunting for common denominators with your clients, you finally stumble upon the fact that it's mostly only emails going to people who use AOL that are not making it to their destination, along with a few other friends who are using their local cable company for email. You turn on logging and watch for any clues, googling what you find until at last you have distilled things down to their cause: Your domains do not have a reverse DNS record in place. What this means is that an outside system cannot take your IP address and look it up to make sure it's associated with the actual domain that is sending the email.
Here's the clue from the mail server's log file:
"Failed Recipient: blabla@aol.com
Reason: Remote host said: 450 #4.1.3 Relaying temporarily denied. Cannot
resolve PTR record for 208.112.55.164"
Further substantiation from AOL's own site (http://postmaster.aol.com/guidelines/standards.html) solidifies that this is indeed the issue:
"AOL's mail servers will reject connections from any IP address that does not have reverse DNS (a PTR record). "
Whew! At least now you know what's causing this faux random issue! Okay then, let's just add a reverse DNS record for each of our domains so that when a receiving system does their look up, they can see that you really are who you say you are.
The Additional Challenge...
After many MORE hours of attempting to create reverse DNS records (PTR records), you figure out that any given IP address is only allowed to resolve back to a single domain name. So your whole configuration of sharing one IP with several domains has now suddenly become a very bad idea, and it's time to give each its own address.
The Solution...
Tech support provides you with two new IP addresses, which you can see and verify on your Windows system by going to your Control Panel --> Network Connections --> [your connection name] --> Properties -->TCP/IP --> Properties.
Assign each of your domains a new IP address in your web server, then edit your DNS entries for each of those domains to reflect the new IP address. It is quite likely that, if you're using hosting, you will not be able to create your own PTR record and will have to contact your host to do this for you (that is the case with Host My Site), so just make sure you have them do that. After the reverse lookup records are in place, you can verify them by visiting http://remote.12dt.com/lookup.php and typing in the IP address. It should come back with the domain name you assigned to it.
Let everything simmer for 24 hours, just to account for whatever propogation delays and caching are floating around, and give things another whirl. You should be good to go at this point.
Doug out.
You are not logged in, so your subscription status for this entry is unknown. You can login or register here.
http://www.openspf.org/
Also ensure that you are properly using SENDER and/or FAIL-TO headers so that your outbound mesages don't look like forgeries.
http://www.openspf.org/Best_Practices/Webgenerated
"AOL's mail servers will reject connections from any IP address that does not have reverse DNS (a PTR record)."
A slightly stricter process it to make sure reverse matches forward with FCrDNS.
Name based Virtual Hosts can typically still be used with FCrDNS, the system doing the checking does a look up on the reverse DNS and then does a look up on the returned hostname to verify that it resolves back to the original IP address. So it is possible to have:
vhost1.com ----> IP_ADDRESS ----> mainhost.com ----> IP_ADDRESS
As long as IP_ADDRESS = IP_ADDRESS it will be accepted.
There seems to be a myriad of reasons why email is blocked, and there are a myriad of good ways to resolve the problem. It is a disservice to suggest that every HTTP based website have a unique IP address to send email reliably.
I think what blech is saying (and I agree) is that your solution of having a dedicated IP for each domain is overkill. Public IP4 addresses are a scarce resource (which is why we use host-headers and Network Address Translation to share them) and responsible ISPs will normally ask you to justify their use. Needing to use SSL on the domain (because Host Headers won't work over SSL) is a valid reason, but I don't think wanting domain specific ReverseDNS is.
As blech says it should normally be enough that the IP address being used to send mail *has* a reverseDNS/PTR record, not that it necessarily matches the domain. That should satisfy the receiving mail server that the IP address has at least been set up properly on an identifiable network. It's not reasonable to expect every domain to be resolvable back to a unique IP address: there simply aren't enough addresses to go round under IP4.
As James says, having proper a correctly configured SPF record in your domain's DNS and using headers properly are a better way of adding credibility your outgoing mail.
Cheers