Bij het migreren van een website spelen twee aspecten een rol: de bestanden en databases van de site, en je e-mailservers. Een veelvoorkomend probleem is dat e-mailservers uitvallen doordat men niet goed begrijpt hoe je MX-records en webhosting onafhankelijk van elkaar, maar toch in onderlinge samenhang werken.
Dit betekent dat je e-mails altijd naar je e-mailprovider worden gestuurd, ongeacht waar je website staat of via welk platform je site wordt gehost.
Om precies die reden zal je migratie naar Kinsta geen enkele e-maildienst onderbreken als je alles correct configureert.
Je MX-records en webhosting werken onafhankelijk van elkaar
Het Domain Name System (DNS) beheert elk recordtype afzonderlijk tijdens migratie van hosting.
Wanneer je van hosting verandert, werk je de A-records bij die browsers naar het nieuwe IP-adres van de server leiden. Je MX-records blijven ongewijzigd, tenzij je ze bewust aanpast, zodat mailservers e-mail blijven doorsturen naar je bestaande e-mailprovider zonder dat je iets hoeft te configureren.
Het migratieproces van Kinsta kloont je site terwijl je oorspronkelijke host het verkeer blijft verwerken. Hierdoor kunnen beide omgevingen tegelijkertijd dezelfde inhoud weergeven. Tijdens de DNS-propagatie zien sommige bezoekers verschillende versies van je site, afhankelijk van de verbindingsaanvraag naar de DNS-server. De TTL-waarden bepalen hoe lang dit tijdvenster duurt (meestal tot een paar uur).
Gedurende dit tijdvenster leiden je MX-records e-mail zonder onderbreking naar je mailserver: kort gezegd werkt e-mailroutering via een apart DNS-lookuppad dan het webverkeer.
3 migratiescenario’s en de gevolgen voor MX-records
De configuraties van je e-mailhosting bepalen hoe MX-records zich gedragen tijdens migraties. Je moet een andere aanpak kiezen, afhankelijk van waar je e-mail momenteel staat en of je van plan bent om tijdens de sitemigratie van e-mailprovider te veranderen.
1. E-mail wordt apart van je website gehost (meest voorkomend)
E-maildiensten zoals Google Workspace of Microsoft 365 werken op een infrastructuur die volledig gescheiden is van webhosting. Je website draait op één platform, terwijl e-mail via een gespecialiseerde provider met speciale mailservers verloopt.
Tijdens de migratie naar Kinsta veranderen alleen je A-records om bezoekers naar je nieuwe hostinglocatie te leiden. Je MX-records blijven zonder wijzigingen naar Google Workspace of Microsoft 365 verwijzen. E-mail verloopt via de infrastructuur van je e-mailprovider precies zoals voorheen, zonder dat er tijdens de overgang configuratiewijzigingen nodig zijn.
Kinsta-klant Cornershop Creative beheert honderden klantensites, waaronder honderden sitemigraties zonder e-mailonderbrekingen. Hun workflow houdt e-mail op Google Workspace terwijl websites naar Kinsta worden verplaatst.
Dit is de door Kinsta aanbevolen configuratie voor alle sites. Het scheidt e-mail van hosting, dus wanneer je sites migreert, servers bijwerkt of infrastructuurwijzigingen doorvoert, gaat de e-mailservice gewoon door zonder dat er verdere coördinatie nodig is.
2. E-mail en website op dezelfde server
Kinsta biedt geen e-mailhosting aan als onderdeel van zijn managed WordPress-hosting. Dit is optimaal omdat e-mail hierdoor op een speciale infrastructuur blijft die is ontworpen voor het bezorgen van berichten, het filteren van spam en het voldoen aan e-mailauthenticatiestandaarden.
Sommige hosts bundelen e-mail echter met webhosting, wat voor ingewikkelde afhankelijkheden zorgt. Omdat je e-mailaccounts op dezelfde server staan als je websitebestanden en databases, is de e-maildienst hierdoor direct gekoppeld aan de infrastructuur van je hostingprovider.
Daarom moet je een beslissing nemen wanneer je overstapt van gebundelde e-mailhosting: gebruik een aparte e-mailprovider voordat je je site verhuist, of verhuis alleen de bestanden van je website naar Kinsta.
Het migreren van e-mail naar een externe provider vóór een sitemigratie houdt in dat je nieuwe accounts moet aanmaken, MX-records moet configureren om naar de nieuwe provider te verwijzen en de e-mailbezorging moet testen voordat je je A-records bijwerkt. Zodra je e-mail betrouwbaar is, ga je verder met de sitemigratie. Het alternatief is om een account bij je oude host aan te houden, specifiek voor e-mail, wat duur en inefficiënt is.
3. Tegelijkertijd zowel de web- als de e-mailprovider wijzigen
Je moet je van tevoren voorbereiden als je e-mail tijdens een sitemigratie wilt overzetten. Dit houdt in dat je beide e-mailsystemen parallel laat draaien tijdens een korte testperiode, voordat je de DNS-records omzet om de nieuwe configuratie live te zetten.
Eerst maak je een account aan bij je nieuwe e-mailprovider en configureer je de MX-records in je DNS-beheerpaneel. Deze nieuwe MX-records bestaan naast je huidige configuratie, in eerste instantie met lagere prioriteitswaarden die voorkomen dat productiemail tijdens het testen doorkomt.
Test vervolgens de nieuwe e-mailconfiguratie met een tool zoals MXToolbox om te controleren of de records bestaan en naar de juiste mailservers verwijzen:
Verstuur hier testberichten, controleer de aflevertijden en bevestig dat zowel het verzenden als het ontvangen correct werkt via de nieuwe provider voordat je wijzigingen doorvoert.
Zodra je hebt bevestigd dat de nieuwe e-mailinfrastructuur goed werkt, coördineer je de DNS-wijzigingen. Hiervoor moet je de prioriteiten van de MX-records bijwerken om e-mail naar de nieuwe provider te leiden en de A-records naar Kinsta te laten verwijzen. Sommige e-mails kunnen nog steeds naar je oude provider worden gerouteerd op basis van DNS-records in de cache, dus door tot 48 uur toegang te houden tot beide e-mailsystemen vang je eventuele vertraagde berichten op.
MX-records beheren tijdens Kinsta-migraties
Elke site op Kinsta krijgt een tijdelijk kinsta.cloud domein. Met de Site Preview tool kun je deze tijdelijke URL openen om je gemigreerde site te testen voordat je DNS-updates doorvoert.
Via de URL heb je volledige toegang om in te loggen op WordPress, front-endpagina’s te bekijken, formulieren in te vullen en de functionaliteit te controleren, terwijl je productiesite het verkeer via de oorspronkelijke host blijft verwerken.
Je moet een verificatieproces uitvoeren om eventuele problemen op te sporen voordat de DNS-propagatie plaatsvindt. Als er zich problemen voordoen, kun je deze hier oplossen zonder dat je productiesite hierdoor wordt beïnvloed. Pas nadat je hebt gecontroleerd of alles correct functioneert, ga je verder met de DNS-updates.
Het Kinsta Supportteam biedt begeleiding en documentatie voor het volledige proces na de migratie en staat 24/7 klaar om vragen te beantwoorden.
Kinsta DNS-features voor het beheren van e-mail
Kinsta DNS biedt optionele DNS-hosting als je domeinrecords rechtstreeks in MyKinsta wilt beheren in plaats van bij je registrar of een externe DNS-provider. De service bevat functionaliteit die speciaal is ontworpen voor het beheer van e-mailrecords.
Je kunt MX-records met een paar klikken instellen in Google Workspace. Wanneer je een nieuw domein toevoegt via de DNS-pagina in MyKinsta, vink je het selectievakje ‘Gmail MX-records toevoegen’ aan. Hierdoor worden automatisch alle vijf vereiste MX-records aangemaakt met de juiste prioriteitswaarden en hostnames.
Voor domeinen die al in Kinsta DNS zijn geconfigureerd, ga je naar DNS, selecteer je je domein en klik je bovenaan de pagina op de knop ‘Gmail MX-records toevoegen’. Zo kun je de vijf Google Workspace MX-records bekijken voordat je het proces voltooit:
aspmx.l.google.com(prioriteit1)alt1.aspmx.l.google.com(prioriteit5)alt2.aspmx.l.google.com(prioriteit5)alt3.aspmx.l.google.com(prioriteit10)alt4.aspmx.l.google.com(prioriteit10)
De standaard TTL voor deze records is 3.600 seconden (één uur). Dit bepaalt hoe lang DNS-servers wereldwijd informatie in de cache bewaren voordat ze controleren op updates. Dit zorgt voor een evenwicht tussen de efficiëntie van DNS-caching en de mogelijkheid om wijzigingen aan te brengen wanneer dat nodig is.
MX-records toevoegen voor andere e-mailproviders
Voor andere e-mailproviders dan Google Workspace moet je de MX-records handmatig configureren. Je provider levert deze waarden, meestal hostnames van mailservers en prioriteitsnummers.
Klik in MyKinsta op DNS, selecteer je domein en klik onder Een DNS-record toevoegen op Record toevoegen. Selecteer het MX-recordtype en vul de vereiste velden in:
- Hostname. Geef de hostname van je e-mailadres op (wordt vaak leeg gelaten bij configuraties voor het hoofddomein).
- Verwijst naar. Voer hier de hostname in van de mailserver van je e-mailprovider.
- Prioriteit. Stel het prioriteitsnummer in, waarbij lagere nummers een hogere prioriteit aangeven.
- TTL (Time to Live). Gebruik de aanbevolen standaardinstelling van één uur.
Klik ten slotte op DNS-record toevoegen om de configuratie op te slaan.
Microsoft 365 gebruikt doorgaans één MX-record dat verwijst naar een regionale mailserver, terwijl Zoho meerdere MX-records met verschillende prioriteitswaarden vereist. De meeste providers ondersteunen meerdere MX-records; voeg ze allemaal afzonderlijk toe volgens hetzelfde proces.
Je hoeft ook geen gebruik te maken van Kinsta DNS. In plaats daarvan kun je DNS beheren via je domeinregistrar of een andere provider, terwijl je je site bij Kinsta host. Dit vereenvoudigt soms het oplossen van problemen en stroomlijnt updates wanneer je je webhosting- of e-mailconfiguraties wijzigt.
Veelvoorkomende problemen met MX-records en hoe je ze kunt oplossen
Ongeacht welke planning en maatregelen je ook neemt, er is altijd wel een probleem dat moet worden opgelost. Hier zijn enkele van de meest voorkomende problemen met MX-records:
- Verwezenn naar CNAME-records.
- Verkeerde prioriteitswaarden ingesteld.
- Backupservers verkeerd geconfigureerd.
Ten eerste zorgen MX-records die naar CNAME-records verwijzen voor bezorgingsfouten. Dit komt doordat mailservers MX-records opvragen en verwachten A- of AAAA-records te vinden die IP-adressen bevatten. Wanneer een MX-record naar een CNAME verwijst, kan de mailserver de opzoekketen niet voltooien, wat resulteert in teruggestuurde berichten.
De oplossing is ervoor te zorgen dat je MX-records rechtstreeks verwijzen naar hostnames die A-records hebben. Een juiste configuratie is dat je MX-record verwijst naar mail.example.com, dat een A-record heeft met het IP-adres van je mailserver.
Onjuiste prioriteitswaarden kunnen ook problemen met de e-mailroutering veroorzaken als er meerdere MX-records voor een domein bestaan. Lagere prioriteitsnummers ontvangen e-mail als eerste, dus je primaire server moet een waarde hebben zoals 10, terwijl backupservers hogere nummers gebruiken (20 of 30). Als je deze waarden door elkaar haalt, leidt dat tot vertragingen als een backupserver berichten moet doorsturen naar de primaire server.
Als je primaire e-mailserver offline gaat, kan een verkeerd geconfigureerde backupserver je e-mails niet verwerken. Een MX-record dat verwijst naar een niet-bestaande of anderszins suboptimale infrastructuur creëert een vals gevoel van redundantie. Om dit op te lossen, pas je tijdelijk de prioriteitswaarden op de back-upserver aan om deze primair te maken, en stuur je vervolgens testberichten om de bezorging te controleren.
Je migratie plannen met e-mail in gedachten
Het migreren van een site kan tijd kosten, vooral als je ook rekening moet houden met het beheer van je MX-records. De beste aanpak is om je records vóór de migratie te documenteren, inclusief eventuele prioriteitswaarden, om een volledige back-up van alle DNS-records te maken.
In het MyKinsta-dashboard kun je met een paar klikken MX-records aanmaken (voor Google Workspace-gebruikers). Nadat de migratie is gelukt, is het belangrijk om te testen of alles werkt. Het Kinsta Supportteam heeft de juiste expertise om je door het hele proces heen te helpen.
Naast die deskundige migratieondersteuning biedt Kinsta’s managed WordPress-hosting betrouwbare infrastructuur die is ontworpen voor sites van elke omvang, en DNS-beheertools die de e-mailconfiguratie vereenvoudigen.
