Quoting Wikipedia,
"Typically, computer networks use the Domain Name System to determine what IP address is associated with a given domain name. So, to reverse-resolve a known IP address is to look up what host and domain name belongs to that IP address.
Network administrators often refer to a reverse lookup as reverse resolving, or more specifically reverse DNS lookup, and is accomplished using a "reverse IN-ADDR entry" in the form of a PTR record." |
In layman's terms, you can think of an RDNS entry in your nameserver as an IP address that points back to a domain name. This is a strange concept, because we're mostly concerned with figuring out what IP address a domain name is pointing to, the exact opposite of RDNS (that's where the REVERSE comes in I suppose). Though there are likely other uses for it, RDNS for a webhost is primarily discussed in terms of email - it is standard practice for a recipient mailserver to check the RDNS entry of the connecting server before it accepts a message. AOL does this with the zeal of a religious fanatic, and has for some time. So, in order to send email effectively you need to ensure that your sending server has a proper RDNS record configured. I won't go into the configuration details since your host will likely take care of that for you, however here is the basic premise:
1. The server you send mail from must have an RDNS entry.
2. That entry must correspond to either
a. The primary IP address of the sending server (the default IP used to send by mail programs).
b. The IP address specifically assigned to send mail by the mail program. |
To elaborate on 'b' - SmarterMail, for example, has the ability to set EACH DOMAIN to send on it's own IP address - you can choose any IP that is bound to the server, and IPs can be re-used if you like. The easiest way to see what IP is being used, aside from checking the mail program's configuration, is just to send a message to an EXTERNAL mail account (aol, yahoo, hotmail, et al.) and then when it gets there check the message header to see the IP of the last server that touched the message before the remote recipient server recieved it. For more information on checking headers, see
http://www.hostmysite.com/support/email/headers/
That last paragraph had an important point buried in it:
THE ONLY IP THAT MATTERS IS THE IP OF THE LAST SERVER THAT PROCESSED THE MESSAGE BEFORE ITS DELIVERY. For example, in a common header you will see an entry for your local machine's IP if you sent the message via MS Outlook or some other similar mail program. That local IP address (which likely belongs to your ISP) does NOT need to have RDNS setup since it's not the server that actually tried to deliver the message. This is a VERY important concept to understand because in it lies the key to understanding EVERY mail delivery problem...i.e. check the last server on the sending side that had the message since that is where the problem will lie.
If you're sending mail via a web-based form (i.e. a 'contact us' form) then the sending server could be the webserver itself if the webserver is configured to send it's own mail, or it could be some sort of relay server if you're webserver (or the script you're using to send) is configured to bounce the message off another server for processing before delivery to the recipient server.
Read this several times if needs be; the concept here is the same one that is used by our technicians to determine exactly why a message bounced...and while it's a tedious process tracking the route a message took and the servers that handled it before it reached the recipient server is the best method to figuring out where your message went awry.
