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

# Wat gebeurt er met je e-mailrecords bij een hosting overstap?

SPF, DKIM, DMARC en DNSSEC worden nooit automatisch meeverhuisd bij een hosting overstap: elk van deze vier DNS-records staat vast gekoppeld aan je huidige nameservers en moet je zelf opnieuw aanmaken bij je nieuwe provider. Vergeet je er een, dan stopt je mail meestal niet meteen volledig, maar zetten ontvangende servers zoals Gmail en Outlook je berichten stiller weg: in de spamfolder, of helemaal niet afgeleverd.

De meeste aandacht bij een overstap gaat naar de MX-record, want zonder een juiste MX-record komt er inderdaad geen mail meer binnen. Maar SPF, DKIM en DMARC bepalen of je uitgaande mail wordt vertrouwd, en DNSSEC bepaalt of je domein an sich nog wel bereikbaar is. Samen vormen ze de technische basis waarop je mailverkeer draait.

Mailmigreren.nl kopieert je bestaande e-mails 1-op-1 over via IMAP-APPEND, met je bron-mailbox intact als back-up, maar de DNS-kant, SPF, DKIM, DMARC, MX en DNSSEC, regel je zelf bij je (nieuwe) hostingprovider. Dat overzicht geeft deze checklist je.

# Wat is SPF en welk record moet je overzetten?

SPF (Sender Policy Framework) is een TXT-record in je DNS dat vastlegt welke mailservers namens jouw domein e-mail mogen versturen; publiceer je dit record niet opnieuw bij je nieuwe provider, dan behandelen ontvangende servers al je uitgaande mail als mogelijk vervalst. Het record staat beschreven in RFC 7208 en bestaat uit een reeks mechanismen die bepalen wie mag versturen.

Een typisch SPF-record ziet er zo uit: v=spf1 include:_spf.jouwprovider.nl ~all. Het include-mechanisme verwijst naar de mailserver van je provider; verhuis je naar een andere provider, dan moet dat include-domein mee veranderen, anders blijft het record verwijzen naar een server die niet meer voor jou mailt.

Let op de limiet van maximaal 10 DNS-lookups per SPF-record: stapel je te veel include-mechanismen op elkaar, bijvoorbeeld omdat je zowel de oude als de nieuwe provider tijdelijk laat meelopen, dan levert dat een permerror op en faalt de SPF-check voor al je mail, ook voor berichten die verder wel kloppen.

• a: staat toe dat het A-record van het domein zelf mag versturen
• mx: staat toe dat de MX-servers van het domein mogen versturen
• include: verwijst naar het SPF-record van een andere partij, zoals je hostingprovider
• ~all: softfail, verdachte afzenders worden gemarkeerd maar niet geweigerd
• -all: hardfail, afzenders buiten de lijst worden geweigerd

# Wat is DKIM en waarom faalt dit record vaak na een overstap?

DKIM (DomainKeys Identified Mail) voegt een cryptografische handtekening toe aan elke uitgaande e-mail met een privésleutel die op de mailserver van je provider staat; verhuis je naar een nieuwe provider zonder een nieuwe DKIM-sleutel te publiceren, dan mist de bijbehorende publieke sleutel in je DNS en faalt de handtekening-check volledig.

Elke hostingprovider genereert zijn eigen sleutelpaar, dus een DKIM-sleutel van je oude provider werkt nooit bij je nieuwe provider: je moet bij de nieuwe host een nieuwe sleutel laten genereren en het bijbehorende TXT-record publiceren onder een naam als selector._domainkey.jouwdomein.nl.

Omdat elke selector een eigen naam heeft, kun je tijdens de overstap gerust de oude en nieuwe DKIM-selector naast elkaar laten bestaan: de oude blijft geldig voor mail die nog via de oude server verstuurd wordt, de nieuwe wordt actief zodra je daadwerkelijk overstapt. Zo ontstaat er geen gat waarin helemaal geen mail ondertekend wordt.

# Wat is DMARC en wat doet dit record tijdens de overstap?

DMARC (Domain-based Message Authentication, Reporting and Conformance) vertelt ontvangende mailservers wat ze moeten doen als een bericht niet slaagt voor SPF of DKIM, via een beleid van p=none, p=quarantine of p=reject; dat beleid blijft actief tijdens je hele overstap, ook op momenten dat je SPF- of DKIM-record tijdelijk niet klopt.

Staat je DMARC-beleid op p=reject en klopt je nieuwe SPF- of DKIM-record even niet, dan weigeren grote mailproviders je bericht direct, zonder een bounce-melding die je snel opvalt. Zet je beleid daarom tijdelijk op p=none zodra je aan de DNS-kant gaat sleutelen, en herstel het pas zodra je hebt geverifieerd dat alles klopt.

