No - I'm not an answering script ...
Group: Admin
Posts: 6631
Member No.: 195
Joined: 19-June 02
|
| QUOTE |
E-mail, Mail Exchangers, and DNS
A source of significant confusion for many of our users continues to involve e-mail and DNS. Many people are misinformed about the link between DNS and mail, so it's time to clarify a few things. (Note: in the dynamic and static DNS services, the mail exchanger feature creates MX records. Since this is a technical whitepaper, we'll mostly refer to them as MX records all the time)
Basic Mail Setup
Many people think that you need an MX record to receive mail. This is incorrect. In the absence of an MX, mail to a machine (for example, mail to @who-needs-an-mx.dyndns.org or @yourcustomdns.com) will be handled by that machine (in the case of my example, the machine at who-needs-an-mx.dyndns.org or at yourcustomdns.com). This is the behavior that most people running mail servers on their home machines want. For this reason, we do not recommend that users wanting a basic mail configuration set up an MX. It is not necessary, and it is possible to make mistakes in the MX record that will cause mail to end up somewhere else.
The Purpose of MX Records
Having just read what we've told you above, you may wonder then why someone invented MX records. MX records serve a clear purpose: they let you specify that you want mail to a machine to be handled by another machine. For example, dyndns.org points to our web server (66.37.218.217 is one of a few IP addresses on a machine called ruby.bos.dyndns.org). This is necessary so that people who enter http://dyndns.org/ in their browser (instead of http://www.dyndns.org) get our web site anyways. The problem is that with this setup, mail for our staff and support e-mail addresses would be handled by our web server. For a whole bunch of reasons totally outside the scope of this whitepaper, we do not want that.
This is where MX records come in. MX records allow you to specify that another machine handles the mail. So, for example, we want the machine mail.dyndns.org to handle the mail sent to @dyndns.org, so all we need to do is have an MX for dyndns.org pointing to mail.dyndns.org, then we tell the machine mail.dyndns.org that it handles mail for @dyndns.org, otherwise it'll reject it, and boom, all the SMTP servers out there will now connect to mail.dyndns.org to deliver mail to @dyndns.org. This keeps our web server happy.
Backup MXes and MX Preference
The purpose of MXes doesn't end there; it is also possible to have multiple MX records. In my simple example, I omitted to mention that MX records all have a preference assigned to them. So, the MX saying that mail to @dyndns.org goes to mail.dyndns.org has preference 20. There is a second MX with preference 50 saying that mail to @dyndns.org should go to mail2.dyndns.org. That introduces our next point about MXes: when there are multiple MX records, remote mail servers will first try to deliver mail to the server with the lowest preference. That means that if a mail server wants to send mail to @dyndns.org, it looks up the MXes. It sees the one with preference 20 is the lowest preference one, so it tries to connect to mail.dyndns.org. If mail.dyndns.org doesn't respond, then it will look for the next-lowest preference MX, namely the one with preference 50, and thus connect to mail2.dyndns.org. mail2.dyndns.org is a machine in our Ithaca, NY network, so even if the whole network or facility in Waltham, MA (the place where mail.dyndns.org is) was experiencing problems, it would probably still be up. mail2.dyndns.org is not configured to deliver mail for dyndns.org locally, but instead it queues the mail and regularly tries to send it to mail.dyndns.org. When mail.dyndns.org comes back up, then mail2.dyndns.org will send it all the mail that was received while it was down. In this case, mail2.dyndns.org would be a backup MX. The next section will explain how to set them up.
Creating MX Records
If you are using our dynamic or static DNS, the choices are fairly limited: you have a box in which to enter a DNS hostname as a mail exchanger and a backup MX checkbox. (note: the DNS RFC says that hostnames used in MX records cannot be CNAMEs; the NIC enforces this and will reject any CNAME; see the Dynamic DNS FAQ for more information.) If you type in a DNS name and don't check the backup MX option, then a single MX of priority 10 pointing to that DNS name will be created. If you check the backup MX option, then an MX of priority 5 pointing to yourhostname.dyndns.org will be created, along with a MX of 10 pointing to the DNS hostname you entered.
If you're using our Custom DNS service, then you have many more options available. You are able to create MX records within your domain with any priority, so you need to keep in mind the following rules about MXes:
MXes must be DNS hostnames defined by A records, not CNAMEs.
MXes cannot be IP addresses
If you create a single MX, the priority doesn't matter
If you create multiple MXes, your actual mail server must have the lowest preference
Make sure not to create MXes backwards! If you want mail for @yourdomain.com to go to mail.yourdomain.com, then you create the MX record for yourdomain.com and set it (that means the data field) to mail.yourdomain.com with whatever priority you like. If you reverse the two DNS names, then you're telling remote mail servers where to send mail to @mail.yourdomain.com; for most people, this is not very useful.
With those rules in mind, you should be able to set up MXes for your domain.
Limitations of MX Records
Above, we stated that MX records are used only to determine which machine the mail is sent to. That means that you cannot use MX records to forward mail for @yourdomain.com to you@yourisp.com, for example. Also, any machine you use as an MX must have its mail server software configured so that it knows about your hostname/domain. That means that it's usually a bad idea to specify your ISP's mail server as an MX, because it probably won't know about your hostname/domain and it is likely to bounce your e-mail.
Yes, these limitations are annoying. Some people ask "Why does the MX functionality you provide do so little?". The best answer we can give is the following: "We didn't invent MXes. Someone else did, and someone else gave them this capacity. All we're doing is allowing you to use them".
Mail Forwarding (or Mail Redirection)
Some of you may then wonder, how does one do it so that you@yourdomain.com gets redirected to you@yourisp.com, if MX records can't do it? The answer is quite simple: you need to have mail to yourdomain.com accepted by a mail server somewhere (presumably, you'd use an MX to indicate which mail server this is), and then this mail server will look up its tables and will resend the message out to the new address. (The details of how to do this involve the way the SMTP protocol works; it's quite simple, but we're a DNS provider, not an SMTP counselling service)
Again, a few limitations need to be pointed out here: firstly, as all mail must be received and then sent back out by the server doing the mail forwarding, this can potentially use a lot of bandwidth. That is the main reason why we do not currently provide a mail redirection service: it is very difficult to price something knowing that one person may receive 100K of mail per week, and then another person may receive 10 megs per day of mail. Obviously, the person with 10 megs would cost the mail forwarding provider a lot more in terms of bandwidth (and thus money), so he/she should pay more. Another limitation is that you need to follow all of the rules of MXes from above: whichever machine handles the forwarding needs to know that it handles that domain/hostname, and where to send the mail back out to.
|
--------------------
|
E-mail, Mail Exchangers, and DNS, About MX records
Help
Search
Members
Calendar
