Verlies ik mail tijdens de migratie?

Niet als je vooraf kopieert (imapsync), tijdens de switch parallel draait en daarna een dual-delivery-periode aanhoudt. Met die drie lagen verlies je niets, ook niet die ene mail die net binnenkomt tijdens de switch.

Hoe lang duurt een mailmigratie?

Voor een mkb-omgeving met 3 tot 10 mailboxen reken ik een halve dag. Voor grotere omgevingen of veel archief: een hele dag of meer. Het zit grotendeels in wachten op de sync, niet in actief werk.

Wat als de oude mailhost geen IMAP-toegang biedt?

Dan moet je per mailbox een lokale backup maken (in Outlook of Apple Mail) en die op de nieuwe server importeren. Lastiger, en je verliest metadata (read/unread, server-mappen). Liever IMAP, dus check vooraf of dat aan staat.

Moet ik SPF en DKIM opnieuw doen?

Ja. SPF moet de nieuwe mailserver toestaan (anders bouncet uitgaande mail). DKIM-keys verschillen per provider. DMARC kan blijven, mits SPF en DKIM correct nieuw zijn ingesteld.

Wat doe ik met aliassen?

Zelfde naam op de nieuwe server aanmaken, inclusief forwarders. Test ze daarna met een echte test-mail om zeker te zijn dat ze doorlopen.

Werkt dit ook voor Microsoft 365?

Voor migraties van of naar Microsoft 365 zijn er gespecialiseerde tools die ik niet zelf draai. Voor classic IMAP-omgevingen (hosting-mail, cPanel-mail, Plesk-mail) wel.

E-mail migratie website verhuizen: veilig in 6 stappen

E-mail migratie website verhuizen wordt bijna altijd als laatste bedacht, en juist daar gaat het mis. De hosting wordt verhuisd, de DNS wordt omgezet, de site werkt. Twee dagen later: “Krijg ik nu eigenlijk nog wel mail?” Of erger: “Ik mis mail van afgelopen donderdag.”

Het is geen nalatigheid, het is een typisch blinde vlek. Veel hostingpakketten leveren mail mee bij de site, en in de gedachte gaat alles als één pakket mee. In werkelijkheid zit mail in een eigen laag (MX-records, IMAP-mailboxen, SPF/DKIM/DMARC) die je apart moet plannen.

Dit artikel beschrijft hoe ik e-mail meeverhuis tijdens een website-migratie, zonder dat er ook maar één bericht verloren gaat. De stappen, de tools, en het tijdsvenster. Bedoeld voor mensen die meekijken bij hun eigen migratie of weten willen wat de aanpak is als ik het doe.

E-mail migratie website verhuizen met behoud van synchronisatie tussen telefoon en laptop

E-mail migratie website verhuizen: waar het misgaat

Drie patronen kom ik telkens tegen.

Patroon één: MX-records te vroeg omgezet. Iemand verandert de MX-records voordat de nieuwe mailserver klaar is. Resultaat: mail bouncet, of komt op de nieuwe server aan voordat de mailboxen er staan.

Patroon twee: oude mailbox niet meegekopieerd. Bezoeker maakt een nieuwe mailbox op de nieuwe server, MX-records gaan om, en de oude inhoud blijft achter op de oude hoster. Bij de eerste klik op een Outlook-mapje is hij weg.

Patroon drie: Outlook of Apple Mail blijft op de oude server hangen. De DNS is om, mail komt binnen op de nieuwe server, maar de mailclient blijft de oude IMAP-server raadplegen. Gebruiker denkt: “Ik krijg niks.” In werkelijkheid staat de nieuwe inbox vol.

Alle drie zijn vermijdbaar. Niet door één magische plugin, maar door planning.

Draaiboek

E-mailmigratie in 6 stappen

Klik door de stappen. Per stap zie je wat je doet en de valkuil om te vermijden.

Voortgang

0 van 6 klaar

Interactieve versie, zet JavaScript aan. Hieronder staat het statische draaiboek.

