Snel antwoord
Hoe verhuis ik e-mail naar een nieuwe provider zonder e-mail te verliezen?
Verlaag de TTL van uw MX-records 24 tot 48 uur van tevoren naar 300 tot 600 seconden, importeer het oude archief in de nieuwe mailbox, wijzig de MX-records als laatste en houd het oude account totdat de nieuwe e-mail is aangekomen. Postelva host de DNS, dus de overstap is één wijziging in twee of meer records.
Hoeveel records er wijzigen als u overstapt
| Nieuwe aanbieder | MX | Verificatie-TXT | SPF | DKIM | DMARC | Records in totaal |
|---|---|---|---|---|---|---|
| Proton Mail | 2 | 1 | 1 include | 3 CNAME | 1 | 8 |
| Mailbox.org | 4 | 1 | 1 include | 4 CNAME | 1 | 11 |
| Fastmail | 2 | Niet vereist voor een opzet met alleen MX | 1 include | 3 CNAME | Niet gelezen (niet geverifieerd) | 6, zonder DMARC |
Vijf stappen in de juiste volgorde
Verlaag de TTL
Stel minstens 24 tot 48 uur vóór de overstap de TTL van de MX-records in op 300 tot 600 seconden. Een wijziging verspreidt zich in ongeveer de oude TTL, dus een korte waarde vóór de wijziging maakt de wijziging snel.
Bereid de nieuwe mailbox voor
Voeg uw domein toe bij de nieuwe aanbieder, maak de adressen en aliassen aan en kopieer het verificatierecord dat wordt getoond. Raak de MX-records nog niet aan.
Kopieer de oude e-mail
Importeer het archief met de IMAP-importtool van de nieuwe aanbieder terwijl het oude account nog e-mail ontvangt. Doorsturen alleen verplaatst enkel nieuwe e-mail.
Schakel de MX-records om
Vervang de oude MX-records door de nieuwe, voeg de nieuwe SPF-include toe aan het bestaande SPF-record en voeg de DKIM-records toe. Laat de oude server e-mail accepteren totdat de oude TTL is verstreken.
Bevestig en ruim daarna op
Stuur uzelf een test vanaf twee externe accounts, controleer de headers, houd het oude account nog even aan, verhoog daarna de TTL weer en verwijder de oude records.
Waarom bepaalt de TTL of er e-mail verloren gaat?
De TTL is het aantal seconden dat een resolver een antwoord mag bewaren, dus hij bepaalt hoe lang afzenders uw oude MX-records blijven gebruiken. Als de oude TTL 86400 seconden is, blijft een afzender die u één minuut vóór de wijziging heeft opgezocht tot een dag lang bezorgen op de oude server. Met een TTL van 300 tot 600 seconden is dat venster vijf tot tien minuten.
De regel uit de gidsen over bezorgbaarheid is om de TTL 24 tot 48 uur vóór de overstap te verlagen, zodat elke cache op de dag zelf al de korte waarde bevat, en hem daarna weer te verhogen. Een gewone MX-wijziging is dan na 1 tot 4 uur doorgevoerd en kan in het slechtste geval 24 tot 48 uur duren. Dit is advies van leveranciers, geen standaard. Ook lege antwoorden worden gecachet, met de TTL van het SOA-record van de zone (RFC 2308), dus een record dat u laat aanmaakt kan bij sommige resolvers nog een tijdje onzichtbaar blijven.
Hoe kopieer ik mijn oude e-mail vóór de overstap?
Importeer het oude archief via IMAP voordat u ook maar één MX-record wijzigt. Proton Mail documenteert bijvoorbeeld een overstap van Gmail met een importtool, en de adviezen in de migratiegidsen van aanbieders komen op dezelfde volgorde neer: eerst importeren, de MX pas wijzigen als de bestemming klaar is, en het oude account houden totdat u hebt bevestigd dat alles is aangekomen.
Twee gewoonten voorkomen de meeste verliezen. Zorg er ten eerste voor dat de oude mailbox e-mail blijft ontvangen terwijl de import loopt, want e-mail die tijdens het kopiëren binnenkomt, staat alleen in het oude account. Voer ten tweede na de MX-overstap een tweede, korte import uit om de berichten op te halen die tijdens de verspreiding op de oude server zijn beland. Voor de volgorde van werken als uw adres van aanbieder verandert maar niet van naam, leest u hoe u uw e-mailadres behoudt als u van aanbieder wisselt.
Hoe wijzig ik de MX-records veilig?
Verwijder de oude MX-records of geef de nieuwe het laagste prioriteitsnummer, en laat nooit twee aanbieders door elkaar staan. Fastmail en Proton Mail zeggen dit allebei op hun helppagina's: als oude en nieuwe records naast elkaar staan, wordt e-mail onvoorspelbaar bij de ene of de andere server bezorgd. Een MX-record noemt een mailserver en een prioriteit; afzenders proberen eerst het laagste nummer. Het concept wordt uitgelegd in wat een MX-record is.
Bij Postelva bewerkt u de zone in het klantenpaneel, en DNS-sjablonen met één klik voor Proton Mail, Fastmail, Zoho Mail, Google Workspace en Microsoft 365, plus een SPF- en DMARC-sjabloon en een sjabloon "geen e-mail" voor een domeinnaam die niets verstuurt. Een sjabloon vervangt in één handeling de MX-, SPF- en DKIM-records voor de aanbieder. Voor Tuta, Mailbox.org, iCloud+ en Migadu typt u de MX-, TXT- en CNAME-records in de DNS-editor, met de waarden die het eigen scherm van de aanbieder toont.
Wat gebeurt er met SPF en DKIM tijdens een overstap?
Een domein mag maar één SPF-record publiceren, dus voeg de include van de nieuwe aanbieder toe aan het bestaande record in plaats van een tweede aan te maken. Proton Mail, Mailbox.org en Mailfence geven allemaal dezelfde instructie. Houd de oude include in het record totdat u bent gestopt met verzenden vanaf de oude aanbieder en verwijder hem dan: de SPF-controle staat maximaal 10 DNS-opzoekingen toe (RFC 7208) en elke include telt mee.
DKIM-records zijn anders. Elke aanbieder gebruikt eigen selectornamen, zoals fm1, fm2 en fm3 bij Fastmail of protonmail, protonmail2 en protonmail3 bij Proton Mail, dus de nieuwe records kunnen naast de oude staan totdat u de oude aanbieder verwijdert. Bekijk de gepubliceerde records met de opdrachten in hoe u MX-, SPF-, DKIM- en DMARC-records controleert.
Hoe weet ik dat de overstap is gelukt?
Stuur een testbericht naar het domein vanaf twee externe accounts en lees de bezorgheaders. Volgens de index van Postelva van 12 november 2026 betekent overstappen naar Proton Mail dat 8 records wijzigen, naar Mailbox.org 11 en naar Fastmail 6 (het DMARC-record van Fastmail is op de gecontroleerde pagina's niet gelezen), dus een controle van elk recordtype is de snelste manier om een gemist record te vinden.
Als een bericht niet aankomt, ligt de oorzaak vrijwel altijd bij een van de oorzaken in waarom e-mail niet aankomt op een eigen domein. Houd het oude account een paar weken aan, want een afzender met een verouderde cache kan daar nog steeds bezorgen. Als het oude account leeg blijft, zet u de TTL terug op de normale waarde en verwijdert u de oude records.
Overstappen van aanbieder: vragen
Hoe lang duurt de overstap?
Een gewone MX-wijziging is na 1 tot 4 uur doorgevoerd en kan 24 tot 48 uur duren. Proton Mail vraagt u tot een dag de tijd te geven. Een vooraf ingestelde korte TTL houdt het venster klein.
Verlies ik mijn adres als ik overstap?
Nee, als het adres op uw eigen domein staat: het domein blijft bij dezelfde registrar en alleen de records veranderen. Een adres op het eigen domein van de oude aanbieder, zoals @proton.me of @tuta.com, kan niet mee verhuizen.
Kan ik overstappen zonder de oude e-mail te importeren?
Dat kan, maar dan verliest u het archief in de nieuwe mailbox. Houd het oude account open, of exporteer de e-mail, totdat u hebt wat u nodig hebt.
Verandert de overstap mijn domeinregistratie?
Nee. De registratie, de verlengingsdatum en de eigenaar blijven hetzelfde. Alleen de DNS-records die naar de mailserver wijzen, veranderen.
Moet ik op een rustig moment overstappen?
Het helpt, maar is niet vereist. Waar het om gaat, is dat de MX-overstap plaatsvindt na de import en nadat de TTL is verlaagd.
Samengevat
- Verlaag de MX-TTL 24 tot 48 uur vóór de overstap naar 300 tot 600 seconden.
- Importeer het archief eerst via IMAP; doorsturen verplaatst alleen nieuwe e-mail.
- Wijzig de MX-records als laatste; laat geen twee aanbieders door elkaar staan.
- Slechts één SPF-record; voeg de nieuwe include daaraan toe; maximaal 10 DNS-opzoekingen.
- Gewijzigde records: Proton Mail 8, Mailbox.org 11, Fastmail 6 zonder DMARC.
- Gewone verspreiding duurt 1 tot 4 uur, tot 24 tot 48 uur.
- Houd het oude account totdat de testmails zijn aangekomen.
Bronnen (8)
- Overstappen van Gmail naar Proton — Proton (gelezen op 2026-11-12)
- Eigen domeinnaam van Namecheap (MX-waarden) — Proton (gelezen op 2026-11-12)
- Anti-spoofing voor eigen domeinen — Proton (gelezen op 2026-11-12)
- Standaard DNS-records — Fastmail (gelezen op 2026-11-12)
- mailbox.org KB: eigen domein — mailbox.org (gelezen op 2026-11-12)
- RFC 7208, sectie 4.6.4 — RFC Editor (gelezen op 2026-11-12)
- RFC 2308: negative caching of DNS queries — RFC Editor (gelezen op 2026-11-12)
- Hoe lang duurt het voordat DNS-wijzigingen zich verspreiden — Suped (gelezen op 2026-11-12)