Het overstapje leek geslaagd. Je bent met je zakelijke mail naar Microsoft 365 gegaan, de MX-records zijn omgezet, Outlook doet het, mail van klanten komt binnen. En dan, na een paar dagen, valt het op: het contactformulier van je website komt niet meer aan. En die ene leverancier zweert dat hij je gemaild heeft, maar jij hebt niets. De rest werkt gewoon. Hoe kan mail nou gedeeltelijk zoekraken?
Dit is een van de meest voorkomende — en meest verwarrende — mailproblemen na een overstap naar Microsoft 365 of Google Workspace. De oorzaak zit vrijwel altijd op dezelfde plek: je oude hostingserver weet nog niet dat de mail verhuisd is.
Het patroon herkennen
Zo ziet het er in de praktijk uit:
- Mail van Gmail-, Outlook.com- en de meeste zakelijke adressen: komt gewoon aan.
- Mail van je eigen website (contactformulier, webshopbestellingen, WordPress-meldingen): komt niet aan.
- Mail van een paar specifieke bedrijven: komt niet aan — en opvallend vaak zitten die bij dezelfde hoster als jij.
- Geen foutmelding aan jouw kant; de afzenders krijgen soms wél een bounce, soms niets.
Herkenbaar? Dan is de kans groot dat je dit binnen tien minuten oplost.
Wat er misgaat: de server kijkt niet naar buiten
Normaal gesproken zoekt een verzendende mailserver via DNS het MX-record van jouw domein op: “waar moet mail voor voorbeeldbedrijf.nl heen?” Sinds je overstap wijst dat record naar Microsoft 365, dus de wereld levert daar af. Prima. (Hoe MX en andere records werken lees je in DNS uitgelegd.)
Maar er is één server die dat MX-record niet raadpleegt: je eigen hostingserver. Toen je hostingpakket werd aangemaakt, is jouw domein daar geregistreerd als “lokaal maildomein” — oftewel: “mail voor voorbeeldbedrijf.nl handel ik zélf af”. Zolang die instelling aan staat, denkt de server: mail voor dit domein? Dat ben ik! En hij bezorgt het bericht keurig… in de oude, verlaten mailbox op de hostingserver. Of hij weigert het, omdat de mailbox daar niet meer bestaat.
Daarom is de uitval zo selectief. Alleen mail die vanaf die server zelf vertrekt, gaat mis:
- je contactformulier en webshop (die draaien op die server);
- WordPress-meldingen en wachtwoord-reset-mails;
- mail van andere klanten op dezelfde gedeelde server — hun uitgaande mail vertrekt van dezelfde machine, die jouw domein nog als lokaal beschouwt.
Al het andere verkeer loopt via het publieke MX-record en komt gewoon in Microsoft 365 aan.
De fix: zet “lokale mail” uit voor je domein
De oplossing is één instelling. In DirectAdmin (het hostingpaneel dat veel Nederlandse hosters gebruiken) heet die: E-mail → MX Records → het vinkje “Use this server to handle my e-mails” (of in het Nederlands: “Gebruik deze server voor het afhandelen van e-mail”). Zet dat vinkje uit.
Daarmee vertel je de server: mail voor dit domein is niet meer van jou — zoek voortaan gewoon het MX-record op, net als de rest van de wereld. Vanaf dat moment stuurt de server formulier-mails en al het andere lokale verkeer netjes door naar Microsoft 365.
Kun je de instelling niet vinden, of beheer je het paneel niet zelf? Eén mailtje naar je hoster (bijvoorbeeld KeurigOnline) met “willen jullie het lokale maildomein uitzetten voor voorbeeldbedrijf.nl, mail draait nu extern bij Microsoft 365” is genoeg — dit is een standaardhandeling die elke hoster in een minuut voor je doet.
Testen of het opgelost is
Test na de wijziging niet alleen vanaf je eigen Microsoft 365-adres — mail van jezelf naar jezelf blijft binnen Microsoft en bewijst niets over de route die misging. Doe dit:
- Vul je eigen contactformulier in op de website. Dit is precies de route die stuk was.
- Stuur een testmail vanaf een extern adres (privé-Gmail bijvoorbeeld) ter controle van de normale route.
- Heb je een webshop: plaats een testbestelling en check of de bevestiging binnenkomt.
Komt het formulier nog steeds niet aan, kijk dan ook even naar de spammap in Microsoft 365 — formulier-mails vanaf een webserver worden daar nogal eens argwanend bekeken.
Vergeet je SPF-record niet
Dat brengt ons bij het tweede punt dat bij een overstap vaak blijft liggen: het SPF-record. Dat DNS-record vertelt ontvangers welke servers namens jouw domein mogen mailen. Na de overstap moet daar Microsoft 365 in staan (include:spf.protection.outlook.com) — én je webserver, als je contactformulier vanaf je eigen domein verstuurt. Klopt dat record niet, dan belandt je mail bij ontvangers in de spam of wordt hij geweigerd.
Hoe je SPF, DKIM en DMARC goed zet, staat stap voor stap in SPF, DKIM en DMARC instellen.
Samengevat
- Mail die na een overstap naar Microsoft 365 “gedeeltelijk” zoekraakt, komt bijna altijd van je eigen hostingserver: contactformulier, webshop, en klanten op dezelfde server.
- Oorzaak: de hostingserver beschouwt jouw domein nog als lokaal maildomein en bezorgt in de oude mailbox in plaats van bij Microsoft.
- Fix: in DirectAdmin bij E-mail → MX Records het vinkje “Use this server to handle my e-mails” uitzetten — of je hoster vragen dat te doen.
- Testen doe je met het contactformulier en een extern adres, niet met mail naar jezelf.
- Werk ook je SPF-record bij, met Microsoft 365 én je webserver erin.
Wanneer schakel je hulp in?
Twijfel je waar je mail nu precies langsloopt, of blijft er na de fix mail wegvallen? Vraag je hoster of webbeheerder om de maillogs erbij te pakken — daarin is per bericht te zien welke route het nam en waar het strandde. En plan je de overstap naar Microsoft 365 nog? Laat dan vooraf iemand de DNS- en mailinstellingen doorlopen; dan sla je dit hele artikel over.