E-mail naar een nieuwe host verhuizen: zorgvuldig overstappen

Wil je e-mail naar een nieuwe host verhuizen, dan is het kopiëren van oude berichten niet het moeilijkste. De uitdaging is nieuwe mail blijven verwerken terwijl DNS-antwoorden nog in caches staan, gebruikers op Verzenden blijven klikken en oude apparaten de verkeerde server benaderen. Daar lopen migraties vaak vast. Bepaal je nog welke oplossing op lange termijn past, begin dan bij zakelijke e-mail, zodat je dit werk niet dubbel hoeft te doen.

Veel handleidingen doen alsof het eenvoudig is: exporteren, importeren, MX aanpassen, klaar. Dat advies kan problemen veroorzaken. E-mail kent statusinformatie, DNS wordt gecachet, IMAP kan traag zijn en gebruikersgewoonten maken het nog ingewikkelder. Behandel je een mailmigratie als een websiteverhuizing, dan kunnen berichten verspreid raken over de oude mailbox, de nieuwe mailbox en iemands telefoon.

De oplossing is eenvoudig, maar niet onmiddellijk: laat beide systemen naast elkaar draaien, kopieer historische mail vooraf, verlaag de DNS-TTL ruim op tijd, schakel tijdens een gecontroleerd tijdvak over en voer een laatste incrementele synchronisatie uit voordat je de oude dienst opheft.

Dit is een praktische aanpak voor 2025-2026, zonder beloften over een migratie zonder enige onderbreking.

Waarom e-mailmigraties misgaan

Om e-mail met minder risico te verhuizen, moet je de overlap beheren. DNS-wijzigingen worden op verschillende momenten zichtbaar: sommige afzenders leveren nog bij de oude mailserver af, andere al bij de nieuwe. Zonder plan voor die tussenperiode kun je berichten uit het oog verliezen.

Wanneer iemand mail naar je domein stuurt, zoekt diens server de MX-records op. Recursieve resolvers, mailgateways en andere onderdelen van de internetinfrastructuur kunnen dat antwoord cachen. SMTP zelf is vastgelegd in RFC 5321, maar het praktische probleem zit in de uitvoering: verzendende servers vernieuwen hun DNS-informatie niet allemaal tegelijk.

Daardoor ontstaat een periode met twee actieve bestemmingen:

Afzender A ziet nog de oude MX en levert bij de oude host af.
Afzender B ziet de nieuwe MX en levert bij de nieuwe host af.
Je gebruiker bekijkt maar één mailbox en denkt dat er berichten ontbreken.

Daarom is op vrijdagavond de records omzetten en hopen op het beste riskant. Wil je de dienstverlening tijdens de verhuizing zo veel mogelijk behouden, dan heb je een gefaseerde migratie nodig, geen simpele schakelaar.

Wat je moet inventariseren voordat je DNS wijzigt

Breng voor de verhuizing in kaart wat er werkelijk bestaat: mailboxen, aliassen, gedeelde adressen, doorstuurregels, inactieve accounts en grote mailboxen. Alleen het aantal gebruikers zegt weinig over de omvang van het werk.

Begin met de mailboxen die projecten het vaakst ingewikkeld maken:

1. Grote mailboxen. Alles boven 20-50 GB verdient extra aandacht: IMAP-migraties kunnen traag zijn en providers kunnen het verkeer afremmen.
2. Gedeelde adressen. `info@`, `sales@` en `support@` zijn vaak geen gewone persoonlijke mailboxen.
3. Aliassen en doorstuurregels. Als `jane@` ook mail voor `hello@` en `jd@` ontvangt, moeten die koppelingen vanaf de eerste dag in het nieuwe systeem bestaan.
4. Mailboxen van voormalige medewerkers die nog mail ontvangen. Dit zijn stille foutbronnen die soms pas weken later opvallen.

Sla je deze stap over, dan heb je geen migratieplan, maar een aanname.

