Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a corporate website on a server that also hosts all our email. I have no idea how diligent all the employees have been about backing up their email / leaving old messages on the server, etc. In fact, I'd like to avoid all that hassle and keep the old email running on the old server.

I just want to move the website to a new, more reliable server, leaving the emails running on the old server.

How can I do this? When I point the DNS to the IP address of the new virtual host, once it propagates, will it cut off the email to the old server? The server admin of the old server seems to think so.

What's the solution here, operating on the principle that we want the LEAST amount of change / reconfiguration / data loss for our staff?

share|improve this question
I don't get it. Website is a mail client? If your client would be connecting to old mail webgui, put there a big warning that the service will be cut off in XX days :) Then you can rsync old mails to new server, can't you? – Jiri Xichtkniha Mar 15 '12 at 20:47
up vote 8 down vote accepted

There are four functions you have to take care of with regards to email:

  1. People sending your users email.
  2. Your users collecting their email.
  3. Your users sending email.
  4. Your mail server passing those emails on to other people's servers.

Each one of these requires handling potentially a different DNS entry.

  1. Your MX record. It should currently hold a name such as which in turn should hold an A record containing the IP address where other people can send your users email. If your MX record is instead of you will probably want to change it prior to the migration.

  2. What your users put in their mail client as their POP or IMAP server. This can be a raw IP address or your main domain ( or a subdomain. It's common to use something like, or

  3. What your users put in their mail client as their SMTP server. As with the POP and IMAP settings, this is often a subdomain such as

  4. The two DNS records that matter for this are your SPF record(s) and your PTR record. You will not want to change your SPF record apart from maybe adding the new web server in if it sends mail. Some mail servers expect your forward and reverse DNS to match, hence if the mail server IP address has a PTR pointing to and now resolves to the new web server IP address, some mail servers will reject email your users send to them.

What I would do in your situation:

  1. Create,, and and give them all A records pointing at the mail server.
  2. Verify that every user in your organisation is using some combination of those and only those subdomains in their mail clients. (Don't forget smart phones.)
  3. Verify that your MX records are using one of those subdomains.
  4. Verify that the PTR for your mail server's IP address is one of those subdomains.
  5. Make sure all these DNS changes have time to clear out of other people's caches. This means waiting as long as the longest existing TTL.
  6. Change the DNS for your domain to point to the new web server.


  • You can change the www subdomain fairly easily and safely without affecting email. (Unless you have done something weird like putting in your user's mail clients.) You could even stop here and not bother with any of the steps above. Leave a web server running on the mail server that does nothing but issue a 301 redirect to
  • Doing all the changes above, while potentially slow and arduous now, will allow you to avoid much grief in the future because all of your independent services are now pointing to separate subdomains and all your users are using a consistent naming scheme to find those services. Future changes will be easy.
  • You can test DNS changes out yourself by editing your own hosts file. This will allow you to check that your users can send and receive email and that other people can send you email.
share|improve this answer
Awesome and comprehensive answer. Thanks for taking the time to put this much detail in. – Tom Auger Mar 16 '12 at 0:26

Scenario: Email will continue going where it's currently going. Web site will move to a new server.

Change the A record for the web site (if you're using an A record for www), or for the web site host server (if you're using a CNAME for www) to point to the ip address of the new server.

No change to, nor discussion of, the MX record is required.

share|improve this answer

The MX DNS entry of your domain should be pointing on your old server after you moved the website. You then shouldn't have an interruption in service.

share|improve this answer

You must set mx record for your email to the old server and set up A record to a new one server for your website. Thats all. MX maps a domain name to a list of message transfer agents for that domain and record A returns a 32-bit IPv4 address, most commonly used to map hostnames to an IP address of the host.

All modification are safe and should not impact on any downtime of any service. You must ofcource first set up website on new server test it than make changes to dns. Ad MX record and change A record.

share|improve this answer

Check your DNS for any MX records and see how they're configured. If your MX is set to, take a look at the record for If that is an A record (which should be set as the IP of your current server), you're good to go, just don't change that record when you move and

If is a CNAME that points to or, you'll need to create a new A record as above.

If your MX record says or, then you'll have to create a new A record as above and change the MX record to the new one.

If you need to make any of the changes described, you should wait a day or two (unless your TTLs are longer than that) to make sure that any other mailservers that have your current info cached get the new info before you change things.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.