DNSSEC, SPF, DKIM, DMARC: checklist voor hosting-overstap

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

Je mail valt weg of belandt in spam zodra SPF, DKIM of DMARC na een hosting-overstap niet meer kloppen met de servers die daadwerkelijk namens jouw domein verzenden. Ontvangende mailservers van Gmail, Outlook en Ziggo controleren bij elk binnenkomend bericht of de verzendende server overeenkomt met wat er in je DNS staat; wijkt dat af, dan wordt het bericht geweigerd of gemarkeerd als verdacht.

Dit risico ontstaat niet omdat je iets fout doet tijdens het overstappen zelf, maar omdat hosting-overstappen vaak twee dingen tegelijk veranderen: de mailserver die uitgaande post verstuurt, en soms ook de naamserver die je DNS-records beheert. Beide veranderingen raken direct aan de vier technieken die samen bepalen of jouw e-mail als betrouwbaar geldt: SPF, DKIM, DMARC en DNSSEC.

Het goede nieuws: geen van deze vier hoeft ingewikkeld te zijn als je weet welk record waar staat en in welke volgorde je moet wijzigen. De rest van dit artikel behandelt elk record apart, met een concreet stappenplan aan het eind.

# Wat is SPF en waarom breekt een hosting-overstap dit record?

SPF (Sender Policy Framework) is een TXT-record in je DNS dat exact vermeldt welke mailservers namens jouw domein e-mail mogen versturen; staat de nieuwe hostingpartij niet in dat lijstje, dan wordt mail die via hun server verstuurd wordt als vervalst beschouwd. Het record is gestandaardiseerd in RFC 7208 en ziet er in de praktijk uit als 'v=spf1 include:_spf.oudeprovider.nl -all'.

Bij een hosting-overstap breekt SPF omdat je e-mail straks via een andere server buiten je domein verstuurt, terwijl het bestaande record alleen de oude server toestaat. Vergeet je dit aan te passen, dan krijg je typisch een bounce-bericht met 'SPF check failed' of ziet de ontvanger je bericht simpelweg niet terug.

Een veelgemaakte fout is het stapelen van meerdere include-mechanismen zonder de oude te verwijderen. SPF staat maximaal 10 DNS-lookups toe; overschrijd je dat aantal, dan negeren ontvangende servers het hele record met een permerror, ook als de inhoud verder correct is. Verwijder daarom oude includes zodra de overstap is afgerond, in plaats van ze te laten liggen.

# Wat is DKIM en hoe verhuis je de sleutel mee naar de nieuwe host?

DKIM (DomainKeys Identified Mail) plaatst een digitale handtekening onder elke uitgaande e-mail, waarvan de bijbehorende publieke sleutel als TXT-record in je DNS staat onder een selector zoals 'selector1._domainkey.jouwdomein.nl'. Die sleutel is gekoppeld aan de mailserver die de handtekening zet, dus een nieuwe hostingpartij genereert altijd een nieuw sleutelpaar.

Het gevolg: de oude DKIM-sleutel werkt niet meer zodra je bij de nieuwe provider verstuurt, want die ondertekent met een andere private key. Publiceer de nieuwe publieke sleutel dus vóórdat je daadwerkelijk mail via de nieuwe server laat versturen, anders faalt de DKIM-validatie en daalt je afzenderreputatie bij grote mailproviders.

Laat tijdens de overgangsperiode gerust beide selectors naast elkaar staan; een domein mag onbeperkt DKIM-selectors hebben. Zo blijft mail die nog via de oude server vertrekt geldig ondertekend, terwijl mail via de nieuwe server ook al correct valideert. Kies bij het aanmaken van de nieuwe sleutel voor minimaal 2048-bit RSA; 1024-bit sleutels worden door een groeiend aantal providers niet langer geaccepteerd.

# Wat is DMARC en welke instelling voorkomt mailverlies tijdens de overstap?

DMARC (Domain-based Message Authentication, Reporting and Conformance) bouwt voort op SPF en DKIM en bepaalt wat een ontvangende server moet doen als een bericht een van beide checks niet doorstaat: negeren, in quarantaine plaatsen, of volledig weigeren. Het beleid staat, net als SPF, als TXT-record in je DNS en is vastgelegd in RFC 7489.

Tijdens een hosting-overstap is DMARC het record dat de schade bepaalt als SPF of DKIM tijdelijk niet kloppen. Staat je beleid op p=reject, dan verdwijnt mail die de checks niet doorstaat zonder waarschuwing. Zet je DMARC-record daarom tijdelijk op p=none zodra je aan de overstap begint; dan ontvang je nog steeds rapportages over mislukte checks, maar wordt er geen mail geweigerd terwijl je SPF en DKIM aan het bijwerken bent.

