Mailbox migratie zonder downtime: wat is realistisch?

# Wat betekent 'downtime' bij e-mailmigratie precies?

Downtime bij e-mailmigratie is niet dat je webmail even offline is, maar dat inkomende berichten stuiteren of dat historische mail tijdelijk ontbreekt op de nieuwe server. Er zijn twee vormen: berichtenverlies, waarbij een inkomend bericht geen geldige mailserver aantreft en een 5xx-fout retourneert aan de verzender, en leesonderbreking, waarbij historische mail nog niet in de nieuwe omgeving staat terwijl je al wel op de nieuwe server bent ingelogd.

De meeste migratieproblemen bij mkb-bedrijven komen van het tweede type. Iemand zet de MX-records om voordat de historische mail is overgezet, logt in op de nieuwe server en ziet een lege mailbox. Technisch is er niets verloren gegaan, maar praktisch is het desastreus voor een medewerker die halverwege een offertethread zit.

Echt berichtenverlies is zeldzamer dan vroeger, omdat mailservers een bericht meerdere keren proberen te bezorgen gedurende de herbestelperiode zoals vastgelegd in RFC 5321: standaard vier tot vijf dagen. Die herbestelperiode is echter geen garantie als je TTL te laag staat en de DNS-propagatie te snel gaat zonder dat de doelserver klaar is.

# Hoe werkt dual-delivery MX-overlap?

Bij dual-delivery voeg je tijdelijk een tweede MX-record toe met hogere prioriteit (lagere numerieke waarde) voor de nieuwe mailserver, terwijl het oude record met lagere prioriteit actief blijft. Inkomende berichten landen dan op de nieuwe server, maar als die een adres afwijst, valt het systeem terug op de oude server. Dit is de veiligste methode voor de overgangsperiode.

De overlap-periode duurt in de praktijk 24 tot 48 uur. Tijdens die periode loopt nieuwe mail al naar de nieuwe server, terwijl je de historische mail via het IMAP-protocol overzet. Pas als de kopie klaar is en je hebt geverifieerd dat alles aanwezig is, verwijder je het oude MX-record.

Een kritiek voorbehoud: dual-delivery werkt alleen sluitend als beide servers de e-mailadressen accepteren. Als de nieuwe server een adres afwijst met een 5xx-fout omdat het account nog niet aangemaakt is, gaat dat bericht niet terug naar de oude server maar stuitert het definitief. Maak accounts op de nieuwe server daarom altijd aan vóórdat je het nieuwe MX-record toevoegt.

• Maak alle mailboxen op de nieuwe server aan voordat je MX-records aanpast
• Voeg het nieuwe MX-record toe met prioriteit 10; houd het oude op prioriteit 20
• Wacht 24-48 uur en kopieer historische mail via IMAP in deze periode
• Verwijder het oude MX-record pas als de IMAP-kopie volledig en geverifieerd is

# TTL verlagen: de kritieke voorbereiding 48 uur van tevoren

De TTL (Time To Live) van je MX-record bepaalt hoe lang DNS-servers wereldwijd de waarde cachen. Een standaard TTL van 3600 seconden (1 uur) of 86400 seconden (1 dag) betekent dat DNS-wijzigingen tot een dag lang niet overal zichtbaar zijn. Dat is ongewenst als je snel wilt schakelen zonder dat mailservers elders verouderde informatie gebruiken.

Verlaag de TTL van je MX-record minimaal 48 uur vóór de geplande migratie naar 300 seconden. Na die 48 uur heeft de verlaagde TTL zich volledig gepropageerd en duurt een MX-wijziging nog maar vijf tot vijftien minuten voordat ze wereldwijd zichtbaar is. Na afloop van de migratie zet je de TTL terug naar 3600 of hoger om DNS-verkeer te normaliseren en je nameserver niet onnodig te belasten.