Inventarisatie. Wat je doet: breng alle mailboxen, aliassen, doorstuurregels en de huidige provider in kaart. Valkuil: vergeten aliassen en catch-all adressen die na de switch stilvallen.
Nieuwe mailomgeving klaarzetten. Wat je doet: maak de mailboxen op de nieuwe omgeving aan, met dezelfde adressen en voldoende opslag. Valkuil: mailbox pas aanmaken ná de MX-switch, waardoor inkomende mail bounct.
Bestaande mail kopiëren met imapsync. Wat je doet: kopieer alle bestaande mail van oud naar nieuw met imapsync, vóór de switch. Valkuil: alleen de inbox kopiëren en submappen of verzonden items vergeten.
MX-records timing en de switch. Wat je doet: verlaag de TTL van de MX-records een dag vooraf, wissel daarna de MX-records om. Valkuil: TTL niet verlaagd, waardoor de wereld nog uren naar de oude server blijft mailen.
Dual-delivery periode. Wat je doet: laat oude en nieuwe omgeving een korte periode allebei ontvangen, zodat niets tussen wal en schip valt. Valkuil: de oude mailbox te vroeg opzeggen tijdens propagatie.
Outlook en Apple Mail re-sync. Wat je doet: laat clients opnieuw synchroniseren met de nieuwe server en controleer SPF, DKIM en DMARC. Valkuil: oude accountinstellingen blijven staan, mail komt dan dubbel of helemaal niet binnen.

Stap 1: Inventarisatie

Voor ik iets aanraak, breng ik in kaart wat er staat.

Welke mailboxen draaien er, hoeveel zijn het, hoe groot is elk?
Welke aliassen en forwarders staan er ingesteld?
Waar staan de MX-records nu en wat is hun TTL?
Staat SPF, DKIM en DMARC ingesteld? Wat is hun huidige waarde?
Welke clients gebruiken de medewerkers (Outlook, Apple Mail, Thunderbird, mobiel)?

Een mailbox van 20 GB met 15 jaar archief migreert anders dan een leeg account voor info@. Een omgeving met DKIM-signing vraagt om een ander script dan eentje zonder.

Voor agencies en collega-webmasters: dit is precies waar ik vaak ingehuurd word. De website-kant gaat goed, de mail-kant is een blinde vlek.

Stap 2: Nieuwe mailomgeving klaarzetten

Op de nieuwe mailprovider zet ik alles klaar voordat er ook maar iets verandert in DNS.

Wat ik doe:

Mailboxen aanmaken met dezelfde naam als op de oude (info@, voornaam@, sales@)
Wachtwoorden noteren in een password manager (lokaal, versleuteld)
Aliassen en forwarders nazetten op de nieuwe server
SSL/TLS-certificaten voor de mailserver controleren (mail.voorbeeld.nl of de host die de provider gebruikt)
Een testbericht heen en weer sturen via webmail om te bewijzen dat alles werkt

Op dit moment ontvangen de nieuwe mailboxen nog niks. MX-records wijzen nog naar oud. De nieuwe server staat klaar.

Stap 3: Bestaande mail kopiëren met imapsync

Hier komt het belangrijkste stuk. Bestaande mail kopiëren van oude server naar nieuwe, terwijl beide mailboxen IMAP-toegang hebben.

Mijn standaardtool: imapsync. Een command-line tool die mailfolders van de ene IMAP-server naar de andere kopieert, met de juiste flags voor read/unread, datums, labels en mappen.

Een typische sync:

imapsync \
  --host1 mail.oudehoster.nl --user1 info@voorbeeld.nl --password1 'xxx' \
  --host2 mail.nieuwehoster.nl --user2 info@voorbeeld.nl --password2 'yyy' \
  --ssl1 --ssl2

Voor één mailbox van 5 GB duurt dat ongeveer 30 tot 90 minuten, afhankelijk van internet en server-snelheid. Voor een omgeving met tien mailboxen reken ik gerust een halve dag.

Belangrijke punten:

Doe de eerste sync ruim voor de MX-switch (een dag of twee). Alle bestaande mail staat dan al op de nieuwe server.
Doe een tweede sync direct na de MX-switch. Dat haalt de mail op die in de tussentijd nog op oud is binnengekomen.
Bij grote mailboxen overweeg een dry-run vooraf om problemen te vinden (rare karakters in mapnamen, te grote bijlagen).

MX, SPF, DKIM en DMARC DNS-records voor email-deliverability bij website-migratie

Stap 4: MX-records timing en de switch

De MX-record-switch is het moment dat nieuwe mail naar de nieuwe server gaat. Hier komt het draaiboek erop aan.

Vooraf: TTL van de MX-records verlagen naar 300 seconden. Doe dat 24 tot 48 uur eerder. Meer over de werking van TTL in DNS-overstap bij website-migratie.

