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

# Wat zijn MX-records en waarom zijn ze kritiek bij een overstap?

MX-records zijn het enige DNS-record dat bepaalt welke server inkomende e-mail voor jouw domein ontvangt, en daarmee zijn ze het meest risicovolle record om verkeerd of op het verkeerde moment aan te passen bij een hosting-overstap. Elke zendende mailserver raadpleegt het DNS-systeem voordat hij een bericht aflevert: hij zoekt het MX-record op en stuurt de mail naar het opgegeven adres. Meer over de technische werking lees je op Wikipedia: MX record.

Verander je de MX-records te vroeg, dan komen nieuwe berichten aan op een server die nog niet ingericht is; ze worden geweigerd of teruggestuurd als bounce. Verander je ze te laat, dan wordt inkomende mail nog steeds afgeleverd bij de oude provider, terwijl je medewerkers al op de nieuwe omgeving werken en antwoorden vanuit een andere server versturen. Beide scenario's leiden tot verwarring en potentieel verlies.

De oplossing ligt in twee dingen: de DNS TTL tijdig verlagen en de juiste volgorde aanhouden. Die twee maatregelen samen geven je volledige controle over het moment van omschakeling.

# DNS TTL: de klok die bepaalt hoe lang de overstap duurt

De DNS TTL bepaalt hoelang resolvers een gecachte MX-waarde mogen gebruiken, en bij de meeste Nederlandse hostingproviders is die standaardwaarde 1 tot 24 uur, wat betekent dat een MX-wijziging zonder voorbereiding pas na die periode wereldwijd actief is. TTL staat voor Time To Live en is een waarde in seconden die bij elk DNS-record staat. Zolang de TTL niet verlopen is, gebruiken resolvers de gecachte waarde, ook als jij al een nieuw MX-record hebt ingevoerd.

De aanpak is de TTL minimaal 24-48 uur voor de geplande overstap te verlagen naar 300 seconden (5 minuten). Zodra de oorspronkelijke TTL-periode is verlopen, slaan alle resolvers de nieuwe lage TTL op. Wanneer je daarna het MX-record aanpast, is de maximale propagatietijd nog maar 5 minuten in plaats van 24 uur.

Verlaag de TTL via het DNS-beheerpanel bij je huidige provider. Bij Strato en TransIP doe je dit in de zone-editor per record; bij Hostnet is soms een support-verzoek nodig voor records met een afwijkende TTL. Controleer na de verlaging met een DNS-lookup of de lage TTL al zichtbaar is, voordat je verdergaat met de migratie.

# De juiste volgorde: eerst mailboxen migreren, dan MX aanpassen

De gouden regel bij elke mail-overstap is: migreer alle mailboxen volledig naar de nieuwe provider en pas daarna pas de MX-records aan. Zolang de MX-records nog naar de oude server wijzen, komen nieuwe berichten gewoon binnen op de vertrouwde locatie en loop je niets mis. Ondertussen kopieer je alle bestaande mails, mappen en bijlagen via IMAP naar de nieuwe server, zonder dat gebruikers het merken.

Een tool als Mailmigreren.nl werkt volledig in kopieer-modus via IMAP-APPEND streaming: de bronmailbox blijft onaangetast staan totdat jij bevestigt dat alles op de nieuwe server klaarstaat. Wachtwoorden worden uitsluitend in het werkgeheugen verwerkt en nooit op disk opgeslagen. Voor mailboxen van 5 GB reken je op 30-90 minuten migratietijd; grotere mailboxen van 10 GB of meer kunnen enkele uren in beslag nemen.

Plan de MX-omschakeling bewust buiten kantooruren. Zo heb je tijd om de eerste binnenkomende mails te controleren en eventuele configuratieproblemen op te lossen voordat medewerkers op de nieuwe omgeving inloggen.

# Dual-delivery: hoe je inkomende mail tijdens de DNS-propagatie opvangt

Dual-delivery elimineert het risico van de DNS-propagatieperiode door zowel de oude als de nieuwe mailserver tijdelijk berichten te laten accepteren, zodat inkomende mail sowieso aankomt ongeacht welk MX-record een resolver op dat moment gebruikt. Sommige beheerde mailplatforms, zoals Microsoft 365 en Google Workspace, bieden dit als ingebouwde functie via een extra geaccepteerd domein; bij een eigen server stel je een additioneel accept-domein in op de nieuwe omgeving.

