E-mailhosting voor je domein verhuizen: DNS-controlelijst

Je kunt e-mailhosting voor je domein verhuizen en dezelfde adressen behouden als mailboxen en aliassen op het doel opnieuw zijn ingericht. Een verkeerde DNS-wijziging kan de mailstroom verstoren. Mailboxgegevens kopiëren en DNS omschakelen zijn aparte taken; onjuiste afstemming kan weigering of ontvangst op beide systemen opleveren.

Lees voor het volledige migratiebeeld eerst zakelijke e-mail. Hier gaat het om de overstap van mailhosting voor een eigen beheerd domein, niet om een registrartransfer of het verhuizen van een persoonlijk provideradres. We behandelen MX, SPF, DKIM en DMARC terwijl de bron nog wordt gebruikt.

Bereid doelmailboxen voor, kopieer gegevens vooraf, verlaag TTL vroeg en publiceer nieuwe authenticatie voordat je ontvangst omschakelt. Verifieer iedere stap; die volgorde verkleint risico's zonder een ononderbroken overgang te garanderen.

Wat betekent e-mailhosting voor je domein verhuizen?

Je houdt het domein en richt de gewenste adressen met toestemming op een nieuwe host in. Daarna wijzig je de ontvangst en verzendauthenticatie waar nodig. DNS-timing, oude afhankelijkheden en niet-passende authenticatie kunnen naast de gegevenskopie problemen veroorzaken.

De opdracht omvat doorgaans drie taken:

1. Oude gegevens kopiëren naar vooraf aangemaakte doelmailboxen; de voorbereiding hieronder moet dus vóór deze kopie gebeuren.
2. Dezelfde mailboxen, aliassen en forwarding op het doel voorbereiden en verifiëren.
3. DNS voor inkomende mail van het eigen domein naar de nieuwe provider omschakelen.

Schakel MX pas na doelvoorbereiding en kopiecontrole om. Anders kan nieuwe mail ontbreken of worden geweigerd. Vergeten SPF of DKIM kan authenticatie beïnvloeden; de ontvanger bepaalt de uiteindelijke behandeling, niet automatisch spam of weigering.

Verdeel de overgang in voorbereiding, omschakeling en stabilisatie. TrekMail beschrijft IMAP-import vanuit Gmail, Outlook, Yahoo, iCloud en andere IMAP-bronnen op Starter en hoger. IMAP kopieert ondersteunde berichten en status, geen contacten, agenda's of accountregels. Controleer actuele ondersteuning en toegestane broncredentials. De directe importer biedt geen interactieve OAuth; app-wachtwoorden hangen af van verificatie en providerbeleid, en zo nodig is een andere ondersteunde tool nodig. Lees voor de kopieerwerkwijze imapsync.

Fase 1: bereid de omschakeling 24-48 uur vooraf voor

Voorbereiding beperkt de impact. Maak doelmailboxen aan, publiceer nieuwe authenticatie, verlaag TTL tijdig en kopieer terwijl de bron actief is. Het genoemde tijdvenster is een planningsvoorbeeld, geen garantie dat iedere cache is bijgewerkt.

1. Verlaag TTL van bestaande mailrecords

Een TTL van 300 seconden kan bruikbaar zijn als de DNS-provider dat toestaat. Het venster van 24-48 uur is illustratief; houd vooral rekening met de oude TTL en caches. Vijf minuten vooraf wijzigen wist bestaande antwoorden niet.

dig example.com MX

dig example.com TXT

dig example.com TXT _dmarc.example.com

Bij een oude TTL van 3600 of 86400 kunnen eerdere antwoorden blijven staan tot hun geldigheid verloopt. Begin daarom tijdig, niet pas vrijdag om 4:55 PM. De laatste opdracht hierboven is geen betrouwbare afzonderlijke DMARC-query; root-TXT controleert ook niet automatisch DKIM-selectors. Controleer de juiste namen afzonderlijk bij gezaghebbende servers en relevante resolvers.

2. Kopieer mailboxgegevens vóór de MX-wijziging

Voer de IMAP-import uit terwijl de oude provider beschikbaar blijft. De beschreven TrekMail-wizard schrijft naar een bestaande doelmailbox op de achtergrond. Controleer login, quota en een proefkopie voordat je de rest overdraagt.

Koppel het domein zonder ontvangst voortijdig om te schakelen, maak het doel aan en volg een import starten via het dashboard. TrekMail wordt als IMAP-dienst zonder POP3 beschreven. POP is niet op zichzelf een fout, maar lokale POP-mail kan buiten de bronserver staan: maak daarvan eerst een aparte back-up.

3. Bereid alle doelidentiteiten voor

