Postvak overzetten: DNS-checklist voor MX, SPF en DKIM

Een postvak overzetten naar een nieuwe provider: DNS-checklist

Bij het overzetten van postvakgegevens bepaalt je DNS-strategie het verschil tussen een nette overgang en mogelijk 48 uur storing. Eén verkeerd ingestelde TTL of vergeten SPF-include kan harde bounces en omzetverlies veroorzaken.

Dit is geen creatieve oefening, maar een reeks nauwkeurige technische handelingen. Deze gids behandelt een veilige overdracht van postvakinhoud via propagatietimers, gecombineerde authenticatie met SPF, DKIM en DMARC, en routering naar de nieuwe provider met zo min mogelijk risico op gemiste berichten.

Lees voor de feitelijke gegevensoverdracht de volledige IMAP-synchronisatiegids.

Waarom DNS-propagatie niet direct is bij een postvakoverdracht

DNS is een gedistribueerd cachesysteem. Na een wijziging ben je afhankelijk van recursieve resolvers, zoals DNS-servers van internetproviders, Googles 8.8.8.8 en lokale routers, die de Time-To-Live (TTL) respecteren.

Staat de TTL op de gebruikelijke 86,400 seconden (24 uur), dan kan tijdens de overgang een dag lang gesplitste routering ontstaan. Een deel van de mail komt in het nieuwe postvak terecht en een deel in het oude.

De lange staart en negatieve caching

Twee minder zichtbare factoren verstoren regelmatig een postvakoverdracht:

• De lange staart: zelfs met een lage TTL negeert naar schatting 1-5% van de wereldwijde resolvers waarden onder 60 minuten. Houd ongeveer een uur na de overstap rekening met restverkeer naar de oude provider.
• Negatieve caching (SOA): vraag je een record op voordat het bestaat, bijvoorbeeld een nieuwe DKIM-selector, dan wordt het NXDOMAIN-antwoord bewaard volgens de minimale TTL van het SOA-record, vaak 1 uur. Daardoor kan het geldige record na publicatie nog tijdelijk onzichtbaar blijven.

Fase 1: aftellen vanaf 48 uur

Wijzig de MX-records nog niet. Bereid eerst de omgeving op de verandering voor.

Stap 1: TTL's verlagen (T-minus 48 uur)

Zoek de MX-, SPF- (TXT) en DMARC-records en verlaag hun TTL naar 300 seconden (5 minuten).

Dit verkort het beoogde propagatievenster van maximaal 24 uur. Het garandeert geen wereldwijde update binnen 5 minuten, omdat caches en resolvers zich verschillend kunnen gedragen.

Stap 2: SPF samenvoegen (T-minus 24 uur)

SPF (RFC 7208) machtigt IP-adressen om namens je domein te verzenden. Tijdens de overgang moeten beide providers tegelijk gemachtigd zijn.

De valkuil: SPF staat maximaal 10 DNS-zoekopdrachten toe. Twee providers combineren, bijvoorbeeld Google Workspace en TrekMail, kan die limiet overschrijden.

De oplossing: maak het record alleen vlakker met een ondersteunde werkwijze die gewijzigde adressen blijft bijwerken. Anders kunnen bij vervanging van geneste include:-vermeldingen door directe ip4:-mechanismen de adressen verouderd raken.

Voorbeeld van een overgangsrecord:

Gebruik je TrekMail BYO SMTP via Amazon SES of SendGrid, neem dan hun SPF-records op.

Stap 3: DKIM vooraf publiceren

DKIM gebruikt selectors, zoals google._domainkey. Maak bij de nieuwe provider DKIM-sleutels met een unieke selector, bijvoorbeeld tm1._domainkey. Gebruik een selectornaam nooit opnieuw. Een nieuwe selector kan dagen vooraf worden gepubliceerd zonder de oude provider te hinderen.

Stap 4: DMARC tijdelijk versoepelen

Staat DMARC op p=reject of p=quarantine, wijzig dit dan minstens 24 uur voor de overstap in p=none. In de eerste uren kunnen authenticatiefouten optreden. Met p=none worden fouten in RUA-rapporten vastgelegd zonder dat DMARC ze op basis van dit beleid afwijst; andere filters kunnen bezorging nog steeds beïnvloeden. De Google-handleiding voor DMARC legt de juiste configuratie uit.

