Overstappen van mailprovider zonder je bezorging te slopen

Als je overstapt naar Microsoft 365 of Google Workspace, verhuist je mail niet zomaar automatisch mee. Op de achtergrond regelen een paar technische instellingen bij je domeinregistrar of DNS-beheerder waar je mail naartoe gaat en wie er namens jou mag versturen. Verander je die instellingen in de verkeerde volgorde, dan loop je het risico dat mail een tijdje niet aankomt of als spam wordt gezien. Dat is met een beetje voorbereiding volledig te voorkomen, zonder dat je daar iemand voor hoeft in te huren. In dit artikel lees je precies welke stappen je in welke volgorde zet en waar de meeste mensen struikelen.

Wat er eigenlijk gebeurt als je overstapt

Je domeinnaam, zoals jouwbedrijf.nl, heeft een aantal instellingen die vastleggen hoe mail bij je binnenkomt en wie er mag versturen namens dat domein. Deze instellingen staan in het DNS, dat je kunt zien als het adresboekje van internet. Het staat meestal bij je domeinregistrar of hostingpartij, en niet bij je mailprovider zelf.

Drie van die instellingen zijn belangrijk bij een overstap. De MX-record vertelt de buitenwereld naar welke server mail voor jouw domein gestuurd moet worden. SPF is een lijst van partijen die officieel namens jouw domein mail mogen versturen, dit voorkomt dat anderen zich voordoen als jouw bedrijf. DKIM is een soort digitale handtekening die aan elke verzonden mail wordt toegevoegd, zodat de ontvanger kan checken dat de mail echt van jou komt en niet onderweg is aangepast.

Bij een overstap moet je al deze drie dingen aanpassen. Doe je dat zomaar in willekeurige volgorde, dan kan het gebeuren dat mail al naar de nieuwe provider wordt gestuurd terwijl SPF en DKIM nog niet kloppen, of dat oude en nieuwe systemen elkaar tegenwerken. Vandaar dat de volgorde en de voorbereiding zo belangrijk zijn.

Verlaag eerst de TTL, voordat je iets anders aanpast

TTL staat voor time to live en is eigenlijk een houdbaarheidsdatum voor een DNS-instelling. Elke keer als een instelling zoals je MX-record wordt opgevraagd, wordt die voor een tijdje onthouden door computers over de hele wereld, zodat niet elke mail opnieuw hoeft te vragen waar hij naartoe moet. Die onthoudtijd is de TTL, en die staat vaak standaard op een paar uur tot een dag.

Het probleem is dat een wijziging die je nu doorvoert, pas overal ter wereld bekend is zodra die oude TTL is verlopen. Verlaag je de TTL dus niet vooraf, dan kan het na jouw wijziging nog een hele tijd duren voordat alle mailservers je nieuwe instelling zien. Door de TTL een paar dagen voordat je gaat wijzigen te verlagen naar bijvoorbeeld vijf minuten, zorg je dat een latere aanpassing veel sneller overal doorkomt. Dat geeft je ruimte om snel te reageren als er iets niet klopt.

Zet de TTL na de hele overstap, als alles goed werkt, gewoon weer terug naar de oorspronkelijke waarde. Een heel lage TTL laten staan is niet nodig en levert net iets meer belasting op voor de systemen die je DNS opvragen.

De volgorde: SPF en DKIM eerst, MX als allerlaatste

De vaste volgorde is: eerst SPF aanpassen, dan DKIM instellen en controleren, en pas als beide goed staan de MX-record omzetten naar je nieuwe provider. De reden is simpel. MX bepaalt waar nieuwe mail binnenkomt, terwijl SPF en DKIM bepalen of uitgaande mail wordt vertrouwd. Je wilt dat uitgaande mail al goed is ingericht voordat je überhaupt binnenkomende mail naar het nieuwe systeem laat lopen.

Zet je de MX-record als eerste om, dan komt mail meteen bij de nieuwe provider aan, maar als je daar dan pas gaat versturen zonder correcte SPF en DKIM, loop je het risico dat die mail als onbetrouwbaar wordt gezien door de ontvangende partij. Andersom, als je SPF en DKIM eerst goed zet terwijl de oude provider nog actief is, verandert er voor de ontvanger van je mail niets totdat jij zelf de knop omzet.

SPF tijdens de overgang: beide providers moeten erin staan

