E-mail na een verhuizing: SPF, DKIM en DMARC stap voor stap

Na een verhuizing moeten je MX-record, SPF-record, DKIM-sleutel en DMARC-beleid kloppen met de nieuwe situatie, anders bereikt binnenkomende mail je mailbox niet of komt verzonden mail bij een strenger DMARC-beleid niet in de inbox van ontvangers die DMARC toepassen. Het MX-record bepaalt waar binnenkomende mail naartoe gaat. SPF, DKIM en DMARC bepalen hoe ontvangers controleren of verzonden mail echt van jouw domein komt. Dit artikel legt uit wat elk record doet volgens de RFC's, welke DMARC-standaard per 11 oktober 2026 geldt en hoe je na de overstap controleert dat alles werkt.

Wat doet het MX-record bij een verhuizing?

Begin bij de vraag waar je mail eigenlijk staat. Een website verhuizen is niet hetzelfde als een mailbox verhuizen. Volgens RFC 1034 identificeert een MX-record een mail exchange voor het domein, en RFC 1035 omschrijft die als een host die bereid is als mail exchange voor de naam op te treden. Je website kan dus op de ene plek staan en je mail op een andere. Verhuis je alleen de website, dan blijft je MX-record bij voorkeur ongemoeid. Verhuis je ook je mailboxen, dan wijst het MX-record straks naar de nieuwe mailserver en moet je weten wanneer die omzetting plaatsvindt.

Een groot risico zit niet in het MX-record zelf, maar in wat eromheen gebeurt. Worden bij een verhuizing alle DNS-records van je domein vervangen door een nieuwe set standaardrecords, dan kan je MX-record verdwijnen, en met dat record je SPF-, DKIM- en DMARC-gegevens. Maak daarom voor je iets verandert een kopie van alle bestaande records, inclusief de TXT-records. Hoe die records in elkaar zitten staat in DNS uitgelegd voor ondernemers. Met die kopie kun je elk record na de overstap vergelijken met de oude situatie.

Wat doet SPF?

SPF is het eenvoudigste van de drie. RFC 7208 beschrijft SPF versie 1 als een mechanisme waarmee domeinbeheerders expliciet de hosts kunnen autoriseren die hun domeinnaam mogen gebruiken, en waarmee een ontvangende partij die autorisatie kan controleren. Je geeft dus aan welke servers namens je domein mogen mailen. Een SPF-record moet volgens dezelfde RFC uitsluitend als DNS TXT-record worden gepubliceerd, het recordtype met nummer 16. Controleer dus bij je DNS-beheerder dat je het record als TXT hebt aangemaakt.

Bij een verhuizing kan veranderen welke servers jouw mail versturen. Voeg de nieuwe verzender toe aan je SPF-record, en haal een oude verzender pas weg als je zeker weet dat die niet meer mailt namens jouw domein. Let op twee regels uit RFC 7208. Een domeinnaam mag niet meerdere records hebben die ertoe leiden dat de controle twee of meer records selecteert, dus je plaatst geen tweede SPF-record maar breidt het bestaande uit. En een SPF-evaluatie mag maximaal tien DNS-opzoekende termen gebruiken, anders is het resultaat permerror. Elke dienst die je toevoegt kan meetellen.

Wat doet DKIM?

DKIM werkt met een handtekening. Volgens RFC 6376 laat DomainKeys Identified Mail de eigenaar van het ondertekenende domein verantwoordelijkheid voor een bericht claimen door het domein aan het bericht te koppelen. De ontvanger valideert dat met een cryptografische handtekening en de publieke sleutel die hij bij het domein van de ondertekenaar opvraagt. Het verzendende systeem tekent dus elk bericht met een geheime sleutel, en de bijbehorende publieke sleutel staat in jouw domeingegevens. Klopt de sleutel niet, dan valt de controle om.

Wat volgt is ons advies voor een overstap, geen voorschrift uit RFC 6376. Een nieuwe mailprovider werkt met een eigen sleutel, en je provider geeft je het record dat je moet plaatsen. Zet dat record eerst op zijn plek, en schakel pas daarna het ondertekenen door de nieuwe provider in. Verwijder de oude sleutel niet op hetzelfde moment, maar wacht tot je zeker weet dat er geen berichten meer onderweg zijn die ermee zijn ondertekend. Omdat de controle volgens RFC 6376 bij de ontvanger plaatsvindt, die de publieke sleutel bij jouw domein opvraagt, zie je een fout in het record niet vanzelf aan je eigen kant. Controleer het daarom na het plaatsen.

