E-mailmigratie: 7 fouten die berichten verloren laten gaan

Een e-mailmigratie lijkt een kopieertaak totdat e-mail op twee plaatsen binnenkomt, gebruikers oude gesprekken beantwoorden en bounces krijgen, en iemand ontdekt dat de mailbox van de directeur 85GB groter is dan het gekozen pakket. Begin voor de hulpmiddelen bij deze imapsync-gids voor beheerders. Dit artikel is het draaiboek voor alles eromheen: DNS, maptoewijzing, snelheidsbeperkingen, mailboxquota en lastige uitzonderingen die van een gewone migratie een weekendstoring maken.

Het probleem is eenvoudig: mensen behandelen e-mail als bestanden. Erger is dat mailboxen tijdens de verhuizing blijven veranderen, DNS-caches een misleidend beeld geven en IMAP-servers het niet eens zijn over mapgedrag. De oplossing is geen heldenwerk, maar voorbereiding, controle en weigeren om hoeken af te snijden die om 6 PM onschuldig lijken en maandag om 9 AM rampzalig blijken.

Waarom e-mailmigratie in productie mislukt

E-mailmigratie mislukt wanneer beheerders haar als één gebeurtenis behandelen in plaats van een beheerste reeks: inventariseren, voorbereiden, omschakelen, een verschilronde uitvoeren en controleren. E-mail is levende data. DNS wordt opgeslagen in caches. Clients gedragen zich niet hetzelfde. Sla je één laag over, dan krijg je geen schone verhuizing maar gedeeltelijke bezorging, duplicaten of ongemerkt gegevensverlies.

1. Gesplitste DNS veroorzaakt de eerste migratiestoring

De eerste fout is meestal niet de kopie, maar de routering. Sommige afzenders gebruiken binnen enkele minuten je nieuwe MX. Andere houden de oude MX uren in de cache. Tijdens dat venster kan e-mail op beide systemen aankomen. Is de oude host uitgeschakeld, dan krijg je bounces. Is deze nog actief, dan blijven berichten daar achter.

Microsoft adviseert de MX-TTL vóór een IMAP-omschakeling te verkorten, zodat bijgewerkte records sneller worden verspreid. Dat advies is saai, maar redt migraties. Als je huidige TTL 86,400 seconden is en je MX op de verhuisavond wijzigt, ben je de controle over de planning al kwijt.

;; T-48 hours: inspect current MX TTL
example.com.  86400  IN MX 10 oldmail.example.com.

;; T-48 hours: lower it before cutover
example.com.    300  IN MX 10 oldmail.example.com.

;; T-0: switch to new provider
example.com.    300  IN MX 10 mail.trekmail.net.

Verhuis je naar TrekMail, haal dan de exacte records uit Een domein toevoegen aan TrekMail en controleer vóór de aankondiging dat het domein actief is. TrekMail controleert DNS ook live en helpt zo de klassieke fout vinden waarbij oude MX-records blijven staan.

Slechte omschakeling: MX om 10 PM wijzigen, de oude host om 10:05 PM uitschakelen en maandag ontdekken dat de gateway van een leverancier het oude record het hele weekend heeft bewaard.

Een andere valkuil is SPF. Als inkomende e-mail naar het nieuwe systeem gaat, maar uitgaande verificatie nog fout is, belanden antwoorden in spam. De afzenderregels van Google zijn niet langer optioneel. Gebruik één SPF-record, lijn DKIM uit en publiceer DMARC.

2. Snelheidsbeperkingen breken de droom van één weekend

De tweede migratiefout is een fysieke beperking. De flessenhals is meestal niet je lokale bandbreedte, maar de bronprovider die bepaalt dat je voorlopig genoeg hebt gekopieerd. Google, Microsoft en andere gehoste systemen remmen agressief IMAP-verkeer af. Dan worden voortgangsschattingen fictie en vertraagt of stopt de taak.

Daarom is alles tegelijk een slecht plan voor meer dan een piepklein team. Een mailbox van 10GB in een omgeving die per dag slechts een fractie daarvan toestaat, wordt niet sneller voltooid omdat jij dat wilt. Limieten houden geen rekening met je onderhoudsvenster.

De oplossing is gefaseerde migratie:

1. Zet eerst oudere e-mail klaar, doorgaans alles ouder dan 60 tot 90 dagen.
2. Laat de tool gedurende de week opnieuw proberen en pauzes toepassen.
3. Wijzig MX pas wanneer het historische volume al op de bestemming staat.
4. Voer tijdens de omschakeling een verschilronde voor recente e-mail uit.

De IMAP-import aan de serverkant van TrekMail is voor deze werkwijze ontworpen. De actuele documentatie voor Een migratie starten in het dashboard bevestigt dat de tool e-mail van een externe IMAP-server naar een gekozen TrekMail-mailbox haalt en een optie Duplicaten overslaan heeft. Herhaalde rondes zijn normaal bij een veilige migratie en geen teken dat er iets misging.