Sinds februari 2024 eisen Google en Yahoo geldige SPF, DKIM en DMARC van elke afzender die meer dan 5.000 e-mails per dag verstuurt. Voor kleinere mkb-verzenders is dat zelden een probleem, maar het laat zien hoe zwaar grote mailboxproviders inmiddels leunen op deze drie records bij het bepalen of mail wordt afgeleverd.

# Hoe verschillen SPF, DKIM, DMARC en DNSSEC van elkaar?

SPF controleert wie mag versturen, DKIM controleert of een bericht onderweg niet is aangepast, DMARC bepaalt wat er gebeurt als een van beide checks faalt, en DNSSEC beveiligt de DNS-antwoorden zelf tegen vervalsing; de eerste drie gaan dus over je mail, de laatste gaat over je hele domein.

Dat laatste maakt DNSSEC bijzonder: een fout in SPF of DKIM raakt alleen je e-mail, maar een fout in DNSSEC tijdens een overstap kan je hele domein onbereikbaar maken, website en mail inbegrepen. De tabel hieronder zet de vier naast elkaar.

Voor een gewone hosting overstap zijn SPF, DKIM en DMARC de records waar je actief iets voor moet doen; DNSSEC vraagt vooral om voorzichtigheid: niet vergeten, en met beleid aanpassen, zoals verderop in dit artikel staat.

# Wat vergeet bijna iedereen bij een hosting overstap?

De meestgemaakte fout bij een hosting overstap is dat SPF, DKIM en DMARC pas ná de MX-omzetting worden aangepast in plaats van ervoor, waardoor er een gat ontstaat waarin mail bounces of in spam belandt terwijl de oorzaak niet meteen duidelijk is.

Vergeet daarnaast niet de out-of-office-instellingen, e-mailfilters en gedeelde mailboxen op de oude server te controleren: die worden door geen enkele DNS-wijziging automatisch meegenomen en moet je, net als de mailinhoud zelf, apart migreren of opnieuw instellen.

• MX-record pas als laatste wijzigen, DNS eerst volledig voorbereiden
• SPF-record van de nieuwe provider toevoegen vóór de daadwerkelijke overstap
• Nieuwe DKIM-sleutel genereren en publiceren bij de nieuwe host
• DMARC-beleid tijdelijk verzachten naar p=none tijdens de overstap
• DNSSEC DS-record bijwerken bij de registrar als je van nameserver wisselt
• TTL van alle records 24-48 uur vooraf verlagen naar 300 seconden
• Out-of-office, filters en gedeelde mailboxen op de oude server controleren

# Hoe voorkom je dat DNSSEC je domein onbereikbaar maakt bij een overstap?

DNSSEC maakt je hele domein onbereikbaar, mail incluis, zodra de DS-record bij je registrar niet meer overeenkomt met de DNSKEY van je nieuwe nameservers; schakel DNSSEC daarom tijdelijk uit bij de registrar vlak vóór je van nameserver wisselt, en activeer het pas weer zodra de nieuwe keten geverifieerd is. Meer over de werking van deze beveiligingslaag staat op Wikipedia.

DNSSEC bouwt een keten van vertrouwen op tussen het topleveldomein en jouw nameservers via cryptografische handtekeningen; klopt een schakel in die keten niet, dan geven resolvers die DNSSEC valideren een SERVFAIL terug voor je hele domein, niet alleen voor mail.

Werk je met een provider die DNSSEC automatisch beheert, controleer dan vóór de overstap of de nieuwe provider dat ook doet en of de registrar de nieuwe DS-record automatisch overneemt; is dat niet het geval, doe die stap dan handmatig zodra de nieuwe nameservers actief zijn.

# Hoe test je of SPF, DKIM en DMARC goed staan na de overstap?

De snelste manier om te testen of SPF, DKIM en DMARC goed staan, is een e-mail sturen naar een Gmail-adres en daar via 'Bericht origineel weergeven' de Authentication-Results-header bekijken: staat er spf=pass, dkim=pass en dmarc=pass, dan is de configuratie correct.

Voor Microsoft 365 geldt hetzelfde principe via de header-analyse in Outlook; Microsoft's officiële documentatie over e-mailauthenticatie laat precies zien hoe je die header leest en welke waarden je moet zoeken.

Wacht met concluderen dat iets fout staat tot minstens enkele uren, en in het slechtste geval 48 uur, na de wijziging: DNS-propagatie verloopt niet overal even snel, en een resolver die nog de oude waarde cachet geeft je een vals negatief resultaat.