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

# Waarom vallen e-mails weg na een hosting-overstap?

E-mails vallen weg na een hosting-overstap omdat DNS-records als SPF, DKIM en DMARC zijn gekoppeld aan de mailinfrastructuur van je oude provider en niet automatisch meeverhuizen. Zodra je mailstroom via de nieuwe servers loopt maar de DNS-records nog naar de oude omgeving verwijzen, keuren ontvangende mailservers jouw berichten af als verdacht. Het resultaat is een '550 5.7.1'-bounce of een stille plaatsing in de spammap.

Het probleem is bijzonder onzichtbaar: tijdens een migratie is de aandacht gericht op de website, het CMS en de mailboxinhoud. DNS-beveiligingsrecords zijn geen standaard onderdeel van een migratiepakket. De meeste hostingproviders kopiëren de mailboxen maar laten de DNS-configuratie volledig aan jou over.

SPF, DKIM en DMARC werken alleen als ze zijn afgestemd op de mailserver die daadwerkelijk verstuurt. Verander je van mailserver, dan moeten ook deze records worden bijgewerkt. DNSSEC voegt hier een extra risico aan toe: een domeinoverdracht kan de DNSSEC-configuratie in een inconsistente staat achterlaten, waardoor het domein volledig onbereikbaar wordt voor validerende resolvers.

# Wat doen SPF, DKIM, DMARC en DNSSEC precies?

SPF (Sender Policy Framework) is een TXT-record in je DNS-zone dat vastlegt welke mailservers e-mail mogen versturen namens jouw domein. Een ontvangende server vergelijkt het IP-adres van de verstuurde server met de lijst in het SPF-record. Staat het adres er niet in, dan is de e-mail verdacht. SPF is gestandaardiseerd in RFC 7208.

DKIM (DomainKeys Identified Mail) voegt een cryptografische handtekening toe aan elke uitgaande e-mail. De bijbehorende publieke sleutel staat als TXT-record in je DNS. Klopt de handtekening niet met de sleutel, dan is de e-mail mogelijk gemanipuleerd of niet afkomstig van de genoemde afzender. DKIM-sleutels zijn provider-specifiek: elke mailprovider heeft zijn eigen privésleutel en bijbehorend DNS-record.

DMARC (Domain-based Message Authentication, Reporting and Conformance) verbindt SPF en DKIM met een beleid: wat moet er gebeuren als een e-mail beide checks niet doorstaat? De drie opties zijn <code>none</code> (alleen rapporteren), <code>quarantine</code> (naar spam) of <code>reject</code> (volledig weigeren). DMARC stuurt ook geaggregeerde rapportages naar een e-mailadres dat jij opgeeft.

DNSSEC (DNS Security Extensions) beveiligt de DNS-zone zelf door digitale handtekeningen toe te voegen aan DNS-antwoorden. Zo kunnen aanvallers geen nep-DNS-records injecteren via een DNS spoofing-aanval. DNSSEC is optioneel maar sterk aanbevolen voor domeinen die zakelijke e-mail verwerken.

# SPF aanpassen: welk IP-adres hoort er nu in?

Het SPF-record moet het include-mechanisme of het IP-adres van je nieuwe mailserver bevatten, anders faalt de SPF-check voor elke uitgaande e-mail. Een typisch record ziet er zo uit: <code>v=spf1 include:spf.nieuwehoster.nl ~all</code>. Het <code>include</code>-mechanisme verwijst naar de SPF-publicatie van je nieuwe provider, zodat al hun uitgaande mailservers automatisch zijn toegestaan.

Gebruik je naast je hosting-mail ook externe diensten voor nieuwsbrieven, CRM-mails of transactionele berichten, dan moeten die includes ook in het SPF-record staan. Let op de limiet van RFC 7208: maximaal 10 DNS-lookups per SPF-controle. Meer includes leiden tot een <code>PermError</code>, waardoor alle uitgaande e-mail van je domein als ongeldig wordt beschouwd, ook berichten die inhoudelijk correct zijn.

Verwijder het oude include-mechanisme van je vorige provider zodra de mailstroom volledig op de nieuwe provider draait. Twee TXT-records met <code>v=spf1</code> tegelijk is ongeldig: combineer altijd alle mechanismes in één SPF-regel.

• Vraag het juiste include-mechanisme op bij je nieuwe provider
• Vervang het oude include door het nieuwe in je SPF-record
• Tel het aantal DNS-lookups: blijf onder de 10
• Controleer of externe maildiensten ook zijn opgenomen
• Verwijder het oude include na bevestiging dat de nieuwe setup werkt

# DKIM opnieuw instellen: nieuwe sleutels bij nieuwe provider

DKIM-sleutels moeten altijd opnieuw worden aangemaakt bij je nieuwe mailprovider, want de privésleutel staat bij de provider en verhuist niet mee. Zodra je e-mail via de nieuwe servers verstuurd wordt terwijl het oude DKIM-record nog actief is, faalt de handtekeningverificatie en markeren ontvangende servers je berichten als verdacht.