Oude tegenover nieuwe aanpak: traditionele providers rekenen per gebruiker en laten je daarnaast afzonderlijke migratietools kopen. Met de nieuwe aanpak bereid je de verhuizing voor via ingebouwde IMAP-migratie, betaal je een vast pakket vanaf $3.50 per maand en maak je niet van elke mailbox een licentiegebeurtenis.

3. UIDVALIDITY kan van één migratie drie kopieën maken

Deze fout verbergt zich achter een geslaagd uitziende voortgangsbalk. IMAP-berichten hebben unieke identificatoren, maar die zijn alleen betrouwbaar binnen de regels van hun mailbox. Wanneer de server de mapstatus genoeg wijzigt om UIDVALIDITY opnieuw in te stellen, kan een eenvoudige tool oude berichten als nieuwe zien en ze opnieuw kopiëren.

IMAP4rev1 (RFC 3501) definieert UIDVALIDITY met een reden. Als deze verandert, zijn oude bericht-UID's niet meer betrouwbaar. Dat is normaal protocolgedrag, maar rampzalig migratiegedrag wanneer een tool alleen op UID's vertrouwt.

Gebruikelijke oorzaken:

• Een gebruiker hernoemt of maakt een map opnieuw tijdens de verhuizing.
• De bronserver bouwt indexen opnieuw op.
• Een beheerder voert onderhoud uit dat de mailboxstatus verandert.

De praktische verdediging is eenvoudig. Leg mailboxonderhoud tijdens het migratievenster stil. Vraag gebruikers geen mappen te hernoemen, duizenden berichten naar Archief te slepen of Verzonden op te schonen tijdens de synchronisatie. Gebruik vervolgens een bestemming die duplicaten in herhaalde rondes kan overslaan in plaats van blind op map-UID's te vertrouwen.

Vergelijk bij handmatige controle de mapaantallen vóór en na. Stop niet bij de inbox. Controleer Verzonden, Prullenbak, aangepaste projectmappen en gedeelde archieven. Daar verbergen zich grote aantallen duplicaten.

4. Maptoewijzing maakt migraties snel vreemd

Maptoewijzing breekt e-mailmigraties omdat IMAP-servers het niet eens zijn over hiërarchiescheidingstekens, namen van systeemmappen en het labelmodel van Gmail. Gebruikers ervaren dit als ontbrekende mappen of dubbele berichten. Technisch is de e-mail vaak aanwezig, maar slecht vertaald, wat genoeg is voor paniek en supportvragen.

Dit probleem kent twee gebruikelijke vormen. Ten eerste het verschil in scheidingstekens: één server gebruikt punten in mapnamen en een andere schuine strepen. Ten tweede Gmail-labels: één bericht kan onder meerdere labels staan en IMAP presenteert deze als mappen.

Zo verandert een bronmailbox met nette Gmail-labels in een opgeblazen bestemming met herhaalde e-mail in Verzonden, aangepaste mappen en archieven. De eigen documentatie van Microsoft noemt dubbele e-mail expliciet wanneer Gmail-labels betrokken zijn en de map [Gmail] niet wordt uitgesloten.

# Example folder rules
^INBOX\.Sent$        -> Sent Items
^INBOX\.Trash$       -> Deleted Items
^\[Gmail\]/Trash$   -> Deleted Items
^\[Gmail\]/All Mail$ -> [SKIP]

Sla bij migratie vanuit Gmail [Gmail]/All Mail over, tenzij je een zeer specifieke uitzondering hebt. Anders vraag je om duplicaten. Voor clients na de verhuizing houdt TrekMail het overzichtelijk met standaardwaarden in IMAP & SMTP-instellingen voor alle clients.

5. De reusachtige mailbox vernietigt budget en planning

Migratieplannen mislukken meestal op gemiddelden. Echte omgevingen mislukken op uitschieters. Eén mailbox die sinds 2011 e-mail verzamelt, kan groter zijn dan tien gewone gebruikers samen. Als je het werk begroot, een doelpakket kiest en de planning maakt zonder eerst elke mailbox te meten, blaast die uitschieter het project op.

Dit is de valkuil van een lagere licentie. Bronsystemen, vooral oudere lokale installaties, tolereerden vaak gigantische mailboxen. Veel gehoste platforms doen dat niet. Wanneer het doelquota kleiner is dan de echte mailbox, mislukt de migratie niet netjes. Vaak gebeurt dat pas laat, na uren verspilde overdracht.

Begin altijd met een inventaris. Bepaal daarna of het doelmodel ongelijke mailboxgroottes ondersteunt zonder dure eenmalige upgrades.

Gedeelde opslag is operationeel beter dan opslag per gebruiker. Bij TrekMail wordt opslag over het account gedeeld in plaats van elke mailbox in dezelfde kleine ruimte te dwingen. Dat is belangrijk voor oprichters, juridische mailboxen en gedeelde inboxen van bureaus. Voor teams met veel domeinen werkt e-mailhosting voor meerdere domeinen alleen als het opslagmodel uitzonderingen niet bestraft.

Wil je het gebruik na de verhuizing volgen, dan beschrijft TrekMail limieten en quota in Opslagquota voor mailboxen.

6. Beschadigde berichten zijn normaal, handel als een beheerder

