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?

  • 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? – jirib Mar 15 '12 at 20:47

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 mail.example.com 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 example.com instead of mail.example.com 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 (example.com) or a subdomain. It's common to use something like pop.example.com, imap.example.com or mail.example.com.

  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 smtp.example.com.

  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 example.com and example.com 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 mail.example.com, pop.example.com, imap.example.com and smtp.example.com 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 www.example.com 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 www.example.com.
  • 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.
  • 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.


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.


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.


Check your DNS for any MX records and see how they're configured. If your MX is set to mail.yourdomain.com, take a look at the record for mail.yourdomain.com. 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 yourdomain.com and www.yourdomain.com

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

If your MX record says yourdomain.com or www.yourdomain.com, 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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