Google waarschuwt dat intensieve IMAP-synchronisatie bandbreedtebeveiligingen kan activeren. De Google Workspace-documentatie die het bronartikel aanhaalt, noemt 2500 MB IMAP-download per dag en 500 MB IMAP-upload per dag, met blokkades die bij het bereiken van de limieten tot 24 uur kunnen duren. Controleer de actuele voorwaarden; een grote mailbox kan dagen nodig hebben om te kopiëren, geen uren.

Bij TrekMail speelt het kostenmodel mee. Volgens de voorwaarden in het bronartikel beginnen betaalde abonnementen bij $3.50 per maand, werken ze met gedeelde opslag in plaats van facturering per gebruiker en bevatten Starter en hoger een migratietool aan de serverzijde. Afhankelijk van je behoeften en de actuele voorwaarden kan dat het makkelijker maken de bestemming vroeg klaar te zetten en langdurige imports op de achtergrond te laten afronden zonder dubbele gebruikerslicenties.

Een zorgvuldige manier om e-mail naar een nieuwe host te verhuizen

Een migratie met beide systemen naast elkaar beperkt risico's: maak eerst de bestemming aan, kopieer oude mail vooraf, verlaag de DNS-TTL voor de omschakeling, wijzig MX tijdens een gecontroleerd tijdvak en voer daarna een laatste incrementele synchronisatie uit.

Volg deze volgorde:

1. Richt eerst de bestemming in

Maak het domein, de mailboxen, aliassen en doorstuurregels op het nieuwe platform aan voordat je MX wijzigt. In TrekMail betekent dit het domein toevoegen, controleren of DNS gereed is en de doelmailboxen aanmaken voordat je imports start.

Nuttige documentatie: een domein toevoegen, een IMAP-migratie starten en IMAP/SMTP-instellingen.

2. Kopieer oude mail vooraf

Kopieer oudere berichten voor de omschakeling. Een gebruikelijke aanpak is eerst alles ouder dan 30 dagen te importeren en recente mail voor de laatste ronde te bewaren. Zo verhuis je een groot deel van de mail zonder tijdsdruk op het omschakelmoment.

Volgens het bronartikel haalt de TrekMail-migratietool berichten van externe IMAP-servers, zoals Gmail, Outlook en cPanel-achtige hosts, naar een specifieke TrekMail-mailbox. Schakel het overslaan van duplicaten in om het risico bij herhaalde taken te beperken.

3. Verlaag de TTL 48 uur van tevoren

Verlaag de TTL van MX en gerelateerde DNS-records ongeveer 48 uur voor de omschakeling. Een waarde van 300 seconden kan bruikbaar zijn als je provider die toestaat. Dat kan de overlap van oude en nieuwe antwoorden verkorten nadat de eerdere TTL is verlopen, maar garandeert geen onmiddellijke verversing van alle caches en bepaalt op zichzelf niet hoe spamfilters reageren.

Verander je ook de verzendconfiguratie, controleer DNS dan zorgvuldig. De TrekMail-documentatie noemt een veelgemaakte fout: een tweede SPF-record aanmaken in plaats van de include-mechanismen in één record samen te voegen.

4. Stop wijzigingen op het oude systeem

Vraag gebruikers bij de omschakeling te stoppen met verzenden vanuit het oude account. Bij migraties met meer risico kun je aanmelding door oude clients blokkeren, zodat ze geen verzonden berichten op de verkeerde host blijven aanmaken.

5. Wijzig MX en controleer daarna extern

Werk de MX-records bij en controleer vervolgens welke antwoorden vanaf internet beschikbaar zijn.

dig mx example.com +short
nslookup -type=mx example.com

Vertrouw niet alleen op het DNS-dashboard. Voer externe queries uit.

6. Voer de incrementele synchronisatie uit

Start na de MX-wijziging nog een importronde. Die haalt berichten op die tijdens de overlap bij de oude host zijn aangekomen. Deze laatste ronde verkleint het risico dat je de laatste uren inkomende mail achterlaat.

7. Schakel oude toegang snel uit