Een schone e-mailmigratie betekent niet dat letterlijk elk item geldig is. Oude mailopslag verzamelt beschadigde MIME-structuren, bijlagen zonder inhoud en ongeldige agenda-uitnodigingen. Als elk defect item alles stillegt, kan één kapot bericht uit 2014 een verder goede migratie blokkeren.

Hier verwarren mensen precisie met vakbekwaamheid. Je wilt een controlespoor, maar niet het hele proces bevriezen omdat een dode bijlage niet kan worden verwerkt.

Stel een drempel voor slechte items in. Registreer elke omissie, controleer het rapport en ga door. De meeste mislukte items zijn rommel, duplicaten uit eerdere systemen of ongeldige oude uitnodigingen die niemand nodig heeft. Staat iets gevoeligs in het CSV-bestand, haal dat bericht dan handmatig op. Dat is nog altijd sneller dan de hele migratie gegijzeld houden.

De ingebouwde migratie van TrekMail toont voortgang en fouten in het dashboard. Komt e-mail na de omschakeling niet aan waar je verwacht, begin dan met Ik ontvang geen e-mail, met stappen voor MX- en mailboxcontrole.

7. LegacyExchangeDN is de Exchange-valkuil die blijft bestaan

Deze fout is specifiek, vervelend en veelvoorkomend. Gebruikers antwoorden in Outlook op een oud intern gesprek en krijgen een IMCEAEX-bounce of melding dat de ontvanger niet bestaat, terwijl de mailbox bestaat en nieuwe e-mail werkt. De oorzaak is niet SMTP, maar de oude Exchange-identiteit in historische berichten en opgeslagen adressen.

Exchange bewaart oude adressering in X.500-stijl via het kenmerk LegacyExchangeDN. Bij migratie tussen Exchange-omgevingen, of bij een slechte overstap, kunnen antwoorden op oude berichten naar die identiteit blijven verwijzen. Als de doelmailbox de oude waarde niet als X500-proxyadres bevat, mislukt het antwoord.

# Find the old LegacyExchangeDN on source
Get-Mailbox -Identity user@example.com | Format-List LegacyExchangeDN

# Add it as an X500 proxy address on destination
Set-Mailbox -Identity user@example.com -EmailAddresses @{add="X500:/o=OldOrg/ou=Exchange Administrative Group/cn=Recipients/cn=user"}

Dit raakt niet elke migratie, omdat een gewone IMAP-verhuizing geen eigen Exchange-objecten meeneemt zoals een volledige Exchange-migratie. Moeten Outlook-gebruikers zonder problemen oude interne gesprekken kunnen beantwoorden, controleer dit dan vóór goedkeuring. Het is een probleem dat pas verschijnt nadat het project klaar is verklaard.

Een veiliger omschakelplan voor e-mailmigratie

Een veilige migratie is gefaseerd, meetbaar en bewust saai. Dat is het doel. Je wilt minder verrassingen en niet automatisering om de automatisering. De beste omschakelingen lijken rustig omdat het riskante werk vóór de MX-wijziging plaatsvond.

1. Inventariseer elke mailboxgrootte en markeer opvallend grote waarden.
2. Verlaag de MX-TTL 24 tot 48 uur vóór de omschakeling.
3. Maak eerst de doeldomeinen en mailboxen.
4. Voer de historische IMAP-synchronisatie vóór het weekend uit.
5. Leg mapopruiming en bulkverplaatsingen tijdens de laatste ronde stil.
6. Wijzig MX pas wanneer de bestemming kan ontvangen.
7. Voer één laatste verschilronde uit.
8. Test inkomend en uitgaand verkeer, mapaantallen en antwoorden op oude gesprekken.

Bouw je de bestemming vanaf nul, dan behandelt e-mail maken met je domein de inrichting, terwijl e-mailaccounts in bulk maken helpt bij meer dan enkele gebruikers.

Voor TrekMail is de route helder: voeg het domein toe, controleer DNS, maak mailboxen, voer op een betaald pakket de ingebouwde IMAP-migratie uit en schakel actief verkeer om nadat het grote volume is gekopieerd. Prijzen beginnen bij $3.50 per maand. Betaalde pakketten hebben een gratis proefperiode van 14-day waarvoor een creditcard nodig is. Nano staat los daarvan: geen kaart, geen proefperiode en altijd gratis.

Conclusie: e-mailmigratie is bedrijfsvoering en geen kopieertaak

E-mailmigratie slaagt wanneer je de lastige onderdelen respecteert: opgeslagen DNS, afgeremde bronnen, inconsistent IMAP-gedrag, niet-passende quota en resten van Exchange. Negeer je die, dan lijkt het project in orde tot gebruikers e-mail missen. Behandel migratie als actieve infrastructuur en ze wordt voorspelbaar. Daar draait alles om.

Wil je na de verhuizing een model met een vast tarief, dan biedt TrekMail multidomainhosting, gedeelde opslag, ingebouwde IMAP-migratie, doorsturen van mailboxen, API-toegang en een inrichting op basis van standaarden zonder kosten per gebruiker. Begin op trekmail.net of vergelijk pakketten bij prijzen van TrekMail.