Op het moment van de switch: MX-records aanpassen in het DNS-paneel. Tegelijk SPF aanpassen aan de nieuwe mailserver (anders bouncet je uitgaande mail straks), DKIM-keys overzetten of nieuwe genereren bij de nieuwe provider, en DMARC laten staan.

Direct na de switch: Een testbericht sturen vanaf een externe afzender (Gmail bijvoorbeeld) naar info@. Komt het binnen op de nieuwe server: ja. Komt het nog op oud binnen: even wachten en opnieuw proberen, of DNS-propagatie checken.

Korte tijd later: Tweede imapsync-run om de overgangsmail mee te nemen.

Wat ik uitdrukkelijk vermijd: alles op één moment doen. Mail-migratie wordt rustiger als je het in twee fasen splitst (kopiëren vooraf, switchen, na-kopiëren).

Stap 5: De dual-delivery periode

Een truc die nauwelijks bekend is, maar die ik in bijna elke migratie gebruik. Stel: je hebt MX-records omgezet en de nieuwe server vangt nu de mail. Wat als er een fout in zit en je een dag mail mist?

Oplossing: dual-delivery. Op de oude server zet je een forwarder van info@ door naar info@voorbeeld.nl, en die laat je nog een week of twee actief. Alles wat per ongeluk nog naar de oude server komt, wordt naar de nieuwe doorgestuurd.

Wat dual-delivery oplost:

DNS-caches die hardnekkig vasthouden aan oude MX-records
Externe afzenders die hun eigen DNS-cache lang vasthouden
Backupservers van afzenders die naar fallback-records gaan
Gewoon menselijke fouten in de configuratie

Na een week of twee is de wereld bij. Forwarder uit, oude mailbox kan dan ook echt weg.

Stap 6: Outlook en Apple Mail re-sync

Het laatste stuk, en vaak het gevaarlijkste. De medewerkers gebruiken Outlook of Apple Mail die nog tegen de oude IMAP-server praat.

Wat er kan gebeuren als je niets doet: de client raakt verward. Hij ziet dat het IMAP-protocol nog werkt (oude server is nog actief), maar nieuwe mail komt niet meer binnen omdat MX naar nieuw wijst. De gebruiker mist mail zonder foutmelding.

Mijn aanpak:

Per medewerker uitleggen dat het IMAP-account in de mailclient opnieuw moet worden ingesteld
Tip: nieuw IMAP-account toevoegen op nieuwe server, oude pas verwijderen als nieuwe goed werkt
Voor wie het lastig vindt: TeamViewer-sessie van 15 minuten per medewerker
Mobiele apparaten (iPhone Mail, Gmail-app op Android) hetzelfde

In Outlook is "IMAP account opnieuw toevoegen" de schoonste route. Apple Mail kan vaak met "Server Settings" wijzigen. Bij grote organisaties is het werk genoeg om een aparte instructie-pdf te leveren.

IMAP resync van mailbox tussen oude en nieuwe email-provider bij website-migratie zonder berichten-verlies

Stap 7: Wat ik nog uitschakel

Een paar kleine dingen die vaak vergeten worden.

Autoresponders. Vooral "vakantie-antwoorden" en "we zijn aan het verhuizen"-meldingen. Tijdens een migratie kunnen die dubbele berichten triggeren. Uit zetten voor de switch, daarna weer aan.

Externe forwarders die niet meer nodig zijn. Soms forwardt iemand jaren oud nog naar een Gmail-account. Schoonmaak doen.

Catch-all-routes. Als de oude server een catch-all heeft (mail@iets.nl, foutje@iets.nl, alles naar info@), die op de nieuwe server bewust wel of niet aanzetten. Bewust, niet automatisch.

Multi-stack en wat ik doe

Mail-migratie reken ik tegen 95 euro per uur, hetzelfde tarief als migratie en serverwerk. Een typische omgeving (een handvol mailboxen) is een halve dag werk inclusief monitoring.

De aanpak werkt los van waar je website draait. WordPress, Joomla, Drupal of Shopify: mail zit in een eigen laag. Andersom werkt het ook: ik kan je mail meeverhuizen zonder dat de website meegaat, als alleen de mailhoster wisselt.

Wat ik niet doe is een complete Microsoft 365- of Google Workspace-tenant-migratie. Daar zijn aparte specialisten voor met de juiste tooling. Voor regulier IMAP-naar-IMAP, of een classic mailhost-wissel, prima.

Verbeteren boven herbouwen geldt ook hier. Een mailomgeving die werkt, moet je niet vernieuwen omdat het kan. Migreer alleen als er een goede reden voor is.