Als je hebt bevestigd dat berichten bij de nieuwe host aankomen, schakel dan gebruikersaanmeldingen bij de oude uit. Oude telefooninstellingen vormen een reëel risico. Blijft een telefoon via het oude account verzenden, dan komen antwoorden in de nieuwe mailbox terecht terwijl verzonden berichten op de oude server blijven staan en de conversatie wordt opgesplitst.

DNS-records die doorgaans veranderen bij de omschakeling

Bij een mailverhuizing zijn MX-records essentieel voor ontvangst, en meestal SPF, DKIM en DMARC voor geauthenticeerd verzenden. Verouderde records die niet meer bij de inrichting passen, kunnen problemen met aflevering en reputatie veroorzaken.

De precieze waarden verschillen per provider, maar het patroon ziet er ongeveer zo uit:

; Incoming mail
example.com.   300   IN MX 10 mail.your-new-provider.tld.

; SPF - keep only one SPF TXT record
example.com.   300   IN TXT "v=spf1 include:your-sender.example -all"

; DKIM - provider-specific selector and key
selector1._domainkey.example.com. 300 IN TXT "v=DKIM1; k=rsa; p=..."

; DMARC
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

Twee regels zijn belangrijk:

1. Publiceer nooit twee SPF-records voor dezelfde hostnaam.
2. Verwijder oude verzendrecords pas als je weet dat niets meer via de oude dienst verzendt.

Is verkeer naar Gmail belangrijk, let dan op de eisen voor afzenders. De Google-FAQ in het bronartikel omschrijft bulkafzenders als partijen die ongeveer 5,000 of meer berichten per dag naar persoonlijke Gmail-accounts sturen en beschrijft strengere handhaving vanaf november 2025. Raadpleeg Googles FAQ over richtlijnen voor afzenders voor de actuele eisen.

Wat er daadwerkelijk misgaat bij een mailverhuizing

De meeste migratieproblemen zijn geen grote storingen, maar stille verschillen: dubbele of overgeslagen berichten, verkeerde mapkoppelingen, oude apparaten die nog via de vorige server verzenden of DNS-records die slechts gedeeltelijk zijn gewijzigd.

Dit zijn de concrete foutscenario's:

IMAP-verkeersbeperking

Grote mailboxen kunnen halverwege de import vastlopen, vooral bij Gmail. Zonder aanpassing van de belasting blijven proberen kan tot een accountbeperking leiden. Daarom is vooraf kopiëren belangrijk.

Dubbele berichten

Verkeerd ingestelde herhalingen of zwakke deduplicatie kunnen berichten opnieuw kopiëren. Gebruik migratieopties die duplicaten overslaan en controleer daarna de aantallen.

Problemen met mapkoppelingen

Verzonden mail belandt soms in de verkeerde map omdat het ene systeem `Sent` gebruikt, het andere `Sent Items` en een derde een pad met een namespace. Zeggen gebruikers dat mail verdwenen is, kijk dan of die niet gewoon in een andere map staat. TrekMails handleiding over imapsync behandelt zulke operationele details.

Oude mailboxen die blijven ontvangen

Ook na de omschakeling kan mail bij de oude host aankomen doordat caches nog niet zijn verlopen of ergens een oud MX-record blijft bestaan. Precies daarvoor is de incrementele synchronisatie bedoeld.

Oude clients verzenden nog via de verkeerde server

Telefoons en Outlook-profielen houden hun instellingen vast. Na de verhuizing moeten gebruikers hun IMAP/SMTP-instellingen bijwerken, anders blijven ze de verkeerde server benaderen. Herzie je tijdens dit project ook mailboxeigenaars en toegangsrechten, lees dan tevens over e-mailbeheer voor klanten.

De migratie controleren op basis van gegevens

Controleer na de verhuizing met bewijs, niet met een gevoel. Vraag gebruikers niet alleen of alles er goed uitziet. Vergelijk de aantallen berichten, test echte aflevering, controleer het gedrag van verzonden mail en bevestig dat de oude host geen verkeer meer ontvangt.

