Field report: migrating a customer domain in one morning

Starting point

The mailboxes were spread across two systems: an in-house Exchange server in the office (reachable via VPN) and three mailboxes at the web hoster, which also manages the domain and DNS. The MX pointed to the hoster’s spam filter.

Data migration the day before and overnight

• Temporarily enabled IMAP4 on the Exchange server and created a dedicated migration account with full access.
• Copied all folders with imapsync: 8 mailboxes, about 95 GB, 0 errors, about 8 hours. The limiting factor was the upload bandwidth of the office connection.
• Calendars, contacts, tasks and notes deliberately left out; they are not transferred via IMAP.
• Hoster mailboxes: sync across all folders with duplicate detection by Message-ID (without an ID, by date, sender and subject). New mail from the last 7 days lands in the same folder, older missing mail in “Archiv <Anbieter>” (archive); these were mostly deliberately deleted newsletters.
• Everything can be run repeatedly. A follow-up run shortly before and after the switch-over fetches the rest.

Domain provider, step 1: preparation

The customer does not notice these changes yet:

• New: mx A 203.0.113.10
• New: woa._domainkey TXT (DKIM)
• New: _dmarc TXT with p=none
• MX TTL lowered from 3600 to 600 seconds, the minimum in the panel. The TTL automatically applies to all records with the same name and type.

Then issued the Let’s Encrypt certificate for mx.example.de and tested all mail ports (25, 465, 587, 993) from outside.

Tip: Port 25 cannot be tested from every server: many data centres block outbound port 25.

Server provider: setting reverse DNS

Menu Panel des Server-Anbieters öffentliche IP Reverse DNS

Set the reverse DNS of the server IP to mx.example.de. The provider checks whether the A record mx points to this IP. That is why step 1 at the domain provider comes first, then the PTR.

• Previously it held a generic name (“ubuntu”). Large recipients reject mail with that.
• The notice “Dem Server muss mindestens eine IPv4-Adresse zugewiesen werden” (at least one IPv4 address must be assigned to the server) in the same dialogue only concerns IP assignment and can be ignored.
• Outbound port 25 had to be unblocked at the server provider.

Switch the server to direct mode before changing the MX

Caution: If the server is still in collection mode (Abholbetrieb), it does not treat the domain as its own and permanently rejects incoming mail („Relay access denied“). So enable direct mode (Direktbetrieb) first, check that mail is accepted, then switch the MX.

Domain provider, step 2: the switch-over

Merely deleting the CNAME records for autoconfig and autodiscover was not enough: they fell back to the wildcard record *, which again pointed to the hoster. They were therefore recreated as A records.

Left unchanged: the main domain and www (placeholder page at the hoster), remote (office) and the verification TXT record. After about a week, include:<hoster> is removed from the SPF record, along with the hoster’s old DKIM record.

Within a few minutes the change was visible on the authoritative name servers and public resolvers. The first external mail arrived directly about 10 minutes after the switch-over.

Updating the certificate and autodiscover

• mail.example.de now also points to the server, so extend the certificate to include mail and autodiscover. Otherwise there will be certificate warnings.
• For Outlook there is a dedicated HTTPS endpoint autodiscover.example.de/autodiscover/autodiscover.xml that reports IMAP 993 and SMTP 465. Outlook queries it via POST; upper and lower case in the path do not matter.
• Thunderbird and mobile phones use autoconfig.example.de/mail/config-v1.1.xml.

Pitfall: the hoster delivers internally

A test mail from an account at the same hoster did not come via the new MX but ended up in the old mailbox at the hoster. As long as the domain is active there as a mail domain, the hoster delivers internally without looking at the MX.

Solution: in the hoster’s panel, under email for the web hosting package, select the domain and set the “Maildienste” (mail services) switch to inactive. The next test mail arrived via the MX immediately.

Caution: This also makes the hoster block IMAP access. So run the final sync beforehand.

In the process, further almost empty mailboxes at the hoster came to light, as well as an administrator@ address forwarding to another mailbox. A corresponding forward had to be created on the new server.

Tip: Before the switch-over, always list all mailboxes, forwards and aliases at the old provider.

Pitfall: greylisting

The first reply from webmail to an address at the hoster sat in the queue for about 16 minutes („451 … not yet authorized … try later“) and was then delivered. After that, mail went through immediately. The DKIM signature for the domain was correct.

Pitfall: Outlook suggests the data centre’s server

Outlook asked for the password for the data centre’s IMAP server instead of mx.example.de. This comes from Microsoft AutoDetect, not from your own autodiscover. The solution is described under Outlook suggests the wrong server.

Decommissioning Exchange

1. Export calendars and contacts first.
2. Stop all Exchange services via PowerShell and set them to “Disabled”. Save the previous startup types to a CSV file beforehand; a second script restores them if needed.
3. Remove the migration account and disable IMAP4 on the Exchange server again.

Time required

On the day of the switch-over, about 2.5 hours including all checks; the actual DNS change took a few minutes. Because everything ran before the working day began, the staff noticed nothing.