E-mail naar een nieuwe host verhuizen zonder onnodige uitval

E-mail naar een nieuwe host verhuizen met minimale onderbreking

Wanneer je e-mail naar de infrastructuur van een nieuwe host moet verhuizen, hoeft dat geen storing van 24 uur te betekenen waarbij berichten terugkaatsen of verdwijnen. Het gevreesde zwarte gat ontstaat wanneer beheerders geen rekening houden met de doorlooptijd van DNS-wijzigingen en alles in één keer proberen te doen. Met een parallelle overgang houd je het oude systeem actief terwijl het nieuwe op de achtergrond synchroniseert. Pas wanneer beide omgevingen op elkaar aansluiten, zet je de routering om.

Deze handleiding beschrijft een praktisch overgangsplan waarmee beheerders de kans op onderbrekingen bij een verhuizing beperken. Lees voor de volledige migratieaanpak ook onze uitleg over IMAP-migratie.

Waarom de big-bangmethode mislukt

Bij de big-bangaanpak wordt alles op vrijdagavond gekopieerd, DNS omgezet en vervolgens gehoopt dat het goed gaat. Dat mislukt omdat overdrachtssnelheden niet constant zijn. Beperking door de provider, zoals HTTP 429-fouten, en bandbreedtelimieten kunnen een migratie halverwege stilleggen. Op maandagochtend blijken dan mailboxen maar gedeeltelijk gevuld en wordt de helpdesk overspoeld.

De professionele aanpak voor een verhuizing naar een nieuwe mailhost is een parallelle periode. Je richt de nieuwe omgeving in, synchroniseert historische gegevens op de achtergrond en past DNS pas aan nadat je hebt gecontroleerd dat de bestemming de bron volledig weerspiegelt. Lees voordat je begint ook onze uitgebreidere uitleg over het behouden van je reputatie als e-mailafzender tijdens de overstap.

De 4 fasen van een e-mailmigratie

Fase 1: DNS-propagatie en de regel van 300 seconden

Gesplitste routering, waarbij sommige afzenders de oude server bereiken en andere de nieuwe, ontstaat door lange TTL-waarden van DNS-records. Recursieve resolvers bewaren MX-records volgens de TTL, al kunnen afzonderlijke caches zich anders gedragen. Een gebruikelijke TTL is 86,400 seconden (24 uur). Als je MX-records omzet zonder die waarde vooraf te verlagen, kan mail nog lange tijd bij de oude server aankomen. Daarom moet iedereen die van mailhost wisselt eerst de TTL voorbereiden.

De werkwijze is eenvoudig: controleer de huidige TTL, verlaag de TTL van MX en SPF naar 300 seconden en wacht daarna minimaal de duur van de oorspronkelijke TTL voordat je verdergaat. Wie die wachttijd overslaat, houdt rekening met oude records in caches. Die waarde is een bovengrens voor caches die de TTL correct naleven, geen wereldwijde garantie dat iedere resolver binnen 5 minuten is bijgewerkt.

De SPF-valkuil van 10 lookups

Tijdens de migratie wil je mogelijk de SPF-include van de nieuwe provider naast die van de oude zetten. Wees voorzichtig. RFC 7208 beperkt SPF tot 10 DNS-lookups. Meerdere providers stapelen, bijvoorbeeld Google, Outlook en de nieuwe host, overschrijdt die grens vaak en kan PermError en bezorgproblemen veroorzaken. Maak je SPF-record alleen statisch als je het bij wijzigingen in ondersteunde IP-reeksen betrouwbaar blijft bijwerken. Anders kun je tijdens de overgang niet-kritieke marketingdiensten tijdelijk verwijderen. Lees voor een juiste inrichting onze handleiding voor SPF.

Fase 2: IMAP-gegevens synchroniseren

Bij een verhuizing naar een nieuwe mailhost verloopt de migratie via het IMAP-protocol (RFC 3501). Het is geen gewone bestandskopie, maar een synchronisatie van toestanden. Hulpmiddelen zoals imapsync nemen veel werk over, maar kennis van het protocol blijft belangrijk.

Het probleem met Gmails schaduwmailbox

Wie 'Alle e-mail' uit Gmail migreert, moet bedacht zijn op extra kopieën wanneer een migratietool labels als afzonderlijke mappen behandelt. Gmail toont labels via IMAP als mappen. Daardoor kan één bericht met 3 labels in 3 afzonderlijke IMAP-mappen terechtkomen, zonder dat het in Gmail zelf om 3 fysieke duplicaten gaat. De documentatie van Google over gegevensmigratie beschrijft dit model. Laat de migratietool labels daarom bewust toewijzen of sluit de map [Gmail]/All Mail uit als dat bij je gekozen migratiestrategie past.

Beperking en foutcodes

