My setup is a productive server (e.g. hosting a domain, lets say example.com. Currently, postfix and courier (only IMAP) are doing the job of hosting mail. I am planning to transfer the domain to a new server (e.g., also using postfix but with dovecot as a new IMAP server. I already setup postfix on to accept all mails for example.com, which are delivered to the mailboxes and are accessable via IMAP. All accounts, including mail, are shell accounts. I use Debian for both servers.

In the webinterface of my virtual host provider I am able to set the IP of the server (A-record) and the mailserver (MX-record) for example.com. Currently, they are pointing to respectively server.example.com (the latter automatically resolves to, too). I cannot influence any TTL-settings. And, I am not going to change my provider, just changing the virtual machine the domain is hosted on.

Two questions:

  1. I would like to have my old server deliver all received mails to the new server for testing purposes (e.g. to test mailfilters, SPAM recognition, etc. as not everything will be setup identically). Is this a good idea (e.g. regarding bounces, etc.)? What's the correct way in postfix for achieving this (something like reverse-proxy in Apache HTTP Server)?

  2. What's the best way to perform the domain transfer from the old server to the new server such that downtime is minimal (at least during IMAP account transfer I am sure I need to stop all mail servers) and no mails are getting lost/are deferred? I had the idea of letting the old server forward mails to the new server for a certain time such that mails can be received from systems with outdated DNS cache, too.

Generally speaking, I am searching for a convenient and best-practice way to perform this. And, I do not know, if my ideas regarding both questions are pointing in the correct direction.

3 Answers 3


I did this by letting the old server forward all mail to the new server Using postfix on the old server, you can do the following to send a copy of each incoming mail to the other server:

  1. Add a blind recipient in each mail for some bogus domain. E.g., for user@example.com a BCC recipient user@example.migration is added to each mail
  2. Configure this bogus domain to be delivered to your new server. Thus, mail for example.migration is delivered to
  3. Convert this bogus domain back to normal during delivery to the new server. Thus, upon SMTP delivery replace example.migration by example.com.

To achieve this, create the following files:

  • /etc/postfix/migration/recipient_bcc_map:

    /^(.*)@example\.com$/ $1@example.migration
  • /etc/postfix/migration/transport_map:

    example.migration smtp:[]
  • /etc/postfix/migration/smtp_generic_maps:

    /^(.*)@example\.migration$/ $1@example.com

Now include all this into your main.cf:

recipient_bcc_maps = pcre:/etc/postfix/migration/recipient_bcc_map
transport_maps = hash:/etc/postfix/migration/transport_map
smtp_generic_maps = pcre:/etc/postfix/migration/smtp_generic_maps

Postfix from version 2.3 on avoids bounces in this configuration. Thus, if errors occur on, they are not returned (see http://www.postfix.org/postconf.5.html#recipient_bcc_maps).

Now all mail is delivered as a copy to With this setting you can test all your migration stuff like filters on the new server. Be sure to have /etc/aliases in sync.

To perform the migration itself:

  1. Do the above setup.
  2. Stop postfix and IMAP service on both servers.
  3. Copy mailboxes from old to new server.
  4. Start postfix on both servers, IMAP on the new server.
  5. Change domain to point to new server.
  6. Users can access their mailboxes after domain switch has spread in DNS.

For incoming mail the downtime is minimal as they are only deferred between step 2 and 3.


To answer number 2:

Set the TTL on the current MX record to an appropriate setting (1 hour might be good). Then change the MX record to point to the new server. Then wait an hour (or whatever amount of time you set the TTL to) for any email that might be delivered to the old server (based on some systems having the old MX record cached), and then transfer the email from the old server to the new server.

Once you change the MX record to point to the new server, any email servers that don't already have the MX record cached (the old MX record) will resolve the new MX record immediately and send email there. Any email servers that do have the MX record cached (the old MX record) will continue to send email to the old server until the TTL of the MX record expires, at which time, they'll perform a new lookup for the MX record and find the new MX record and deliver email there.

  • Thank you for your reply. As I pointed out, I am not able to change TTL-settings. Thus, I will have to wait the already configured time before switching. Another question: what do you mean with "transfer the email from the old server to the new server"? Using IMAP? Manually? Jun 5, 2012 at 20:48

There is no way to test compleately except with software like Roundhouse that mirrors delivery to your second server. This level of testing probably isn't neccessary; manual inbound testing using telnet should be fine.

After you're sure delivery (inbound and outbound) is working as intended you can cutover like this:

  1. Set postfix on to deliver all user mail to the new server Example config: When your system is SECONDARY MX host...
  2. Add a new mx record for and remove existing record. When the queue is empty on, shutdown postfix forcing senders to deliver to new mx.
  3. Move client access cname from to (clients need to know their existing mail may not appear for a bit).
  4. Transfer mailbox contents from to
  5. When outbound mailqueue is empty, shutdown

Mail will be queued at senders for a bit if they are caching as joeqwerty says; in my experience, most software will try other mx records. Note that the mx records should point to actual host names, not a cname such as mail.example.com. The hard piece is managing client access; early communication to customers will help.

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.