DNSSEC, SPF, DKIM en DMARC bij hosting-overstap: checklist

# Wat gebeurt er met SPF, DKIM en DMARC bij een hosting-overstap?

SPF, DKIM en DMARC zijn TXT-records die aan je domeinnaam hangen, niet aan je mailbox: ze verhuizen dus niet automatisch mee wanneer je van hostingprovider wisselt. Je moet ze na de overstap zelf opnieuw instellen in de DNS-zone van je domein, anders accepteren ontvangende mailservers je berichten niet meer of zetten ze die in de spamfolder. SPF bepaalt welke servers namens jouw domein mail mogen versturen, DKIM voegt een digitale handtekening toe aan elk bericht en DMARC vertelt ontvangende servers wat ze moeten doen als die twee checks falen.

Bij een gewone update binnen dezelfde provider verandert er niets aan deze records, want de verzendende mailservers blijven identiek. Bij een hosting-overstap verandert echter het IP-adres en de infrastructuur waarmee je mail verstuurt: precies het soort wijziging waar SPF, DKIM en DMARC voor gebouwd zijn om te controleren. Vergeet je de update, dan blijft het domein autoriteit toekennen aan de oude, mogelijk uitgeschakelde server en niet aan de nieuwe.

Providers die adverteren met een 'gratis migratie', zoals Mijndomein, Strato of WebOke, verplaatsen doorgaans alleen de mailbox-inhoud binnen hun eigen platform. Zodra je naar een andere provider verhuist, zoals bij een overstap via mailmigreren.nl, ligt de verantwoordelijkheid voor SPF, DKIM en DMARC bij jou of je nieuwe host, ongeacht welke tool de berichten zelf kopieert.

# SPF-record: welke wijzigingen vergeet je makkelijk?

Het SPF-record bepaalt welke mailservers namens jouw domein mogen verzenden, en bij een overstap vergeet men het vaakst om het include-mechanisme van de nieuwe provider toe te voegen of dat van de oude op tijd te verwijderen. Een SPF-record ziet er tijdens de overgangsperiode bijvoorbeeld uit als 'v=spf1 include:_spf.oudeprovider.nl include:_spf.nieuweprovider.nl ~all', en wordt daarna weer opgeschoond tot alleen de nieuwe provider.

Daarbij geldt een harde grens: maximaal 10 DNS-lookups per SPF-check, vastgelegd in RFC 7208. Stapel je tijdens de overstap te veel includes op elkaar, dan faalt de volledige SPF-controle met een permerror, ook voor mail die wel via een geautoriseerde server verstuurd wordt. Test daarom na elke wijziging met een SPF-validator voordat je verdergaat.

Vergeet ook niet dat sommige nieuwe providers een eigen SPF-syntax hanteren, zoals een specifieke subdomeinverwijzing in plaats van een IP-reeks. Kopieer nooit blind een voorbeeldrecord van een andere website; vraag het exacte include-adres op bij de documentatie van je nieuwe hostingprovider.

# DKIM-selector: waarom de nieuwe hostingprovider een nieuwe sleutel nodig heeft

DKIM werkt met een privé-publieke sleutelpaar dat uniek is per hostingprovider, dus een DKIM-record verhuist nooit automatisch mee naar een nieuwe host. De publieke sleutel staat als TXT-record onder een selector, bijvoorbeeld 'selector1._domainkey.jouwdomein.nl', en die selector en sleutelwaarde moet je exact overnemen uit het controlepaneel van je nieuwe provider zodra de mailbox daar actief is.

Zonder correcte DKIM-instelling zet de nieuwe mailserver berichten wel de deur uit, maar zonder geldige handtekening. Ontvangende servers zoals Gmail en Outlook kunnen die handtekening dan niet valideren tegen het publieke sleutelrecord, wat het spamrisico direct verhoogt. Sinds 1 februari 2024 eisen Google en Yahoo zelfs een geldige DKIM-configuratie voor afzenders van meer dan 5.000 e-mails per dag, en ook bij kleinere afzenders wordt ontbrekende authenticatie steeds vaker afgestraft met een lagere afleverkans.

Een veelgemaakte fout is dat mensen wel een nieuw DKIM-record toevoegen, maar de oude selector laten staan naast een verouderde sleutel. Dat is op zich niet schadelijk, want een niet-actieve selector wordt simpelweg genegeerd, maar het maakt je DNS-zone onnodig rommelig en foutgevoelig bij toekomstige wijzigingen.

# DMARC-policy: wat verandert er tijdens de overstap