Maak vóór de omschakeling de benodigde mailboxen, aliassen, forwarding en catch-all aan. Controleer toestemming, providerbeleid en werkelijke routing, ook voor uitzonderingen.

Voorbeeld: billing@, support@, careers@, noreply@, een catch-all en een oude doorstuurregel naar het Gmail-account van de oprichter. Een vergeten route kan pas zichtbaar worden als juist dat adres mail krijgt.

Voor veel merken of klantdomeinen kan centraal beheer helpen, binnen abonnementsvoorwaarden. Lees hosting voor meerdere e-maildomeinen als schaal je belangrijkste aandachtspunt is.

4. Voeg SPF-verzenddiensten samen

Oude systemen kunnen tijdelijk legitieme antwoorden of automatiseringen blijven verzenden. Autoriseer de daadwerkelijk gebruikte oude en nieuwe diensten voor de geëvalueerde identiteit. Volgens RFC 7208 geldt een budget van 10 geëvalueerde DNS-veroorzakende mechanismen en modifiers, inclusief geneste evaluatie; het gaat niet om alle netwerkpakketjes of gecachte queries.

v=spf1 include:_spf.google.com include:spf.trekmail.net -all

Dit voorbeeld moet aan je werkelijke providers worden aangepast; autoriseer Google niet zonder legitiem gebruik. Free wordt met eigen SMTP beschreven en betaalde abonnementen met Managed SMTP: controleer de huidige route en voorwaarden. Publiceer één SPF-beleidsrecord per naam; andere TXT-records mogen daarnaast bestaan.

5. Publiceer DKIM vooraf en beoordeel DMARC

Gebruik een nieuwe DKIM-selector en publiceer vóór het nieuwe systeem ondertekent. Overschrijf de oude niet zolang het oude systeem nog tekent. Een tijdelijke wijziging naar p=none is alleen een door de eigenaar goedgekeurde risicokeuze; correct uitgelijnde mail kan ook onder handhaving blijven. Monitoringbeleid garandeert geen acceptatie en verwijdert niet alle risico's.

Houd rekening met negatieve caching: een nog ontbrekende selector kan als afwezig worden opgeslagen volgens de SOA-gerelateerde regels van RFC 2308. Publiceer vroeg en controleer relevante antwoorden; een TTL op een ander record wist die cache niet.

Fase 2: schakel de mailhosting om

Controleer voorbereide records bij gezaghebbende DNS, wijzig MX wanneer doel en kopie klaar zijn en test externe resolvers en echte ontvangst en verzending. De duur hangt van de omgeving af.

Beperk deze wijziging tot de noodzakelijke omschakeling. Onverwante DNS-opruiming maakt foutanalyse en terugval ingewikkelder.

1. Verifieer de nieuwe provider

Controleer de domeinstatus en vooraf publiceerbare authenticatie zonder MX vroeg te veranderen. Active of groene vinkjes zijn geen volledige praktijktest en kunnen vóór de omschakeling nog niet allemaal haalbaar zijn. Zie een domein toevoegen. De bronbeschrijving uit maart 2026 noemt dit voorbeeld; valideer actuele accountwaarden en beleid:

MX   @              mail.trekmail.net.   priority 10
TXT  @              v=spf1 include:spf.trekmail.net -all
TXT  dkim._domainkey  [unique value from dashboard]
TXT  _dmarc         v=DMARC1; p=quarantine;

Verwijder oude MX van Google Workspace, Microsoft 365, Zoho, cPanel of de registrar pas bij de geplande vervanging. Gemengde MX werkt via prioriteit en fallback, niet als vaste gelijke verdeling; wanneer beide hosts mail aannemen, kan ontvangst toch op verschillende systemen terechtkomen.

2. Vervang MX en behoud voorlopig lage TTL

Vervang de actieve oude MX-set van het beheerde domein door de nieuwe. Een waarde van 300 kan tijdelijk bruikbaar zijn, maar bestaande caches en SMTP-herpogingen blijven relevant. Houd bronontvangst en herhaalde deltas beschikbaar.

dig @8.8.8.8 example.com MX

dig @1.1.1.1 example.com MX

Controleer minstens twee openbare resolvers én de gezaghebbende antwoorden. Test daarna vanuit een externe mailbox naar het domein en vanuit het doel naar buiten. Enkele goede antwoorden bewijzen geen wereldwijde omschakeling.

3. Controleer IMAP-clients

Gebruik de actuele clientinstellingen: IMAP imap.trekmail.net op poort 993 met TLS en SMTP smtp.trekmail.net op 465 met impliciete TLS of 587 met STARTTLS. Controleer certificaatketen, hostnaam en volledige mailboxcredentials, niet het dashboardwachtwoord. Zie IMAP- en SMTP-instellingen voor clients.

