CloudMail MX Records

This article is for those clients who want to use CloudMail but also manage their own DNS. This article contains generic instrucing for managing your own MX records to use CloudMail and the CloudAccess.net network. Please remember that this is general advice. If you manage your own DNS, each DNS provider has its own control panels.

Don't want to worry about DNS and MX records?

What are MX Records?

Configuring MX Records

CloudAccess.net Mail Servers MX Settings

Avoiding Bounced Messages after Changing MX Records

Don't want to worry about DNS and MX records?

This is really technical stuff and we don't blame you if you get confused or if you want someone else to manage it for you. We suggest that you let us manage your DNS. Our managed DNS service is already setup to work with CloudMail. All you have to do is setup your domain to use our name servers. When you run a “whois” on your domain, you should see name server settings. CloudAccess.net nameservers are listed below.

ns1.gridfast.net
ns2.gridfast.net

If you are using your own DNS servers and you want to use CloudMail, you will have to manually adjust your MX records to have your email flow to our servers. If you get confused about changing the records yourself, we suggest you use the CloudAccess.net DNS system as a managed service - we'll do all the work for you. Simply submit a support ticket to our team with your URL and the username and password needed to access your DNS control panel. Our team will take care of the rest.

Back to Top

What are MX Records?

MX records (mailer exchanger records) are DNS settings associated with your domain name that direct email to a mail server that accepts email on behalf of your domain name. MX records are managed by the company where you registered your domain name. You can create records for multiple servers to ensure mail always gets delivered. That way, if one server is down, mail can be routed to another server instead. You determine which servers are used first by assigning priorities using values like 10, 20, 30 and so on. The lowest value gets the highest priority. For instance, if the domain example.com has two MX records—10 mail1.example.com and 20 mail2.example.com—mail is delivered to 10 mail1.example.com first because it has the lowest priority value. If that server is down, mail is redirected to 20 mail2.example.com and so on. If different MX records have the same priority, one server is chosen arbitrarily.

Back to Top

Configuring MX Records

Now that you understand MX records, you should configure them to receive emails at your domain. When you’re switching to CloudMail, you’ll need to point your MX records to the CloudAccess.net mail servers. Modify MX records using the administration tools of your domain registrar, not the CloudMail administrator control panel. The basic steps below are applicable to all domain registrars. The exact steps for doing so are slightly different for each host. 

First, sign into the domain registrar's administrative control panel for your domain. Locate the area where you can update the domain MX records. The page is typically called something like DNS Management, Name Server Management or Advanced Settings.

Locate the MX records for your domain. You may have one or more MX records resembling the following:

Name/Host/Alias		Time to Live (TTL)		Record Type		Priority		Value / Answer / Destination
Blank or @		86400		MX		10		mail1.example_site.com
Blank or @		86400		MX		20		mail2.example_site.com

*note: these are example settings. Scroll down to get to our exact mx record settings.

As an option you can reduce the Time to Live (TTL) to 300 seconds for every existing MX record. This tells name servers across the Internet to check every 300 seconds (or five minutes) whether you updated these DNS records. This allows you to apply changes to your DNS records much more quickly. Also, if necessary, you can revert any DNS record changes a lot quicker when you’ve set a low TTL.

Any DNS record change will be applied only after the initial TTL of that record expires. For example, a value of 86400 seconds = 1440 minutes = 24 hours before any update will be applied. This also means that you need to wait 24 hours after the TTL of a DNS record is updated once you change it to 300 from 86400.

Update the existing MX records to include the value / answer / destination of the desired MX record values. Also create new MX records (if necessary) to include all servers listed on that page.

To do this you must:

• Enter the entire server name - something like mx1.cloudaccess.net. Many domain hosts also require a trailing period at the end of the server name.
• Set the priority for the MX record by preceding the server name with the priority number specified on the MX record values page. Some domain hosts may require you to set the priority in a separate field. Note: MX records with a lower number have higher priority than MX records with a higher number. Different domain hosts use different priority numbering systems. Regardless of the system, the important fact is the relative priorities of MX records.
• Delete MX records not pointing to our servers or give them a lower priority (priority value higher than 10) than those pointing to CloudAccess.net.
• Save your changes and wait until they take effect.
• Be aware it may take up to 72 hours before changes are propagated, depending on the TTL that was configured for your MX records. Until records have been updated worldwide, you will still receive email through your old mail server. If you have difficulty, first try to troubleshoot MX records. Then contact your domain host for assistance.