Tijdens de aanbevolen dual-delivery periode van 48-72 uur accepteren beide servers inkomende berichten. Zodra de DNS-propagatie volledig is afgerond en alle resolvers de nieuwe MX-records hebben opgepikt, schakel je de doorstuur- of acceptconfiguratie op de oude server uit. De maximale vertraging van het SMTP-protocol speelt hier overigens ook mee: zoals beschreven in RFC 5321 (SMTP) moeten zendende servers bij een tijdelijke fout de bezorging minimaal 4-5 dagen herproberen, wat betekent dat kortdurende DNS-fouten zelden tot definitief verlies leiden.

Voor kleine migraties met een laag e-mailvolume en een TTL die tijdig is verlaagd, is dual-delivery optioneel. Bij kritische bedrijfsmail met hoog volume is het een verstandige extra zekerheid.

# De vijf meest voorkomende valkuilen bij MX-record aanpassingen

• TTL niet verlaagd voor de overstap: resolvers cachen de oude waarden tot 24 uur, waardoor de nieuwe MX pas laat actief wordt en je ondertussen geen controle hebt over de mailrouting.
• MX aanpassen voor alle mailboxen gemigreerd zijn: inkomende mail belandt dan op een lege of niet-geconfigureerde server en wordt geweigerd of teruggestuurd als bounce.
• SPF, DKIM en DMARC niet meegenomen: deze extra DNS-records bepalen of ontvangende servers uitgaande mails als legitiem beschouwen. Vergeet je ze aan te passen, dan belanden uitgaande berichten vaker in de spamfolder van ontvangers.
• Prioriteitswaarde verkeerd ingesteld: een MX-record met prioriteit 10 heeft hogere prioriteit dan 50 of 100. Twee records met gelijke prioriteit veroorzaken load-balancing, wat bij een overstap tot onvoorspelbare mailrouting leidt.
• Geen monitoring op bounces direct na de overstap: de eerste 2-4 uur zijn kritiek. Controleer de mail-logs op de nieuwe server actief en stel een bouncemelding in bij je mailclient.

# MX-records per provider: TTL-standaarden en aanpasstips vergeleken

De aanpak voor het verlagen van de TTL en het aanpassen van MX-records verschilt per provider, zowel in de interface als in de standaardwaarden. Onderstaande tabel geeft een overzicht van de meest gebruikte Nederlandse hostingpartijen en mailplatforms.

Bij Microsoft 365 wijs je de MX-records via je eigen DNS-provider; Microsoft publiceert voor elke tenant een unieke MX-waarde in het formaat domein-com.mail.protection.outlook.com. De exacte stappen staan in de officiële Microsoft-documentatie voor DNS-records bij externe providers. Let op dat Microsoft 365 naast het MX-record ook specifieke TXT-records voor SPF en CNAME-records voor DKIM vereist, die je tegelijk met de MX-omschakeling moet instellen.

# Na de overstap: TTL verhogen, verouderde records opruimen en verifiëren

Zodra de nieuwe MX-records minimaal 48-72 uur actief zijn en alle inkomende mail correct aankomt op de nieuwe server, verhoog je de TTL terug naar de gebruikelijke waarde van 3.600 tot 86.400 seconden. Een lage TTL van 300 seconden verhoogt de DNS-querybelasting op resolvers en je eigen nameservers; houd die waarde niet langer aan dan nodig.

Na de overstap ruim je ook de verouderde DNS-records op. Verwijder MX-records die nog naar de oude server verwijzen. Controleer het SPF-record op oude mailserver-adressen, herkenbaar als include:-verwijzingen of ip4:-entries die niet meer kloppen. Stel DKIM-selectors in voor de nieuwe provider en voer een DMARC-controle uit om te bevestigen dat rapportage via het juiste adres loopt.

Verifieer de complete configuratie met een DNS-controletool: voer je domein in en controleer of de MX-records correct zijn ingesteld, het SPF-record valide is en DKIM-handtekeningen succesvol worden geverifieerd. Een geslaagde verificatie bevestigt dat de mail-overstap volledig en zonder risico is afgerond.