Gebruik deze checklist:

1. Vergelijk voor elke mailbox het aantal elementen bij bron en bestemming.
2. Stuur testmail vanaf een externe provider naar meerdere adressen, inclusief aliassen en gedeelde mailboxen.
3. Antwoord vanuit de nieuwe mailbox en controleer of het bericht in Verzonden bij de nieuwe host staat.
4. Controleer dat de oude host geen gebruikersaanmeldingen meer accepteert.
5. Voer externe MX-queries uit vanaf meerdere netwerken.
6. Controleer steekproefsgewijs mappen met afwijkende namen, archieven en geneste structuren.

Vergelijk mailboxgroottes in gigabytes niet tussen providers. De opslagberekening verschilt daarvoor te sterk. Vergelijk liever het aantal elementen.

Traditionele aanpak tegenover TrekMail

Het zakelijke risico is niet alleen uitval, maar ook de kosten van overlap. Platforms met gebruikerslicenties kunnen beheerders tot haast aanzetten wanneer beide leveranciers tegelijk worden betaald. Een vast tarief kan het makkelijker maken de bestemming vroeg klaar te zetten en zorgvuldig te migreren, afhankelijk van de afgesproken voorwaarden.

TrekMail verandert de werking van DNS niet. Het kan wel de kosten en de werkwijze veranderen. Volgens de functies in het bronartikel kun je domeinen en mailboxen vooraf aanmaken, imports op de achtergrond uitvoeren en gebruikers via uitnodigingen laten instappen, met minder druk door individuele licenties tijdens de verhuizing.

Dat telt extra voor bureaus en managedserviceproviders. Beheer je veel klantomgevingen, lees dan hierna over e-mailhosting voor meerdere domeinen. De migratie is slechts een deel van het werk; het beheermodel na de omschakeling beïnvloedt ook je marges.

Wanneer TrekMail bij deze migratie kan passen

TrekMail kan passen wanneer je IMAP-mailboxen op basis van standaarden, multidomeinbeheer, gedeelde opslag, ingebouwde migratie en beheerd of eigen SMTP zoekt, afhankelijk van het abonnement. De focus op e-mail in plaats van een volledige kantoorsuite kan de inrichting overzichtelijker maken.

Abonnementsgegevens uit de prijspagina's bij het opstellen van het bronartikel; controleer de actuele voorwaarden:

• Free: $0, maximaal 10 domeinen, 5 GB gedeelde opslag, eigen SMTP.
• Starter: vanaf $3.50/maand, 50 domeinen, 15 GB gedeelde opslag, beheerd SMTP, migratietool.
• Pro: $10/maand, 100 domeinen, 50 GB gedeelde opslag, API-toegang.
• Agency: $23.25/maand, 1000+ domeinen, 200 GB+ opslag, API en MCP.
• Enterprise: prijs op maat.

Volgens het bronartikel bieden betaalde abonnementen een gratis proefperiode van 14 dagen waarvoor een creditcard nodig is. Nano wordt beschreven zonder kaartvereiste of vervaldatum; controleer de huidige voorwaarden.

Wil je de overlapkosten vooraf berekenen, raadpleeg dan de TrekMail-prijzen.

De laatste regel voor de omschakeling

Onthoud dit: om het risico op verloren mail te beperken, laat je beide systemen naast elkaar draaien totdat je de aflevering hebt gecontroleerd, de incrementele synchronisatie opnieuw hebt uitgevoerd en gebruikerstoegang tot de oude host hebt geblokkeerd.

Dat is de aanpak: eerst inventariseren, grote mailboxen vooraf kopiëren, TTL ruim op tijd verlagen, MX gecontroleerd wijzigen, de laatste synchronisatie uitvoeren en controleren met aantallen in plaats van indrukken.

Deze stappen kunnen problemen bij de verhuizing beperken. Sla je ze over, dan besteed je misschien de volgende maand aan het zoeken naar verdwenen mail die gewoon is afgeleverd op een plek waar niemand meer keek.