MX-records aanpassen bij hosting-overstap: timing en valkuilen

# Wanneer pas je de MX-record aan bij een hosting-overstap?

Je past de MX-record pas aan wanneer de nieuwe mailbox voor 100% gevuld is met alle bestaande e-mail, mappen en berichtstatus vanaf de oude server. Wijzig je de MX-record eerder, dan komt alle nieuwe, binnenkomende e-mail direct in een lege of onvolledige mailbox terecht, terwijl je nog bezig bent met het overzetten van het archief.

De juiste volgorde is dus: eerst migreren, dan pas de DNS aanpassen. Bij mailmigreren.nl gebeurt dat in kopieer-modus: de bron blijft ongewijzigd staan terwijl elk bericht via IMAP-APPEND naar de nieuwe server wordt gestreamd. Daardoor kun je de nieuwe mailbox rustig controleren zonder dat de oude mailbox stopt met ontvangen, en zonder dat er een moment ontstaat waarop mail nergens aankomt.

Gratis migratietools van hostingproviders zoals Mijndomein, Strato of WebOke werken vaak net andersom: ze koppelen de migratie aan het overzetten van je hele hosting- en DNS-beheer, waardoor je feitelijk gedwongen wordt om eerst de knip te maken. Een provider-onafhankelijke aanpak, waarbij migratie en DNS-wijziging losse, na elkaar uitgevoerde stappen zijn, geeft je meer controle over het moment waarop je de MX-record daadwerkelijk omzet.

# Wat is een MX-record en welke rol speelt het bij mailverkeer?

Een MX-record (Mail Exchanger record) is het DNS-record dat aan de buitenwereld vertelt naar welke mailserver e-mail voor jouw domein verstuurd moet worden. Zonder een geldige MX-record accepteert geen enkele verzendende server je berichten, ongeacht hoe goed je website of hosting verder werkt.

Een domein kan meerdere MX-records hebben, elk met een prioriteitswaarde: hoe lager het getal, hoe eerder een verzendserver die mailserver probeert. Dat mechanisme is bedoeld voor failover naar een back-upmailserver, niet voor het verdelen van mail over twee losstaande mailboxsystemen tijdens een verhuizing, zoals verderop in dit artikel blijkt. Het protocol achter mailaflevering, SMTP volgens RFC 5321, gaat ervan uit dat elke MX-server voor hetzelfde domein dezelfde berichten kan afleveren; dat klopt bij failover-servers van dezelfde provider, maar niet bij twee onafhankelijke hostingpartijen.

Belangrijk om te onthouden: een MX-record stuurt alleen inkomende e-mail. Je A-record en CNAME-records, die je website laten laden, blijven volledig los daarvan staan. Je kunt dus je website al op de nieuwe hosting laten draaien terwijl de MX-record nog naar de oude mailserver wijst, en andersom. Meer achtergrond over de werking van dit recordtype staat op Wikipedia.

# Wat is DNS TTL en waarom bepaalt het jouw risico tijdens de overstap?

DNS TTL (Time To Live) is de tijd in seconden die een DNS-resolver een opgehaald record in cache bewaart voordat hij opnieuw bij de naamserver controleert of er iets is gewijzigd. Een hoge TTL betekent een trage doorvoering van je MX-wijziging, een lage TTL een snelle.

Standaard staat de TTL van een MX-record bij de meeste providers tussen 3600 seconden (1 uur) en 86400 seconden (24 uur). Verlaag die waarde 24 tot 48 uur voordat je de MX-record daadwerkelijk wijzigt naar 300 tot 600 seconden. Resolvers die de oude, hoge TTL al in cache hadden voordat jij de waarde verlaagde, houden zich namelijk nog aan die oude cachetijd; vandaar de marge van een dag of twee vooraf.

Zelfs met een verlaagde TTL is 100% garantie onmogelijk: sommige ISP's en bedrijfsnetwerken negeren de TTL-waarde bewust en cachen DNS-records tot 48 uur om hun eigen verkeer te beperken. Reken daarom op een praktisch venster van enkele uren tot twee dagen waarin een deel van de internet-mailservers nog naar je oude adres kan sturen. Achtergrond over caching binnen het Domain Name System verklaart waarom dit venster nooit helemaal op nul te krijgen is. Zet de TTL enkele dagen na een succesvolle overstap terug naar de standaardwaarde, dat scheelt onnodige belasting van je naamservers.

# Wat is een dual-delivery periode en waarom is 'gewoon twee MX-records instellen' geen oplossing?

Een dual-delivery periode is de bufferfase rond de omzetting waarin je zowel de oude als de nieuwe mailbox actief en bereikbaar houdt, zodat berichten die tijdens de DNS-propagatie nog bij de oude server binnenkomen niet verloren gaan.

Wat niet werkt, is simpelweg twee MX-records instellen die naar twee onafhankelijke, ongesynchroniseerde mailsystemen wijzen. Verzendservers kiezen dan, op basis van prioriteit en hun eigen DNS-cache, willekeurig welke van de twee ze gebruiken. Het resultaat: de ene helft van je nieuwe e-mail komt aan op de oude server, de andere helft op de nieuwe, zonder dat de twee systemen elkaars berichten kennen. Dat is precies de valkuil die veel mkb'ers verwachten op te lossen met 'gewoon twee MX-records', en die het juist erger maakt.

