E-mail, Mail Exchangers, and DNS

MX records control how e-mail is delivered. They are used to locate the receiving mail servers for a given host, and the order of priority of these mail servers. Here is an example of an MX record:

Host		TTL	Type	Data
example.com	43200	MX	10 mail.example.com

• The Host field indicates the email addresses that the MX record handles (in this case, @example.com).
• The TTL (Time To Live) field indicates the length of time in seconds that this record should be cached.
• The Type field indicates the type of record (such as A, CNAME, MX, PTR, etc.).
• The Data field consists of the MX record's Preference and the destination mail server.

The above MX record literally tells sending mail servers, "Please deliver email for @example.com addresses to the mail server at mail.example.com."

Technically, a domain does not require MX records to receive email. By default, a sending mail server should attempt to deliver mail to the host itself if no MX record is present. For example, if a sending server is trying to deliver mail to user@domain.com, and domain.com has no MX records, it will try connecting to any mail server at domain.com itself.

However, it is highly recommended to create MX records for your domain, even if they seem redundant or unnecessary; in the above example, domain.com should still have at least one MX record set to domain.com itself to help ensure delivery, like so:

domain.com	43200	MX	10 domain.com

Some non-RFC-compliant servers will fail to deliver email for domains that lack MX records, including certain versions of Microsoft Exchange, and there is certainly no harm in creating redundant MX records for your domain. (Naturally, if you do not have a mail server for your domain at all, MX records are unnecessary.)

An MX record's Preference value determines its order of priority, with 0 being highest/first priority and 50 being lowest/last priority. If the highest priority mail server is unavailable for any reason (time out, power outage, etc.), sending mail servers try to connect to the next-highest mail server; if this mail server is also unavailable, it goes to the next-highest, and so on down the list.

Here is an example of a domain with two MX records:

example.com	43200	MX	10 mail.example.com
example.com	43200	MX	20 backup.example.com

mail.example.com has a Preference of 10 and backup.example.com has a Preference of 20, so sending mail servers would try to connect to mail.example.com first, and backup.example.com second. You can have as many MX records as you want, and define the order of importance using their Preference values. If you have only one MX record, the Preference value does not matter.

There are two interfaces for Custom DNS: Standard and Expert.

In the Standard interface, creating an MX record consists of three fields:

• Host: This field defines the email addresses you will be directing. If you are creating an MX record for the second-level host (such as domain.com), you should leave this field blank.
• Preference: This field defines the order of priority for the MX record, starting at 5 as the highest and ending at 50 as the lowest.
• Mail Exchanger: This field defines the destination host record for your mail server. The destination mail server record must be a host (A) record, not a CNAME or IP address.

If you are trying to create MX records for a third-party mail hosting provider and you are receiving errors about the destination mail server "resolving to a CNAME," they may have provided a CNAME record instead of a host record. Please see the Common Mistakes section for more information.

In the Expert interface, you will be presented with the Host, TTL, Type and Data fields, as discussed at the beginning of this article. The Data field consists of the Preference value, a single space, and the destination host.

Dynamic DNS hosts allow you to set mail delivery options under the Mail Routing section. By default, Dynamic DNS hosts have no MX records. If you select Yes, let me configure Email routing, you will be given the following options:

• MX Hostname: This is the host record of the destination mail server. Remember, you cannot use CNAMEs or IP addresses in this field.
• Primary: Yes, use it as my primary mail relay: A single MX record will be created for your Dynamic DNS host, assigned to the MX Hostname.
• Primary: No, use it as backup MX record: A primary MX record will be created for your Dynamic DNS host, assigned to the Dynamic DNS host itself, and a secondary MX record will be created and assigned to your MX Hostname.

For example, if you have a Dynamic DNS host called myhost.dyndns.org and a MX Hostname called mx.mailserver.com, selecting Yes, use it as my primary relay will create the following records:

myhost.dyndns.org	60	MX	10 mx.mailserver.com

If you choose No, use it as backup MX record, the MX records would be:

myhost.dyndns.org	60	MX	5 myhost.dyndns.org
myhost.dyndns.org	60	MX	10 mx.mailserver.com

The TTL value of these MX records is identical to the TTL of the Dynamic DNS host itself.

There are a few common mistakes that you should be aware of.

When creating an MX record for a second-level domain, such as 'example.com', make sure that you leave the Host field blank. If you want email for @example.com addresses to be delivered to mail.example.com, the following MX records would be:

Correct:

example.com		43200	MX	10 mail.example.com

Incorrect:

mail.example.com	43200	MX	10 mail.example.com

Incorrect:

mail.example.com	43200	MX	10 example.com

By default, MX records created for Custom DNS hosts have a Time To Live (TTL) value of 12 hours. If you change the MX records for your domain, sending mail servers may continue to try to deliver email using the old information for up to 12 hours, until the records clear and the new information is retrieved. If you have just changed your MX records and you are receiving bounced messages or other errors, you may need to wait for the changes to propagate completely before mail is delivered correctly.

If the MX records for your Dynamic DNS host keep disappearing, your update client is the likely culprit. If an update client sends no MX records in the update string, the MX records for the host are removed. Please ensure your update client is sending the proper MX records to prevent this problem.