Veel hostingpanelen zoals cPanel en Plesk tonen de huidige TTL per record in de DNS-zone-editor. Heb je geen toegang tot de zone, dan vraag je de huidige TTL op via de opdrachtprompt: nslookup -type=MX jouwdomein.nl. De weergegeven waarde achter 'TTL' is je startpunt.

# Vier migratiemethoden vergeleken op veiligheid en complexiteit

# IMAP-kopie als technisch fundament voor een naadloze overstap

Een IMAP-kopie is de kern van een migratie zonder downtime. In plaats van berichten te verplaatsen, streamt de migratiemachine ze via IMAP-APPEND van de bronserver naar de doelserver. De bronmailbox blijft onaangeroerd: je kunt er tijdens de migratie gewoon mee werken, mail ontvangen en verzenden.

Mailmigreren.nl gebruikt precies deze aanpak. Wachtwoorden worden alleen in werkgeheugen verwerkt en nooit op disk opgeslagen. Voor een mailbox van 5 GB duurt de kopie 30 tot 90 minuten; bij 10 GB of meer reken je op enkele uren. Zodra de kopie klaar is, staan alle mappen inclusief Verzonden items, Prullenbak en Archief op de nieuwe server.

Een praktisch voordeel van kopie boven verplaatsing: als er iets misgaat, staat de bron nog compleet. Er is geen destructieve actie verricht. Je kunt opnieuw beginnen of troubleshooten zonder dat berichten verdwenen zijn. Als de migratie niet succesvol afrondt, wordt het betaalde bedrag automatisch teruggestort via iDEAL.

# Welke providers werken zonder obstakels?

Bijna elke IMAP-provider ondersteunt een kopie-migratie, mits de provider standaard IMAP-toegang biedt en geen extra app-wachtwoord of two-factor-blokkade in de weg staat. Providers als Strato, Hostnet, TransIP, YourHosting, Vimexx, Antagonist, Argeweb, Webhostpartner, Byte en Hoasted werken rechtstreeks met IMAP-gebruikersnaam en wachtwoord zonder aanvullende configuratie.

Microsoft 365 vereist een extra stap: je maakt een app-wachtwoord aan of schakelt basic authentication in voor het betreffende account via het Microsoft 365-beheerportaal. De officiële Microsoft-instructies voor app-wachtwoorden leggen per accounttype uit hoe je dit inschakelt.

Gmail en Google Workspace vereisen een app-wachtwoord via myaccount.google.com. Gewone inlog via browser werkt niet voor IMAP-migraties; basic authenticatie met app-wachtwoord wel. Controleer dit vóór de migratie: meerdere mislukte inlogpogingen kunnen een account tijdelijk vergrendelen, wat de migratietijd verlengt.

# Realistische verwachtingen: wat 'zonder downtime' in de praktijk betekent

De term 'nul downtime' is in de migratiewereld een relatief begrip. Wat je realistisch bereikt is nul berichtenverlies en een leesonderbreking van nul minuten tijdens de IMAP-kopie, want de bron staat immers nog online. Na de MX-wissel is er een korte herconfiguratiestap: e-mailclients als Outlook en Thunderbird slaan de servernaam op en moeten handmatig bijgewerkt worden met de IMAP- en SMTP-gegevens van de nieuwe provider. Dat kost per medewerker vijf tot tien minuten.

Plan de MX-wissel buiten kantooruren of op een vrijdagmiddag. Communiceer van tevoren naar medewerkers dat ze op maandagochtend hun e-mailinstellingen opnieuw moeten invoeren. Met die voorbereiding is de totale hinder voor een team van tien personen minder dan twee uur gecombineerd.

Wat je niet kunt vermijden: als iemand een e-mailclient heeft die wachtwoorden cached en die cache niet leegt na de serverwissel, krijgt die persoon een inlogfout. Dit is een clientzijdig probleem, geen migratiefout. De oplossing is altijd: verwijder het oude account in de client en voeg het opnieuw toe met de nieuwe serverinstellingen.