Hi Scott
OY... because mail is dealt with in many different ways, what we usually tell people to do is ask the end mail server support folks to give them the exact syntax to place in the DNS Zone. Now we could just use the info they gave you, but we have found that half the time it doesnt work first time outa the box. This results in 'finger pointing' as to where the problem lies, so our rule of thumb is to take what they give you exactly. If it doesnt work then, its their job to figure out what they either did wrong on their server end or told you to do wrong on our end.
Just FYI, here is a copy & paste from a very simple article explaining how MX records work. Having 7 of them...well...that is pretty darn unusual.
peace
Wolf
MX Entries Made SimpleMX entries are used when preparing to send SMTP mail to a remote system. The provide various options for the people who run the remote system related to mail delivery.
MX records are the responsibility for the domain name server. Here's how it works: suppose an SMTP client wants to send an e-mail message to the SMTP server at SANDH.COM. The first thing it should do, before even trying to translate SANDH.COM to an ip address, is to see what MX records exist for SANDH.COM. There don't have to be any -- if there are not then the mail is delivered to SANDH.COM.
Let's suppose that there are MX records for SANDH.COM, and consider a few ways they might work. First, suppose that the kind folks at S&H figured that there ought to be an MX entry, just for the heck of it, and that it should point to their single, main, public computer. What they would do -- and do in fact do -- in this case is place an appropriate entry in their DNS control files so that a single MX "record" is returned for SANDH.COM which points to NG.SANDH.COM, whose IP address is the same as just good ole plain SANDH.COM. Perhaps the curious user would like to see what this looks like; it goes in DB.NAM:
IN MX 10 ng.sandh.com.
You can ask your own DNS to find out what the MX entries for SANDH.COM are by using the command "NETCHECK/MX SANDH.COM".
When your SMTP client wants to send mail to
dan@sandh.com, it asks its domain name server for the list of MX records associated with the domain "sandh.com". The DNS responds "yes, there is 1: ng.sandh.com". The SMTP client then translates (via another request to the DNS) ng.sandh.com to an ip address and proceeds to connect to the SMTP server at that ip address.
This example underscores the basic mechanism for sending mail from SMTP clients to servers but does little to help justify the existence of MX entries. Let's take another example: our friends at sandh.com now have such a mountain of incoming mail that SMTP clients around the world are often experiencing connection timeouts because the mail server is so busy. To keep up with the traffic, they add a second computer to act as a mail server, and a second record in their DNS control file. The mx entries now look like this:
IN MX 10 ng.sandh.com.
IN MX 10 bundy.sandh.com.
Let's walk that SMTP client through its mail task again. It needs to send mail to
dan@sandh.com, so it asks the DNS for the MX records associated with sandh.com. "Yes", says the eager DNS, "there are two of them: ng.sandh.com and bundy.sandh.com". The client first tries to connect to ng.sandh.com, but the connection times out. So, in a determined effort to deliver the mail, the client tries the next mx entry, translates bundy.sandh.com to an ip address, and -- voila -- the connection is accepted! the mail goes through! The world is saved!
Before we slam into the end of this article, let's take one more example of how MX records can be used. The nice folks at S&H have developed a working relationshipo with the even nicer folks at nashville.com, so that if both the S&H servers are down, the mail can still be delivered to the backup system. The revised MX records now look like this:
IN MX 10 ng.sandh.com.
IN MX 10 bundy.sandh.com.
IN MX 5 nashville.com
AlphaOne Technology Support Forums
Author
Logged