DMARC bepaalt wat een ontvangende mailserver moet doen met berichten die niet slagen voor de SPF- of DKIM-controle, en tijdens een hosting-overstap zet je die policy het beste tijdelijk op p=none zodat er geen legitieme mail wordt geweigerd terwijl je nieuwe SPF- en DKIM-records nog inwerken. Staat je DMARC-record al op p=quarantine of p=reject, dan kan een half bijgewerkte SPF-configuratie ervoor zorgen dat eigen mail alsnog in de spamfolder verdwijnt of hard bounced.

Een DMARC-record bevat ook een rapportage-adres (rua) waarop je dagelijks een overzicht krijgt van geslaagde en mislukte authenticatiechecks per verzendende server. Tijdens en na een overstap is dit rapport de snelste manier om te zien of de nieuwe provider correct is opgenomen in SPF en DKIM, vaak eerder dan een klacht van een ontvanger je bereikt.

Zodra de migratie is afgerond en de rapportages een week lang schoon zijn, kun je de policy weer aanscherpen naar quarantine en uiteindelijk reject. Dat laatste is verstandig, want een DMARC-record zonder afdwingend beleid biedt in de praktijk weinig bescherming tegen spoofing van je domein.

# DNSSEC: de vergeten instelling die je hele domein kan platleggen

DNSSEC beveiligt DNS-antwoorden zelf met digitale handtekeningen, zodat een resolver kan controleren of een DNS-record echt van jouw domein komt en niet vervalst is. Wissel je van DNS-provider zonder de DS-record bij je domeinregistrar bij te werken, dan ontstaat er een gebroken vertrouwensketen tussen registrar en nameserver, en verwerpen validerende resolvers ineens alle DNS-antwoorden voor je domein, niet alleen die voor mail.

Dat maakt DNSSEC de meest onderschatte valkuil bij een hosting-overstap: waar een fout in SPF of DKIM alleen mail raakt, legt een gebroken DNSSEC-keten je hele domein plat, inclusief website, MX-records en zelfs de SPF- en DKIM-records die je zojuist zo zorgvuldig had bijgewerkt. Meer achtergrond over de werking van deze beveiligingslaag staat in de Wikipedia-uitleg over DNSSEC.

Controleer daarom vóór je van DNS-provider wisselt of DNSSEC actief is bij je huidige registrar. Is dat het geval, schakel het dan tijdelijk uit vóór de overstap, of zorg dat de nieuwe DNS-provider de DS-record correct doorgeeft aan de registrar voordat je de nameservers wijzigt. Bij twijfel is tijdelijk uitschakelen het veiligste pad; je kunt DNSSEC na een geslaagde overstap altijd weer inschakelen.

# Checklist: DNS-records vergelijken voor en na de overstap

Elke DNS-record heeft een eigen functie en dus een eigen actiepunt bij een overstap; de tabel hieronder zet ze naast elkaar zodat je in één oogopslag ziet wat je moet wijzigen en wat er misgaat als je het vergeet. Gebruik deze checklist letterlijk als afvinklijst voordat je de knop omzet naar de nieuwe provider.

Bewaar ook een export van de huidige records voordat je iets wijzigt, bijvoorbeeld met een dig- of nslookup-commando per recordtype. Zo kun je bij problemen direct terug naar de oude configuratie in plaats van te moeten reconstrueren wat er ooit stond.

# Hoe voorkom je mail-uitval tijdens de overstap?

Mail-uitval tijdens een overstap voorkom je door de DNS-records in de juiste volgorde te wijzigen en pas MX om te zetten nadat SPF, DKIM en DMARC al bevestigd correct staan bij de nieuwe provider. De volledige stappen staan hieronder in het stappenplan, maar de kern is: eerst voorbereiden en testen, dan pas de daadwerkelijke overstap zichtbaar maken voor de buitenwereld.

Dit is ook precies waarom de kopieer-modus van mailmigreren.nl hier goed bij past: de mailbox-inhoud wordt via IMAP-APPEND naar de nieuwe provider gestreamd terwijl de bron intact blijft staan, dus je kunt de nieuwe mailbox rustig testen voordat je de MX-records en mail-authenticatie definitief omzet. Wachtwoorden blijven daarbij alleen in het werkgeheugen staan tijdens de migratie en worden nooit op schijf opgeslagen.

Zo hoef je niet in één avond zowel de e-mailinhoud te verhuizen als alle DNS-records tegelijk goed te krijgen: je knipt het probleem in tweeën. Eerst de data veilig kopiëren en controleren, dan pas, met een koel hoofd, de DNS-laag aanpassen. Start de migratie zodra je klaar bent om te beginnen.