Bij de verhuizing kan de bronserver verbindingen afremmen. Google kan de verbindingsfouten 11001/11002 teruggeven wanneer IMAP-toegang is uitgeschakeld of door een firewall wordt geblokkeerd. HTTP 429-fouten wijzen op snelheidsbeperking. Sommige providers hanteren bijvoorbeeld een grens rond 2 GB/hour/user, maar de werkelijke limiet verschilt per dienst en account. Gebruik een migratietool met exponentiële wachttijden die beperking herkent en automatisch pauzeert.

Fase 3: gevolgen voor mailclients

Nadat je e-mail naar de nieuwe host hebt verplaatst, is de serverkant doorgaans het voorspelbare deel. Onze handleiding over het overzetten van een mailbox behandelt de DNS-omschakeling uitvoerig. Aan de clientkant kunnen de meeste supportvragen ontstaan.

Certificaat komt niet overeen: Als Outlook tijdens de DNS-omschakeling openblijft, kan het verbinding maken met mail.yourdomain.com, dat nu naar de nieuwe host wijst, maar daarbij oude aanmeldgegevens gebruiken. Daarna kunnen SSL/TLS-waarschuwingen verschijnen. Adviseer gebruikers de mailclient op maandagochtend opnieuw te starten en controleer de serverinstellingen als de waarschuwing blijft terugkomen.

OAuth op mobiele apparaten: Moderne mobiele clients gebruiken OAuth-tokens die aan een specifieke tenant zijn gekoppeld. Soms kan het account opnieuw worden geautoriseerd of met de nieuwe servergegevens worden ingesteld. Als client en provider dat niet ondersteunen, moeten gebruikers het oude account verwijderen en een nieuwe IMAP-verbinding toevoegen.

Interne routeringslussen: Na de MX-omschakeling kan de oude server het domein nog steeds als lokaal beschouwen. Als gebruiker A op de oude omgeving gebruiker B mailt, kan de server het bericht lokaal afleveren terwijl gebruiker B inmiddels alleen de nieuwe mailbox leest. Stel op de oude host daarom eerst een veilige doorsturing van late berichten naar de nieuwe host in en test die. Schakel lokale aflevering pas uit wanneer de doorsturing werkt en de DNS-caches voldoende zijn uitgedoofd.

Terugdraaien: een vangnetplan voor de eerste 15 minuten

Doordat je in fase 1 de TTL naar 300 seconden hebt verlaagd, kan terugdraaien meestal sneller verlopen, maar 5 minuten is niet gegarandeerd. Als de verhuizing mislukt, bijvoorbeeld door een firewallblokkade, licentieproblemen of 30+ minuten zonder mailverkeer, zet je de MX-records terug naar de oude provider. Verkeer keert terug zodra de relevante resolvers hun cache vernieuwen. Houd beide omgevingen intussen actief en controleer de bezorging.

Hoe TrekMail de verhuizing vereenvoudigt

Bij een handmatige verhuizing moet je imapsync-scripts beheren, cryptische fouten zoals 0x800CCC0E uitzoeken en DNS-wijzigingen volgen. TrekMail bevat een ingebouwde IMAP-migratie-engine die voor ondersteunde IMAP-gegevens maptoewijzing, wachttijden bij beperking en deltasynchronisaties automatiseert. Controleer na afloop altijd aantallen, mappen en steekproeven van berichten tegen de bron.

Alle betaalde abonnementen bevatten een proefperiode van 14 dagen (kaart vereist). Voor het Nano-abonnement is helemaal geen kaart nodig.

TrekMail richt zich op snelle opslag en bezorging van e-mail, met daarnaast agenda's en contacten per mailbox via CalDAV en CardDAV. Wil je ook e-mail met je eigen domein maken, dan behandelt onze installatiehandleiding iedere stap. De migratie zelf verplaatst alleen e-mail. Exporteer agenda's en contacten bij de oude provider en importeer ze zodra de mailboxen actief zijn.

Voor bureaus die geregeld tientallen domeinen tegelijk naar een nieuwe mailhost verhuizen, biedt TrekMail gedeelde opslag (verdeel 200 GB over al je domeinen), beheerde SMTP met vooraf opgebouwde IP-reputatie en inrichting op basis van sjablonen om DNS- en migratie-instellingen snel op maximaal 100 domeinen toe te passen.

Conclusie: verhuizen zonder zwart gat

E-mail succesvol naar een nieuwe host verhuizen betekent dat je tegelijk een toestandswijziging in DNS, gegevens en clienttoegang beheert. Iedere beheerder moet met die complexiteit rekening houden. Het doel is om terugkaatsende berichten, gegevensverlies en paniekmeldingen te voorkomen, maar controle blijft noodzakelijk. Bereid de TTL van 300 seconden voor, gebruik een parallelle overgang en houd een getest terugvalplan achter de hand.

Lees vervolgens onze uitgebreidere handleidingen over het kiezen van het juiste e-mailplatform en het beschermen van je domeinreputatie tijdens de overstap.

Betaal niet langer per gebruiker voor functies die je niet gebruikt. Probeer TrekMail gratis en ontdek hoe e-mailhosting voor beheerders eruitziet.