Wat doet DMARC, en welke standaard geldt nu?

DMARC bouwt op SPF en DKIM voort. Het beleid wordt volgens RFC 9989 gepubliceerd als DNS TXT-record op een naam die begint met het label _dmarc. Een DMARC-pass vereist niet alleen een SPF- of DKIM-pass, maar ook dat het domein dat bij die pass hoort aligned is met het afzenderdomein. Daardoor kan een bericht bij DMARC falen terwijl SPF of DKIM wel slaagt: een dienst die namens jou mailt maar de controle op zijn eigen domein laat slagen, is dan niet aligned met jouw afzenderdomein. Controleer dus ook die verzenders.

Welke standaard geldt nu? Per 11 oktober 2026 is DMARC gedefinieerd in RFC 9989, een Standards Track-document dat volgens de RFC-Editor is gepubliceerd in mei 2026. Het vervangt RFC 7489 en RFC 9091. De RFC-Editor markeert RFC 7489 inmiddels als obsolete, met RFC 9989, RFC 9990 en RFC 9991 als opvolgers. Handleidingen die vóór mei 2026 zijn geschreven, kunnen nog naar de oude standaard verwijzen. Controleer daarom bij elke bron of die RFC 9989 volgt en let op datums bij stappenplannen.

Het DMARC-beleid kent drie standen. Bij none spreekt de domeineigenaar geen voorkeur uit. Bij quarantine beschouwt de eigenaar de mail als verdacht. Bij reject beschouwt de eigenaar alle falende berichten als een duidelijke aanwijzing dat het gebruik van de domeinnaam niet geldig is. Volgens RFC 9989 bereiken berichten van domeinen met beleid quarantine of reject die niet via DMARC valideren de inbox niet bij ontvangers die DMARC toepassen. Ons advies, geen eis uit RFC 9989: begin na een verhuizing met none en verscherp pas als je zeker weet dat al je legitieme mail slaagt.

Hoe test je je e-mail na de verhuizing?

Test je mail op meerdere manieren, op meerdere momenten. Stuur een testbericht naar een extern adres bij een andere provider dan de jouwe en bekijk in de berichtdetails of SPF en DKIM als geslaagd staan en of het afzenderdomein bij die controles past. Stuur ook een bericht van een extern adres naar jouw adres om te bevestigen dat het MX-record werkt. Test elke dienst die namens jou mailt: het contactformulier van je website, de nieuwsbrief, de facturatie. Elk van die systemen kan via een eigen route versturen en dus apart falen.

Houd rekening met caching. TTL geeft volgens MDN aan hoeveel seconden een antwoord bewaard mag worden. Na een wijziging kan de ene ontvanger je nieuwe MX nog niet kennen terwijl een andere hem al gebruikt. Verlaag de TTL dus ruim voor de verhuizing, wacht tot de oude waarde is verlopen en doe dan pas de wijziging. Laat de oude mailserver nog een tijd bereikbaar, zodat berichten die nog naar het oude adres onderweg zijn niet verloren gaan. Volg dit stap voor stap in de checklist voor een website-verhuizing.

Ons advies voor de volgorde aan de mailkant van een overstap is deze. Maak een kopie van de bestaande zone. Verlaag de TTL. Plaats de nieuwe SPF- en DKIM-gegevens naast de oude. Zet het MX-record om op het afgesproken moment. Test binnenkomende en uitgaande mail. Laat het DMARC-beleid op none staan tot je alles hebt gecontroleerd. Pas daarna verscherp je het beleid en ruim je oude gegevens op. Werk je met een bureau, leg dan vooraf vast wie welke stap uitvoert en wie de inlog van de DNS-beheerder heeft.

Wil je dat iemand dit voor je uitvoert, dan hoort de mailkant bij een goede website-migratie. Digitaalnu verhuist websites vanaf €250 per migratie. Draait je mail na een overstap toch niet goed, dan kijkt WordPress-hulp mee, vanaf €95 per storing. Nog een stap eerder zit de vraag wie je domein bezit. Daarover lees je in weg bij je webbureau.

Laatst bijgewerkt op 11 oktober 2026