Fase 2: de overstap uitvoeren

De TTL's zijn laag en de authenticatiegegevens zijn gecombineerd. Nu kan de routering naar de nieuwe host worden omgezet.

Stap 1: gezaghebbende en recursieve DNS vergelijken

Controleer eerst of de nieuwe records op de gezaghebbende naamserver zichtbaar zijn en kijk daarna pas naar openbare resolvers:

Stap 2: MX-records bijwerken

Voeg waar mogelijk eerst de nieuwe MX-records toe en controleer ze voordat je de oude verwijdert, of vervang alles in één wijziging. Voor TrekMail:

Laat de TTL op 300 seconden staan. Verhoog hem nog niet.

Stap 3: cache wissen en controleren

Wis je lokale DNS-cache met ipconfig /flushdns op Windows of sudo dscacheutil -flushcache op macOS. Voer dig opnieuw uit. Dit wist alleen de lokale cache en versnelt de update van externe resolvers niet.

Fase 3: stabiliseren na de overstap

Let op tenanttoewijzingsfouten (550 5.7.64)

Dit probleem komt voor bij overdracht naar Microsoft 365 en vergelijkbare pakketten. Als de bestemming je domein nog niet volledig in de interne directory heeft ingericht, kan mail worden geweigerd met Relay Access Denied. Controleer voor de MX-wijziging of de domeinstatus bij de nieuwe provider Verified of Healthy is.

DMARC-rapporten volgen (72 uur)

Volg de RUA-rapporten drie dagen:

• Succes: verkeer vanaf de IP-adressen van de nieuwe provider slaagt voor SPF en DKIM.
• Fout: legitiem verkeer van bijvoorbeeld facturerings- of marketingplatforms slaagt niet voor authenticatie. Werk SPF of DKIM direct bij.

Opschonen (T-plus 72 uur)

Zodra het verkeer stabiel is:

1. Verwijder de include: van de oude provider uit SPF nadat die provider niet meer verzendt.
2. Verwijder oude DKIM-records van het type CNAME/TXT na een veilige periode voor eerder ondertekende berichten.
3. Verhoog de TTL weer naar 3,600s (1 uur) of 86,400s (24 uur).
4. Handhaaf DMARC opnieuw met p=quarantine of p=reject.

De checklist voor postvakoverdracht in één oogopslag

TrekMail vereenvoudigt de postvakoverdracht

Handmatig DNS-beheer is foutgevoelig. Eén syntaxisfout in een TXT-record kan het volledige SPF-beleid ongeldig maken.

Voor kleine bedrijven

TrekMail biedt een actuele DNS-statuscontrole. Het dashboard vraagt de gezaghebbende naamservers op en controleert MX, SPF en DKIM-records aan de hand van de vereiste basiswaarden. Zo kunnen syntaxisfouten worden gemarkeerd voordat ze bounces veroorzaken, maar wereldwijde propagatie blijft afhankelijk van externe resolvers.

Lees meer over e-mail instellen op je eigen domein.

Voor bureaus

Het beheer van 50+ domeinen vraagt om standaardisatie. Met TrekMail pas je een consistente DNS-sjabloon toe op klantomgevingen. Bij Starter en Agency verzorgt Managed SMTP IP-reputatie en bezorgheaders, zodat voor die route geen complexe SPF-afvlakking of eigen IP-opwarmschema nodig is.

Bekijk hoe e-mailhosting voor meerdere domeinen werkt voor bureaus.

Alle betaalde abonnementen hebben een gratis proefperiode van 14 dagen, waarvoor een kaart vereist is. Voor Nano is geen kaart nodig.

Conclusie

Bij een overstap naar een nieuwe provider ontstaan problemen vaak tijdens de DNS-omschakeling. Verlaag de TTL's op tijd, combineer authenticatierecords, wijzig MX in een onderhoudsvenster en volg DMARC-rapporten 72 uur. Dat is de kern van het draaiboek.

Wil je het handmatige DNS-werk overslaan? Probeer TrekMail gratis en laat het dashboard de configuratie voor je controleren.