De procedure is als volgt: je nieuwe provider genereert een sleutelpaar. De privésleutel slaat de provider op in hun mailinfrastructuur. De publieke sleutel krijg jij als TXT-record dat je zelf in de DNS-zone plaatst. Het record heeft de vorm: <code>mail._domainkey.jouwdomein.nl</code> met als waarde <code>v=DKIM1; k=rsa; p=MIIBIjAN...</code>.

Gebruik minimaal 2048-bit RSA-sleutels. Zowel Google als Microsoft beschouwen 1024-bit sleutels als onveilig en dit kan leiden tot stille afwijzing van je berichten. Kies een herkenbare selectornaam, zoals <code>mail2024</code> of de naam van de provider, zodat je later eenvoudig kunt achterhalen welk record bij welke omgeving hoort. Verwijder het oude DKIM-record pas nadat je met een testmail hebt bevestigd dat de nieuwe setup correct functioneert.

# DMARC: wat als je het niet aanpast na de migratie?

Een onjuist DMARC-record na een migratie is het meest ingrijpende scenario: staat de policy op <code>reject</code> terwijl SPF of DKIM nog niet goed zijn ingesteld op de nieuwe provider, dan worden al je uitgaande e-mails gebounced, inclusief antwoorden op klantvragen en orderbevestigingen.

Het DMARC-record zelf hoeft niet altijd inhoudelijk te veranderen, maar moet worden gecontroleerd. Staat er <code>p=none</code>, dan loopt e-mail door maar ontvang je rapportages over falende checks. Staat er <code>p=quarantine</code> of <code>p=reject</code>, dan betaal je direct de prijs voor elke SPF- of DKIM-mismatch.

Aanbevolen aanpak tijdens een migratie: zet DMARC tijdelijk op <code>p=none</code> en voeg een <code>rua</code>-tag toe met een e-mailadres voor rapportages. Controleer na 48 tot 72 uur de rapportages. Tonen die <code>spf=pass</code> en <code>dkim=pass</code> voor jouw eigen mailstroom, zet de policy dan terug naar <code>quarantine</code> of <code>reject</code>. Controleer ook of het rapportage-adres in de <code>rua</code>-tag bereikbaar is na de migratie: een ongeldig adres levert geen rapporten op en blinde vlekken in je beveiliging.

# DNSSEC: uitgeschakeld of kapot na een domeinoverdracht

DNSSEC is de meest over het hoofd geziene instelling bij een hosting- of domeinoverstap. Bij een domeinoverdracht naar een andere registrar worden de DS-records (Delegation Signer) vaak verwijderd of komen ze in een inconsistente staat terecht. Een domein met kapotte DNSSEC-configuratie is voor validerende DNS-resolvers volledig onbereikbaar: e-mail werkt niet, de website is niet te bereiken en er zijn geen foutmeldingen die de oorzaak direct aanwijzen.

De juiste werkwijze: schakel DNSSEC uit bij de huidige registrar voordat je het domein overdraagt. Wacht tot de TTL van de DS-records is verstreken zodat de wijziging wereldwijd is doorgevoerd. Pas daarna start je de domeinoverdracht. Nadat het domein stabiel staat bij de nieuwe registrar en de DNS-zone volledig is geconfigureerd, schakel je DNSSEC opnieuw in.

Niet alle Nederlandse hostingproviders ondersteunen DNSSEC voor alle TLD's. Voor .nl-domeinen controleer je dit via SIDN. Ondersteunt je nieuwe provider geen DNSSEC voor jouw TLD, laat het dan uitgeschakeld totdat je een provider hebt die het wel aanbiedt: een ontbrekend DNSSEC is veiliger dan een kapotte configuratie.

# Overzicht: welke DNS-records moeten worden aangepast bij een hosting-overstap?

# Mailboxinhoud migreren en DNS regelen: twee aparte stappen

De volgorde van acties bepaalt hoeveel downtime je ervaart. Verlaag de TTL van alle kritieke records (MX, SPF, DKIM, DMARC) minimaal 24 uur voor de migratie naar 300 seconden. Zo propageren wijzigingen na de overstap binnen enkele minuten in plaats van uren.

Draai na de migratie een verificatietest via MXToolbox of mail-tester.com: controleer de MX-, SPF-, DKIM- en DMARC-records in één overzicht. Stuur daarna testmails naar een Gmail- en een Outlook-adres en bekijk de e-mailheaders op <code>Authentication-Results</code>: staan daar <code>spf=pass</code>, <code>dkim=pass</code> en <code>dmarc=pass</code>, dan is de configuratie correct.

Migratietools zoals mailmigreren.nl verplaatsen de inhoud van je mailboxen via IMAP-APPEND van de oude naar de nieuwe server, onafhankelijk van de DNS-configuratie. De migratie kan starten terwijl de DNS-records nog wijzen naar de oude server: mailboxinhoud en DNS zijn twee aparte onderdelen van een e-mailmigratie. Gebruik de migratiestarter op mailmigreren.nl voor de mailboxinhoud en deze checklist voor de DNS-records.