Een installatiebedrijf uit Midden-Nederland liet zijn website verhuizen naar een snellere hosting. De site zelf ging vlekkeloos over: op maandagavond omgezet, dinsdagochtend was alles bereikbaar en sneller dan voorheen. Toch belde de eigenaar ons woensdag met de mededeling dat e-mail werkt niet na verhuizing van zijn website. Er was in anderhalve dag welgeteld één bericht binnengekomen, en dat was een nieuwsbrief.
Voor een bedrijf dat het merendeel van zijn opdrachten via het contactformulier en per mail binnenkrijgt, is dat geen ongemak maar omzetverlies. Dit is wat er aan de hand was, hoe we het hebben gevonden en wat u eruit kunt meenemen.
De eerste vaststelling: wat werkte wél?
Bij een stille mailbox is het verleidelijk om meteen in instellingen te duiken. We doen eerst het omgekeerde: vaststellen wat er nog wél gebeurt, want dat grenst het probleem af.
- Uitgaande mail werkte. De medewerkers konden gewoon versturen en kregen geen foutmeldingen terug.
- Interne mail werkte. Berichten van collega’s binnen hetzelfde domein kwamen aan.
- Inkomende mail van buiten kwam niet aan. Een test vanaf een privéadres bij een grote provider leverde na twee minuten een foutmelding op dat het bericht niet bezorgd kon worden.
- Het contactformulier op de site meldde “verzonden”, maar er kwam niets binnen.
Die combinatie wijst maar één kant op. Uitgaand verkeer loopt via de mailserver waar de mailprogramma’s op ingesteld staan; die was ongewijzigd. Inkomend verkeer wordt gestuurd door wat er in het domeinnaamsysteem staat, en daar was wél iets veranderd.
De oorzaak: de MX-records reisden mee
Bij de verhuizing waren de nameservers van het domein verlegd naar de nieuwe hostingpartij. Dat is een gebruikelijke stap en op zich niets mis mee. Alleen: met de nameservers verhuist ook het complete adresboek van het domein. Op de nieuwe nameservers stond een standaardconfiguratie, en die wees de mail netjes naar de mailserver van de nieuwe hoster.
Alleen stond de mailbox daar niet. De mail van dit bedrijf liep al drie jaar via een aparte zakelijke maildienst, ondergebracht bij een andere leverancier. De oude nameservers wisten dat; de nieuwe niet. Vanaf het moment dat de wijziging was doorgedrongen, werd elke inkomende mail aangeboden bij een server die het domein niet kende. Die weigerde beleefd, en de afzender kreeg een foutmelding.
Belangrijk detail: geweigerde mail wordt niet bewaard. Er zat geen wachtrij die we konden vrijgeven. Wat in die anderhalve dag is teruggestuurd, is definitief weg. Dat is precies waarom een stille mailbox altijd voorrang krijgt boven een trage pagina.
Hoe we het hebben vastgesteld
De diagnose duurde tien minuten en bestond uit drie stappen.
- De MX-records opgevraagd. Met een publieke dns-controle zagen we welke mailserver op dat moment werd opgegeven voor het domein. Dat was de standaardserver van de nieuwe hoster.
- Vergeleken met de documentatie van de maildienst. Die schrijft twee specifieke MX-records voor, met een prioriteitsvolgorde. Geen van beide stond er nog in.
- De foutmelding van de teruggestuurde mail gelezen. Daar stond letterlijk in dat het ontvangende systeem het domein niet als eigen domein herkende. Die regel bevestigde het beeld.
Meelezen in zo’n foutrapport is trouwens een gewoonte die iedereen zich kan aanleren. De tekst is technisch, maar de kern staat er in gewoon Engels. Wie hem doorstuurt in plaats van weggooit, bespaart een beheerder een half uur zoeken.
Het herstel en wat daarna nog nodig was
Het terugzetten van de twee MX-records was een kwestie van vijf minuten. Daarna kwam het lastigste deel: wachten. De ttl van de nieuwe records stond op vier uur, dus het duurde de rest van de middag voordat iedereen weer op de goede server uitkwam. In die tijd hebben we een tijdelijk adres bij een andere provider aan de medewerkers gegeven, en dat nummer en adres op de contactpagina gezet.
Er waren nog drie nasleepjes:
- De SPF-regel was ook verdwenen. Zonder die regel belandde uitgaande mail bij een deel van de ontvangers in de ongewenste map. Meer daarover in de uitleg over SPF, DKIM en DMARC voor uw domein.
- Het contactformulier verstuurde nog via de standaard PHP-mailfunctie van de nieuwe server. Dat is een bekende bron van verdwenen aanvragen; we hebben het omgezet naar verzending via een echte mailserver.
- Er was geen back-up van de dns-instellingen. Een schermafdruk van de oude records had de hele zoektocht overbodig gemaakt.
Vier afspraken die dit voorkomen
Deze case is geen uitzondering. Wij zien hem een paar keer per jaar, altijd bij bedrijven waar site en mail bij verschillende partijen staan, wat heel gewoon en meestal verstandig is.
- Leg vóór de verhuizing alle dns-records vast. Een schermafdruk of een export volstaat. Dit is de goedkoopste verzekering die er is.
- Vraag expliciet wie de mail levert. “Verhuist de mail mee?” is een andere vraag dan “verhuist de website?” en verdient een apart antwoord op papier.
- Verlaag de ttl een dag van tevoren. Gaat er iets mis, dan is het binnen vijf minuten hersteld in plaats van vier uur.
- Test direct na de omzetting inkomende mail van buitenaf. Niet vanaf een collega-adres, maar vanaf een privéadres bij een grote provider. Dat is de enige test die telt.
Wij plannen bij WebMaintor dit soort omzettingen daarom nooit op vrijdag, en de eerste controle na een verhuizing is altijd een testmail van buiten. Dat hoort bij het uitzoeken en verhelpen van storingen rond een WordPress-site, en het is de goedkoopste minuut van het hele project.
Blijven berichten daarna toch in de ongewenste map hangen, kijk dan naar de oorzaken van mail die in de spammap belandt. Dat is een apart vraagstuk, met de reputatie van uw domein als kern.
Concrete volgende stap: vraag vandaag de MX-records van uw eigen domein op en leg de uitkomst vast in uw administratie. Dan weet u bij een volgende verhuizing precies wat er hoorde te staan.