SPF staat in een tekstregel in je DNS en somt op welke systemen namens jouw domein mail mogen versturen. Elke mailprovider heeft daar een eigen stukje tekst voor. Tijdens de overstap heb je vaak nog beide providers tegelijk in gebruik, bijvoorbeeld omdat oude mail nog via de oude provider binnenkomt of omdat sommige medewerkers nog niet zijn overgezet.

Vervang je de SPF-regel van de oude provider volledig door die van de nieuwe, terwijl de oude provider nog mail verstuurt namens jouw domein, dan wordt die mail niet meer als betrouwbaar herkend. De oplossing is dat je beide regels in dezelfde SPF-instelling combineert, zodat allebei de partijen tijdelijk toestemming hebben. Zodra de overstap volledig is afgerond en de oude provider niets meer verstuurt, kun je dat stukje er weer uit halen.

Let op dat een domein maar één SPF-regel mag hebben. Je voegt dus niet twee losse regels toe, maar zet de gegevens van beide providers samen in die ene regel. Je nieuwe mailprovider geeft altijd exact aan welke tekst je moet gebruiken, dat hoef je niet zelf te bedenken.

DKIM verhuist niet automatisch mee

Een veelgemaakte misvatting is dat DKIM, net als je mailbox, gewoon meegaat naar de nieuwe provider. Dat is niet zo. DKIM werkt met een sleutel die specifiek voor die ene provider is aangemaakt. De nieuwe provider genereert een eigen sleutel, en die moet je apart als nieuwe DNS-instelling toevoegen.

Vergeet je dit, dan verstuurt je nieuwe provider mail zonder geldige digitale handtekening. Sommige ontvangende systemen accepteren dat nog wel, maar steeds meer grote mailproviders, waaronder Gmail en Outlook zelf, kijken hier kritisch naar bij het bepalen of mail als spam wordt behandeld. Het instellen van DKIM staat meestal duidelijk beschreven in het instapproces van Microsoft 365 of Google Workspace, met een stukje tekst dat je moet kopiëren naar je DNS.

Controleer na het instellen altijd of DKIM ook echt actief is. Beide grote providers hebben in hun beheeromgeving een knop of statusmelding die aangeeft of de DKIM-instelling gevonden en goedgekeurd is. Wacht met de volgende stap totdat dat groen licht er staat.

MX pas als laatste omzetten, en test eerst

Pas als SPF beide providers bevat en DKIM voor de nieuwe provider actief en goedgekeurd is, zet je de MX-record om naar de nieuwe provider. Vanaf dat moment komt nieuwe mail binnen op de nieuwe plek. Omdat je de TTL al vooraf had verlaagd, gaat deze wijziging relatief snel overal doorkomen.

Voordat je die knop omzet, is het slim om eerst een testmail te versturen vanuit de nieuwe omgeving naar een adres bij een andere provider, en te checken of die mail goed en zonder spamwaarschuwing aankomt. De meeste mailproviders laten in de headers van een ontvangen mail zien of SPF en DKIM zijn goedgekeurd, ook als je daar niet technisch in thuis bent kun je vaak gewoon zoeken op ‘pass’ naast SPF en DKIM in die technische details.

Houd er rekening mee dat mail die nog onderweg is naar je oude adres, nog een tijdje kan blijven binnenkomen op het oude systeem terwijl de wijziging zich verspreidt. Log daarom nog een paar dagen in op de oude mailbox om te checken of daar niets achterblijft.

Na de overstap: opruimen en TTL terugzetten

Zodra alles een paar dagen stabiel draait en je zeker weet dat er geen mail meer via de oude provider gaat, kun je de SPF-regel opschonen door het stukje van de oude provider te verwijderen. Dat houdt je DNS overzichtelijk en voorkomt verwarring bij toekomstige wijzigingen.

Zet ook de TTL weer terug naar een normale waarde, meestal een paar uur, dat had je vooraf tijdelijk verlaagd om snel te kunnen bijsturen. Bewaar tot slot de inloggegevens van je oude provider nog een tijdje, voor het geval je met terugwerkende kracht nog bij oude mail of instellingen moet.

Blijft het goed staan?

Als je dit hebt opgelost is het goed, maar het blijft niet vanzelf goed. Dit soort instellingen verschuift bij een providerwissel, een nieuwe tool of een verhuizing van je website, en omdat er geen foutmelding komt merk je het pas als iemand erover begint. Daarvoor is Wachter gemaakt: die kijkt elke dag of er iets verandert en stuurt een seintje.

Meer lezen: mail komt niet aan bij klanten en kan iemand mailen uit naam van je bedrijf.

Veelgestelde vragen