Proper Email Server Configuration - Properly Configure Your Public DNS

sizcache="" sizset="47">

When one 1st tackles the project of receiving Web mail delivered to their mail system, you are rather speedily pointed to the need for finding an MX record published within your domain's public DNS zone. It is this record that tells all of the other mail servers on the planet where to route e-mail destined for your domain.

What most do not tell you is the importance of finding both the forward (A record) and reverse (PTR record) DNS entries right for the server that is the send connector. In some circumstances this is the similar server as the receive connector, but it does not need to be. It is extremely vital that any server that is configured as an Internet Send Connector have both a forward (A record) and reverse (PTR record) published in DNS, and that these records specifically match what you have entered in the FQDN field on the common tab of your Send Connector. If this 1 server is hosting each the send and obtain connectors, the MX record should certainly also point to this same name. If your organization accepts mail for additional than one domain, simply point the MX record in each domain to the same FQDN. There is no requirement that an MX record point to a server in the same DNS domain as the MX record.

You may possibly be thinking, "Why is it so very important that all of these names match?"...  The underlying reason is that mismatched entries and a lack of a reverse DNS entry are utilized by most Anti-Spam services as a signal that mail messages from this host really should be treated as Spam. Some organizations, such as AOL and Comcast, go as far as to outright block mail from hosts that do not have a matching reverse DNS entry. If your organization's email is to get delivered, you will need to do every thing you can to lower the suspicions of the Anti-Spam services.

You can check your organization's DNS entries swiftly and very easily making use of the tools at . To appear for the forward or A record of your server, simply enter a:Servername in the command box, exactly where Servername is the completely qualified domain name of your server as entered in the FQDN of your Send Connector within Exchange. To look for the reverse or PTR record, simply enter ptr:IPAddress in the command box, where IPAddress is your server's public IP address. If the outcomes of these queries are consistent, you are all set. If not, do not fret the fix is not complicated.

Acquiring the forward (A record) entry published in DNS is no various than publishing any other address. You basically function with your DNS hosting provider to publish the name you have setup for your send connector just like you did when you added your MX record or published the WWW address for your domain by offering them with the full name and apparent IP address. It is the reverse entry or PTR record that is a bit tricky. This is considering that you cannot directly publish your own PTR record as you are most most likely not the owner of the IP block your organization is making use of your ISP is. You merely need to have to work with your ISP to publish the reverse entry. This is a common request and quite a few of the larger ISPs have even added this functionality to their consumer self-aid portals. This approach only works although if you have a static IP address/range from your ISP.

 If your Net service is becoming issued a dynamic address, this above approach will not function. Assuming that you need to make certain your mail is delivered you will then have a selection to make. You can either change your ISP service to one with a Static IP range and follow the directions above, or use a "Smarthost". A Smarthost is basically yet another server or servers on the Internet that "Trusts you". This is ordinarily a paid service where they give you with a username/password combination to authenticate your mail server regardless of the IP address it is working with at the time. It is these servers that then deliver your mail messages to their ultimate destination. Your ISP will normally supply this service, so start off with them 1st. It is very important that you make confident that they do not supply this service for their buyers as several ISPs actively block SMTP (email) visitors from their entire dynamic IP service range to maintain themselves on superior standing.