Zodra je hebt geverifieerd dat SPF en DKIM voor de nieuwe server correct valideren, meestal na vijf tot zeven dagen zonder foutmeldingen in de DMARC-rapportages, zet je het beleid terug naar p=quarantine of p=reject. Grote mailproviders eisen sinds 1 februari 2024 dat afzenders van meer dan 5000 e-mails per dag over geldige SPF, DKIM en DMARC beschikken, zoals beschreven in de officiële afzenderrichtlijnen van Google.

# Wat is DNSSEC en wanneer wordt dit een risico bij een overstap?

DNSSEC (Domain Name System Security Extensions) ondertekent je DNS-records cryptografisch, zodat een ontvangende server kan verifiëren dat een DNS-antwoord echt van jouw domein komt en niet onderweg is vervalst. Anders dan SPF, DKIM en DMARC gaat DNSSEC niet over de inhoud van je mailbeleid, maar over de betrouwbaarheid van de DNS-records zelf, inclusief die SPF-, DKIM- en DMARC-records. Meer achtergrond staat op Wikipedia.

DNSSEC wordt pas een risico als je bij de hosting-overstap ook van DNS-provider wisselt, niet wanneer je alleen van mailhost verandert. Verhuis je de DNS-zone naar een nieuwe naamserver zonder de DNSSEC-ondertekening correct over te zetten, dan raakt de keten van vertrouwen tussen je domein en het bovenliggende topleveldomein onderbroken. Validerende resolvers verwerpen dan al je DNS-antwoorden, inclusief het gloednieuwe SPF- of DKIM-record dat je net had gepubliceerd, en je mail valt volledig stil.

Blijft je DNS bij dezelfde partij staan en verhuis je alleen de mailbox, dan hoef je niets aan DNSSEC te doen. Wissel je wel van DNS-provider, schakel DNSSEC dan tijdelijk uit bij de oude provider, migreer de records, en schakel het pas weer in zodra de nieuwe DS-records bij je domeinregistrar staan.

# Welke DNS-records controleer je voor, tijdens en na de overstap?

Vier records verdienen controle bij elke hosting-overstap: MX, SPF, DKIM en DMARC, plus DNSSEC als ook je DNS-provider wijzigt. De tabel hieronder zet per record neer wat het doel is en wat er misgaat als je het vergeet.

Bewaar een kopie van alle bestaande records voordat je begint. De meeste hostingpanelen, waaronder die van Strato, Hostnet en TransIP, tonen je huidige DNS-zone in een overzicht dat je simpelweg kunt exporteren of overtypen. Zonder die back-up moet je bij problemen gissen naar wat er vóór de overstap stond.

# Hoe migreer je DNS-records veilig zonder mail te verliezen?

Een hosting-overstap zonder mailuitval volgt een vaste volgorde: eerst voorbereiden, dan parallel laten draaien, en pas als laatste omschakelen. Het stappenplan hieronder houdt bron en bestemming tijdens de hele overgang bereikbaar, in plaats van dat je in één klap alles ineens omzet.

Bij mailmigreren.nl gebruiken we bewust een kopieer-modus waarbij de bron blijft staan tijdens het overzetten van de mailbox-inhoud zelf; dat betekent dat je MX-record pas hoeft te wijzigen op het moment dat je er klaar voor bent, in plaats van dat je gedwongen wordt alles tegelijk om te zetten. Dat scheelt een risicovolle stap in het proces.

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

Test SPF, DKIM en DMARC altijd voordat je het definitief loslaat, door een testmail te sturen naar een adres bij Gmail of Outlook en de header-informatie te bekijken; daar staat expliciet of SPF, DKIM en DMARC zijn geslaagd ('pass') of gefaald ('fail'). Beide grote mailproviders tonen deze authenticatie-resultaten in de uitgebreide berichtheader onder 'Authentication-Results'.

Vraag daarnaast om DMARC-rapportages door een rua-adres, bijvoorbeeld rua=mailto:dmarc-rapporten@jouwdomein.nl, in je DMARC-record op te nemen. Grote providers sturen dagelijks een samengevat rapport terug met welk percentage van je mail SPF en DKIM doorstaat, uitgesplitst per verzendende server. Zo zie je zwart op wit of de oude hostingpartij nog mail verstuurt die niet meer geautoriseerd is, een teken dat er ergens nog een wachtende taak, formulier of nieuwsbrief-tool met de oude instellingen verzendt.

Bewaar deze controle minimaal twee tot vier weken na de overstap. Sommige geautomatiseerde processen, zoals factuursystemen of CRM-koppelingen, versturen mail slechts eens per maand en komen pas dan aan het licht als de oude verzendserver niet langer in je SPF-record staat.