Back to Top

CloudAccess.net Mail Server MX Settings

Please use the values below when you configure MX records for CloudMail with your domain registrar. Please note the initial numbers in the Value / Answer / Destination column show MX record priority.

Name/Host/Alias		Time to Live (TTL)		Record Type		Priority		Value / Answer / Destination
Blank or @		300		MX		1		mx1.cloudaccess.net
Blank or @		300		MX		5		mx2.cloudaccess.net

The initial numbers in the Value / Answer / Destination column show the relative priorities for the CloudAccess.net servers. The values do not need to be exactly those shown in the table; different domain hosts have different systems for setting MX record priority. Regardless of the system, mx1.cloudcccess.net must be the top priority record

The priority level assigned to an MX record establishes preferences when there are multiple MX records for one domain. A correct priority value assigns a preference to the primary MX record. In this fashion, backup MX records are given a lower priority.

mx1.cloudaccess.net.com. is the most important mail server, and should be assigned a unique priority.

If your DNS provider allows you to assign numbers to MX records, choose the lowest number for mx1.cloudaccess.net., and assign higher numbers to the backup servers. In terms of priority values, the lowest number gets the highest priority. You can also feel free to delete the old MX settings, and only have CloudAccess.net MX settings. Keep in mind it will take time for DNS MX records to update.

If your DNS provider doesn't use numbers to assign priorities, choose the highest priority setting, or designate mx1.cloudAccess.net. as the primary server.

Also, if your DNS provider allows only one server, or doesn't allow ranking, simply enter mx1.cloudaccess.net as the only record.

Back to Top

Avoiding Bounced Messages after Changing MX Records

Any time you change your MX records, it can take up to 72 hours for your new records to propagate. The duration varies depending on your hosting company and may be less than 72 hours; however, during this time, mail sent to your domain may bounce. While there's no way to avoid downtime entirely, there are several steps that you can take to avoid bounces during the transition to CloudMail email.

Reduce MX record TTL in advance of changing MX records.

• Mail exchanger (MX) records contain a “Time to Live” (TTL) value that indicates how long Domain Name Service (DNS) servers should use the record before checking for updates. This is measured in seconds.
• A TTL of 3600 seconds means records will take an hour to update. A TTL of 86400 means records will take a day to update. A higher TTL value means less traffic load for the DNS server, but it also means changing the MX records will take longer.
• By reducing the TTL value in advance, you ensure servers aren’t using invalid records for too long when it comes time to switch the MX records to CloudAccess.net. If you're still not sure how to reduce your MX record TTL, contact your domain host in advance to prepare for the switch.

Create all user accounts in CloudMail.

• Soon after you setup your domain with our company, submit a ticket asking for your mail to be setup with your domain.
• Before you move hosting companies or mail, you can pre-setup all your users in our mail system so they are a replication of your old mail server.
• To ensure that all mail to your domain is received after you change your MX records, make sure that you've created accounts in your CloudMail control panel for all existing users on your domain.
• If you have many existing email accounts, you can upload all the email addresses at once.
• If you have any mailing lists or nicknames at your domain that may be affected when you change your MX records, you can recreate these in your control panel.
• You may also wish to set up a catch-all address to handle messages sent to addresses that haven't been created at your domain.

Make the transition during an evening or weekend.

• To reduce the number of possible bounced messages when you change your domain's MX records, we recommend scheduling the change for an evening or weekend or other time when your email volume is low.
• If your domain host has to input your new records for you, or if you're unsure of how to change your records, we suggest contacting your domain registrar in advance to prepare for the switch.

Notify key contacts of the change.

• To avoid confusion over any bounced messages, you may want to let some or all of your contacts know about the upcoming change to your email system.
• Make sure to include the date and time of the planned change, instructions to resend any bounced messages, and any alternative contact channels people can use for time-sensitive issues.
• You can emphasize that any downtime should be brief, and that no messages will be lost during the transition; some may simply need to be resent.

Back to Top