De werkende aanpak bestaat uit drie onderdelen. Eerst migreer je de volledige mailbox met een kopieer-methode, zodat de bron ongewijzigd blijft staan. Daarna wijzig je de MX-record in één keer, in plaats van geleidelijk. Tot slot houd je de oude mailbox nog 2 tot 3 dagen actief als vangnet en draai je daarna een korte opvolg-migratie om berichten op te halen die tijdens de propagatie nog op de oude server zijn binnengekomen. Zo krijg je het effect van dual-delivery zonder het risico van gesplitste, nooit meer samengevoegde mailboxen.

# Wat zijn de meest voorkomende valkuilen bij het wijzigen van MX-records?

De grootste valkuil is de volgorde omdraaien: eerst de MX-record wijzigen en dan pas de mailbox migreren, in plaats van andersom. Daarnaast zijn er nog vijf fouten die geregeld voor mailverlies of afgekeurde berichten zorgen.

De onderstaande tabel zet elke valkuil naast het gevolg en de oplossing, zodat je in één oogopslag ziet waar je op moet letten voordat je de knop omzet.

• MX-record wijzigen vóór de migratie is afgerond
• TTL niet op tijd verlaagd voor de omzetting
• Alleen de MX-record gecontroleerd, SPF/DKIM/DMARC vergeten
• Oude mailbox direct opgezegd na de omzetting
• Migratie alleen getest met een cachend testaccount op hetzelfde netwerk
• Twee MX-records ingesteld naar losse, ongesynchroniseerde systemen

# Hoe wijzig je een MX-record zonder mail te verliezen?

Je wijzigt een MX-record zonder mail te verliezen door migratie, DNS-wijziging en een bufferperiode in een vaste volgorde te doorlopen, nooit gelijktijdig. De zeven stappen hieronder volgen die volgorde en zijn toepasbaar bij elke IMAP-provider, van Strato en Hostnet tot TransIP en Vimexx.

Reken voor een enkele mailbox van 5 GB op 30 tot 90 minuten migratietijd; bij 10 GB of meer kan dat oplopen tot enkele uren. Plan de migratie daarom niet vlak voor een deadline, maar minimaal een halve tot hele werkdag voordat je de MX-record wilt aanpassen.

# Voorbeeld: MX-record overstap van Strato naar TransIP

Een fictief voorbeeld maakt de timing concreet: een mkb-bedrijf met 5 mailboxen van elk 3 GB stapt over van Strato naar TransIP. De hele overstap, van eerste voorbereiding tot afronding, duurt 5 dagen.

Op maandag verlaagt de ondernemer de TTL van de MX-record bij Strato naar 300 seconden. Op woensdagochtend start de migratie via mailmigreren.nl: 5 mailboxen van 3 GB kosten samen 30 euro excl. btw en zijn, gelijktijdig gemigreerd, binnen circa 1,5 uur volledig gekopieerd naar TransIP. Woensdagmiddag controleert de ondernemer alle 5 mailboxen op mapstructuur en recente berichten, en wijzigt daarna de MX-record naar de TransIP-mailserver, samen met de SPF-, DKIM- en DMARC-records.

Van woensdagmiddag tot en met vrijdag blijft de oude Strato-mailbox actief als dual-delivery buffer; de ondernemer checkt die twee keer per dag op nagekomen berichten. Op vrijdag draait hij een korte opvolg-migratie om de laatste nagekomen e-mails alsnog naar TransIP te kopiëren, en zet hij de TTL terug naar de standaardwaarde van Strato. Vanaf dat moment is de overstap voor 100% afgerond, zonder dat er ergens een bericht is kwijtgeraakt.

# Hoeveel tijd moet je reserveren voor de volledige overstap?

Reserveer voor een gemiddelde mkb-overstap 4 tot 6 dagen tussen de eerste voorbereiding en de definitieve afronding, ook al duurt de daadwerkelijke migratie van de mailbox zelf maar 30 tot 90 minuten per 5 GB.

De kosten schalen mee met het aantal mailboxen: bij mailmigreren.nl betaal je 10 euro voor de eerste mailbox en 5 euro voor elke volgende, dus 30 euro excl. btw voor 5 mailboxen, 65 euro voor 12 en 130 euro voor 25. Ter vergelijking: Hoasted MailSync rekent 15 euro per mailbox en de YourHosting Migratieservice 25 euro per mailbox, ongeacht hoeveel je er migreert. Stap je over naar Microsoft 365, kijk dan ook naar de officiële Microsoft-documentatie over DNS- en MX-records voor de exacte waarden die Microsoft verwacht.

• Dag 1: TTL verlagen naar 300-600 seconden bij de huidige provider
• Dag 2-3: mailbox(en) migreren en volledig controleren
• Dag 3: MX-record, SPF, DKIM en DMARC wijzigen
• Dag 3-5: dual-delivery buffer aanhouden en oude mailbox dagelijks checken
• Dag 5-6: opvolg-migratie draaien en TTL terugzetten naar standaardwaarde