“Ik kan verzenden, maar niet ontvangen” bewijst geen DNS-fout. Onderzoek DNS én mailboxen, aliassen, quota, filtering, mapweergave, clients en netwerk met echte tests en logs.

Fase 3: volg de eerste 72 uur na de overstap

Gebruik de eerste 72 uur als observatievoorbeeld, niet als bewezen einde. Volg ontvangst, verzendauthenticatie en oude routes, en herhaal deltas voor late mail, oude datums, verplaatsingen en ondersteunde vlaggen. Behoud oude SMTP, beheersynchronisatie en terugval tot gecontroleerde uitfasering.

Een omschakeling kan na tien minuten voltooid lijken terwijl uitzonderingen pas dagen later zichtbaar worden. Controleer ook minder frequente processen.

1. Zoek verkeer via de oude provider

CRM, scanners, WordPress-formulieren, facturatie en supporttools kunnen nog de oude route gebruiken. Onderzoek headers en logs en pas integraties aan voordat je toestemming of beleid verder beperkt.

2. Controleer authenticatie en uitlijning

Acceptatie door een mailserver bewijst geen geslaagde authenticatie of inboxplaatsing. Controleer vertrouwde ontvangstresultaten van echte berichten. SPF-falen kan bij doorsturen optreden; DMARC kan toch slagen via een geldige, met het zichtbare From-domein uitgelijnde DKIM-handtekening, of via geslaagde uitgelijnde SPF.

Lees voor resterende externe forwarding domeinmail naar Gmail doorsturen en controleer de gevolgen voor je eigen route.

3. Faseer overlap pas na verificatie uit

Verwijder oude SPF-autorisatie pas als de dienst niet meer legitiem verzendt. Behoud oude DKIM-records zolang berichten in wachtrijen, onderweg of doorgestuurd nog de openbare sleutels nodig kunnen hebben voor verificatie. Verhoog TTL eventueel naar 3600 na stabilisatie. Als je tijdelijk p=none koos, beoordeel handhaving opnieuw met inventarisatie, tests en terugvalplan.

Opruimen hoort bij de opdracht, maar een vaste termijn bewijst niet dat oude authenticatie veilig verwijderd kan worden.

Traditionele en gecontroleerde werkwijzen

Mailhosting verhuizen is geen registrartransfer. Een gecontroleerd proces bereidt doelen en kopieën voor, wijzigt ontvangst bewust en test authenticatie. Tools kunnen fouten helpen vinden, maar vervangen geen controle.

TrekMail beschrijft eigen domeinen, IMAP, catch-all, eigen SMTP op Nano of inbegrepen SMTP op betaalde abonnementen, forwarding, migratie en API. De bron noemt Starter vanaf $3.50 per maand met Free, Starter, Pro, Agency en Enterprise. Controleer huidige functies, limieten en voorwaarden op TrekMail-prijzen; het abonnementsmodel belooft geen onbeperkte uitbreiding.

Laatste controlelijst voor de domeinoverstap

Maak doelen aan, verlaag TTL tijdig, kopieer gegevens, voeg legitieme SPF-diensten samen en publiceer DKIM vooraf. Beoordeel DMARC bewust, schakel zo nodig MX om en test echte mail. Ruim pas na verificatie en resterende deltas op.

1. Gebruik 24-48 uur als planningsvoorbeeld voor TTL, met aandacht voor oude caches.
2. Kopieer IMAP-gegevens naar al aangemaakte en geteste doelmailboxen.
3. Verifieer vooraf alle mailboxen, aliassen, forwarding en catch-all op het doel.
4. Voeg legitieme verzenddiensten samen in één SPF-policy per naam.
5. Publiceer een nieuwe DKIM-selector en test ondertekening.
6. Kies alleen met toestemming tijdelijk p=none als dat bij het risico past; automatische versoepeling is niet nodig.
7. Controleer domeinstatus en werkelijke ontvangst en verzending.
8. Vervang de actieve MX-set van het beheerde domein bij de geplande omschakeling.
9. Test echte inkomende en uitgaande mail en herhaal deltas.
10. Beoordeel na 72 uur voortgang, maar verwijder oude authenticatie of verscherp beleid pas als verificatie dat ondersteunt.

Behandel de overstap als een gecontroleerde infrastructuurwijziging. Dat beperkt risico's zonder continuïteit te garanderen. Voor beheer na de verhuizing kun je TrekMails beschreven multi-domeinabonnementen, gedeelde opslag en IMAP-migratie overwegen binnen de actuele voorwaarden.