Een zakelijke e-mailmigratie wordt vaak beschreven als het verplaatsen van mailboxen en het aanpassen van MX. Voor ontvangers blijft het domein echter de zichtbare identiteit, terwijl facturatie, formulieren, support, scanners en applicaties vaak zelfstandig blijven verzenden. Als alleen MX wordt gewijzigd, kan ontvangst werken terwijl facturen en aanmeldcodes nog via het oude pad lopen. Een veilige migratie begint daarom met alle stromen en eindigt pas na externe DNS- en berichttests.
Werk met vier sporen: mailboxen en data, inkomende ontvangst, uitgaande verzenders en authenticatie. Noteer per toepassing From, Return-Path, DKIM-selector, volume, eigenaar en kritikaliteit. Voeg CRM, webshop, helpdesk, monitoring, apparaten en campagnes toe. Een onbekende afzender blijft in de inventaris totdat iemand heeft vastgesteld wat hij doet. Zo voorkom je dat een stille afhankelijkheid pas zichtbaar wordt wanneer een klant geen bevestiging ontvangt.
Inventariseer mailboxen en verzenders
Maak een lijst van accounts, aliassen, groepen, distributielijsten en gedeelde adressen. Koppel ieder account aan een eigenaar en bewaarbeleid. Verzamel voorbeeldberichten voor facturen, menselijke antwoorden, formulieren, notificaties en campagnes. Lees Authentication-Results en noteer From, Reply-To, Envelope-From en resultaten van SPF, DKIM en DMARC. Externe verzenders hebben een eigen migratiestap nodig. Vraag niet alleen wie de rekening betaalt, maar ook wie DNS, sleutel en afzenderlogica kan wijzigen. Dit is extra belangrijk bij Nederlandse organisaties met meerdere handelsnamen en labels.
- Accounts, aliassen, groepen en bewaarbeleid.
- Huidige MX-doelen, prioriteiten en TTL.
- Applicaties, verzenddomeinen, Return-Path en volumes.
- SPF-, DKIM-, DMARC- en overige TXT-records.
- Testontvangers, onderhoudsvenster en terugvalcontact.
- Voorbeeldberichten zonder onnodige persoonsgegevens.
Meet eerst de publieke DNS- en mailstatus
Controleer MX, TXT en nameservers vanaf meerdere resolvers. De DNS-checker laat zien wat een ontvanger kan waarnemen. Bewaar tijd, TTL en antwoord. Zoek naar dubbele SPF-records, DMARC op de verkeerde naam en selectors zonder eigenaar. Een ontbrekend record kan bewust zijn voor een subdomein dat nooit mailt, maar leg dat vast. Vergelijk de autoritatieve zone met publieke respons vóór je iets wijzigt. Zonder baseline kun je een regressie niet van een oud onbekend probleem onderscheiden.
Test echte flows naar beheerde adressen. Controleer SPF, DKIM, DMARC, alignment en bounces en gebruik de E-mailveiligheidscheck als openbare aanvulling. Deel geen volledige inhoud of persoonsgegevens in een diagnose. Eén geslaagde testmail bewijst niet dat een factuur of resetbericht dezelfde route gebruikt. Bewaar voor iedere kritieke toepassing een testresultaat en eigenaar.
Nieuwe mailboxen en coexistence voorbereiden
Maak accounts, aliassen, groepen, filters en regels in het nieuwe systeem voordat MX wordt gewijzigd. Bepaal per adres welk systeem tijdens de overgang leidend is. Een ongeplande parallelle levering kan berichten verdelen en antwoorden uit het verkeerde systeem sturen. Exporteer data volgens interne eisen en houd de oude omgeving gecontroleerd beschikbaar. Test externe afzenders, onbekende ontvangers, bijlagen, forwards en automatische antwoorden. Een ingelogde testgebruiker is geen bewijs dat klantmail goed loopt.
Verlaag TTL alleen volgens een plan en verwacht geen wereldwijde onmiddellijke wissel. Resolvers kunnen oude antwoorden blijven gebruiken. Bekijk na de MX-wijziging meerdere netwerken, wachtrijen, bounces en berichten die naar het oude systeem gaan. Een timeout is onbekend, geen reden om meerdere records tegelijk te veranderen. Het terugvalplan benoemt oude MX, relevante TXT-records, toegang en beslisser. Herstel alleen waarden die vooraf zijn goedgekeurd.
SPF gecontroleerd aanpassen
SPF publiceert welke systemen bepaalde SMTP-identiteiten mogen gebruiken. RFC 7208 beschrijft syntax en lookup-limiet. Voeg bij een migratie geen tweede SPF-record toe en verwijder een include niet voordat logs tonen dat de oude toepassing klaar is. De SPF-builder helpt structureren, maar de inventaris bepaalt wat legitiem is. Test elk kritisch systeem en noteer Return-Path en From apart. SPF alleen bewijst niet dat het zichtbare From-domein is uitgelijnd.
Een te lange SPF-keten moet bewust worden vereenvoudigd. Kopieer geen onbekende tekst en laat een permanente onbekende bron niet stilzwijgend toe. Bewaar pass, fail, permerror en unknown als verschillende toestanden. Een test vanaf het nieuwe systeem zegt niets over een vergeten scanner of applicatie. Plan een review nadat de oude dienst is uitgefaseerd.
DKIM en DMARC stapsgewijs activeren
DKIM gebruikt selector en publieke sleutel in DNS. Maak een selector voor het nieuwe pad, publiceer de sleutel en controleer de handtekening na alle relais. Laat de oude selector tijdelijk staan voor berichten die nog onderweg zijn en plan verwijdering. RFC 6376 beschrijft domein, selector en gesigneerde headers. Bewaar privésleutels nooit in rapporten. Controleer dat ieder bericht werkelijk door de beoogde route wordt ondertekend.
DMARC koppelt SPF of DKIM aan het zichtbare From en levert beleid en rapportage. RFC 7489 beschrijft alignment en reports. Begin tijdens de migratie met observeren, analyseer legitieme bronnen en verscherp daarna. De DMARC-builder helpt parameters voorbereiden, maar beleid en rapportbestemming horen bij een eigenaar en incidentproces. Een te strenge policy vóór het inventaris kan legitieme facturen blokkeren; een permanente monitorstand beschermt niet voldoende tegen spoofing.
Cutover met stopcriteria uitvoeren
Definieer venster, beslisser, tests en stopcriteria. Sla de uitgangswaarden op, bevestig de mailboxmigratie en wijzig MX volgens plan. Test ontvangst en verzending naar meerdere domeinen, met bijlagen, antwoorden, formulieren, facturen en notificaties. Controleer Authentication-Results en bounces. Stop bij een ontbrekende mailbox, stijgende rejects, ontbrekende DKIM of onverwacht DMARC-gedrag. Een bericht in de inbox is geen bewijs dat ieder kritiek proces werkt.
Terugvallen betekent niet zomaar alle oude waarden terugplaatsen. MX herstellen haalt al geleverde mail niet terug en corrigeert geen fout TXT-record. Volg alleen het afgesproken plan en bewaar de meetgegevens. Communiceer wat bevestigd is en wat onbekend blijft. Parallelle noodwijzigingen maken de oorzaak onduidelijk en kunnen de reputatie verder beschadigen.
Nazorg en opruimen
Herhaal DNS- en berichttests na de coexistenceperiode. Bekijk bounces, vertraging, spamplaatsing en verzending via het oude pad. Google benadrukt authenticatie, TLS en geldige DNS, maar geen enkele richtlijn garandeert inboxplaatsing bij elke ontvanger. Verwijder daarna oude toegang, MX-doelen, SPF-includes en DKIM-selectors volgens een gedocumenteerde datum. Controleer DMARC-rapporten en update het noodhandboek. Voor meerdere Nederlandse merken test je elk zichtbaar domein apart.
Neem ook privacy en continuïteit op in de afsluiting. Controleer exports, resterende toegang tot het oude systeem, automatische forwards, gedeelde mailboxen en bewaartermijnen. De API-documentatie beschrijft mogelijkheden voor periodieke controles. Een technische levering is pas afgerond wanneer eigenaar, rechten, data en uitzonderingen zijn vastgelegd. Plan een review na de eerste factuur- en campagnecyclus.
Controleer bij de afsluiting ook privacy en continuïteit. Leg vast welke data is geëxporteerd, wie nog toegang heeft tot het oude systeem en hoe lang die data daar blijft. Test forwards, automatische antwoorden, gedeelde mailboxen en bewaarbeleid. DMARC-rapporten gaan naar een bewaakt adres met een eigenaar. Voor meerdere Nederlandse labels controleer je ieder zichtbaar From-domein apart. Een technische levering kan geslaagd zijn terwijl oude rechten of een vergeten SMTP-apparaat nog risico geven.
Plan een review na de eerste factuur- en campagnecyclus. Vergelijk de senderinventaris met werkelijke Authentication-Results, sluit onbekende bronnen en geef uitzonderingen een einddatum. De API-documentatie kan herhaalbare controles ondersteunen, maar een rapport moet bron, tijd en status tonen. Een totaalscore die unknown als gezond behandelt, geeft een vals gevoel van veiligheid. Laat de eigenaar bevestigen dat de migratie voor iedere kritieke flow werkelijk is gesloten.
Plan na de cutover een review na de eerste factuur- en campagnecyclus. Vergelijk werkelijke Authentication-Results met de senderinventaris, sluit onbekende bronnen en geef uitzonderingen een einddatum. Controleer Nederlandse labels, gedeelde mailboxen, forwards, automatische antwoorden en apparaten die zelfstandig SMTP gebruiken. DMARC-rapporten horen bij een bewaakt adres met eigenaar. De technische levering kan goed zijn terwijl oude rechten, data in het vorige systeem of een vergeten scanner nog risico geven.
Bewaar plan, DNS-baseline en terugvalwaarden voor het volgende incident. De API-documentatie kan periodieke controles ondersteunen, maar een rapport moet bron, tijd en toestand noemen. Geef unknown niet de kleur groen. Laat de eigenaar bevestigen dat mailboxen, rechten, bewaartermijnen en alle kritieke stromen echt zijn gesloten. Zo is een migratie ook voor een organisatie met meerdere Nederlandse merken en filialen controleerbaar.
Sluit de migratie af met een vergelijking van inventaris en werkelijk verkeer. Controleer welke afzenders nog via het oude systeem gaan, welke gedeelde mailboxen forwards hebben en wie nog toegang heeft tot oude data. Geef onbekende bronnen een eigenaar en deadline. Een eindrapport voor een Nederlandse organisatie vermeldt ook bewaarbeleid, factuurstromen en de route voor escalatie. Zo is een succesvolle testmail niet het enige bewijs waarop de beslissing rust.
Een eindrapport benoemt ook wie de overgang mag terugdraaien, hoe lang de oude omgeving beschikbaar blijft en wanneer uitzonderingen opnieuw worden bekeken. Controleer gedeelde mailboxen, automatische antwoorden, forwards en apparaten die rechtstreeks SMTP gebruiken. Voor filialen en handelsnamen test je elk From-domein apart. Een technisch groene test is pas voldoende wanneer eigenaar, rechten, bewaartermijn en kritieke bedrijfsstroom samen zijn bevestigd.
Bewaar de DNS-baseline en het terugvalplan voor een volgend incident. Een eindrapport noemt mailboxen, forwards, gedeelde adressen, bewaartermijnen en oude toegang, niet alleen de testmail. Voor ieder zichtbaar From-domein is een eigenaar verantwoordelijk voor rapportage en uitzonderingen. Zo blijft de migratie ook bij meerdere filialen en handelsnamen controleerbaar.
Plan een extra controle nadat de oude dienst definitief is afgesloten. Zoek resterende forwards, apparaten, SMTP-bronnen en DKIM-selectors en leg uit waarom ze verwijderd of behouden zijn. Vergelijk de actuele rapporten met de baseline. Een eigenaar bevestigt dat mailboxen, rechten, bewaarbeleid en kritieke berichten samen zijn gecontroleerd.
- Mailboxen, applicaties, verzenders en eigenaren inventariseren.
- MX, SPF, DKIM, DMARC en echte berichten vóór de wijziging meten.
- Accounts, data en gecontroleerde coexistence voorbereiden.
- Authenticatie voor iedere echte flow testen.
- MX wijzigen met stop- en terugvalcriteria.
- Opnieuw meten, oude afhankelijkheden verwijderen en documenteren.
Mailboxen wisselen van dienst, maar het domein blijft de identiteit die ontvangers zien.
Principe voor gecontroleerde e-mailmigratie
Een betrouwbare e-mailmigratie koppelt mailboxen, MX, verzenders, SPF, DKIM en DMARC. Begin met de DNS-checker, gebruik de E-mailveiligheidscheck en bereid wijzigingen met SPF-builder en DMARC-builder voor. De API-documentatie helpt herhaalbare controles bouwen. Houd onbekende toestanden zichtbaar en wijs uitzonderingen toe.