“Ik heb betaald, maar niets ontvangen.” Een klant die dat mailt, is ongerust. Hij weet niet of de bestelling is doorgekomen en of hij is opgelicht. U ziet in WooCommerce dat alles klopt, maar de orderbevestiging is nooit aangekomen. En als het bij één klant gebeurt, gebeurt het waarschijnlijk bij meer, want de meeste klanten mailen niet; ze bellen ook niet, ze bestellen alleen niet meer.

Als de WooCommerce-mail niet aankomt, zijn er drie plekken waar het mis kan gaan: de mail wordt niet aangemaakt, de mail wordt niet verstuurd, of de mail wordt onderweg tegengehouden. Elk van die drie vraagt een andere oplossing. In dit artikel loopt u ze in die volgorde af, zodat u niet aan SMTP gaat sleutelen terwijl het probleem in een uitgevinkt vinkje zit.

Laag 1: maakt WooCommerce de mail wel aan?

Ga naar WooCommerce, Instellingen, E-mails. Daar staat per mailtype (nieuwe bestelling, bestelling in behandeling, bestelling afgerond, enzovoort) of hij ingeschakeld is. Het komt voor dat een mail per ongeluk is uitgezet, of dat een plugin een eigen mailsysteem heeft geïntroduceerd en de standaardmails heeft uitgeschakeld.

Let ook op de orderstatus. De mail “bestelling in behandeling” gaat pas uit als de betaling is bevestigd. Als een betaalplugin de status op “in afwachting” laat staan omdat de webhook van Mollie of Pay.nl de shop niet bereikt, wordt de bevestiging nooit getriggerd. Dan is het mailsysteem prima, maar krijgt het nooit het signaal. Controleer of de betreffende bestellingen wel de juiste status hebben.

Een snelle test: zet een orderstatus handmatig van “in behandeling” naar “afgerond” en kijk of de klant (of een testadres) de mail “bestelling afgerond” ontvangt. Zo ja, dan werkt de verzending en zit het probleem in de status; zo nee, ga naar laag 2.

Laag 2: verlaat de mail de server?

WordPress verstuurt mail standaard via de mailfunctie van PHP op de webserver. Dat is geen mailserver; het is een doorgeefluik zonder wachtwoord, zonder authenticatie en vaak zonder logboek. Veel hosts beperken die functie, en ontvangende mailservers vertrouwen het niet. Het resultaat is dat de mail soms wel, soms niet en soms nooit aankomt.

Installeer een mail-logplugin (bijvoorbeeld een SMTP-plugin met logfunctie) en plaats een testbestelling. Staat de mail in het log met status “verzonden”? Dan heeft de server hem overhandigd en zit het in laag 3. Staat hij er niet, of met een fout, dan is de verzending zelf het probleem.

De structurele oplossing is om mail niet via de webserver te sturen, maar via een echte mailservice met authenticatie: uw eigen zakelijke mail (Microsoft 365, Google Workspace) via SMTP, of een transactionele maildienst als Postmark, Brevo of Amazon SES. Die diensten zijn gebouwd om mail af te leveren en geven u inzicht in wat er gebeurt. Hoe u dat instelt, staat in het stappenplan voor SMTP in WordPress.

Laag 3: houdt de ontvanger de mail tegen?

De mail is verstuurd, maar komt in de spam terecht of wordt geweigerd. Dat gebeurt als de ontvangende server niet kan vaststellen dat uw webshop namens uw domein mag mailen. Daarvoor kijkt hij naar drie DNS-records: SPF, DKIM en DMARC. Ontbreken die, of staan ze verkeerd, dan is uw mail voor Gmail en Outlook verdacht.

Controleer het zo: stuur een orderbevestiging naar een eigen Gmail-adres, open de mail en kies “origineel weergeven”. Bovenin staat of SPF, DKIM en DMARC geslaagd zijn. Staat er “fail” of “none”, dan weet u waar het zit. De records worden bij uw domeinregistrar of DNS-beheerder aangepast, niet in WordPress. Het onderwerp verdient een eigen uitleg; die vindt u in het artikel over websitemail die in spam belandt.

Een bijkomend punt: het afzenderadres. Als de shop mailt vanaf “info@uwdomein.nl” maar via de server van uw host verstuurt, klopt dat niet met elkaar. Zorg dat het afzenderadres een adres is op het domein dat u via SMTP heeft geverifieerd.

Oorzaken die vaak over het hoofd worden gezien

  • Een cacheplugin die de webhook blokkeert. De betaalprovider meldt “betaald” via een verzoek aan uw shop. Als dat verzoek uit een cache komt, wordt de status nooit bijgewerkt en gaat de bevestiging nooit uit.
  • WP-Cron die niet draait. Sommige mails worden uitgesteld verstuurd via de taakplanner van WordPress. Als die niet afgaat, blijven mails in de wachtrij.
  • Een typefout in het klantadres. Banaal, maar kijk het na voordat u uren zoekt.
  • Een mailplugin die in “testmodus” staat en alle mail naar één adres omleidt, vaak vergeten na het inrichten van een staging-omgeving.
  • Een verhuizing. Na een overstap naar een andere host is de oude SMTP-configuratie vaak niet meer geldig, en staat de SPF nog naar de oude server te wijzen.

Wat u zelf doet en wanneer u hulp inschakelt

Laag 1 en de test met uw eigen Gmail-adres kunt u zelf. Een SMTP-plugin instellen met uw zakelijke mail lukt de meeste ondernemers ook, als ze de inloggegevens hebben. Schakel hulp in bij DNS-records (een fout daar kan ook uw gewone zakelijke mail raken), bij een webhook die niet doorkomt en bij alles waarvoor u op de server moet zijn.

Een meubelwebshop uit Breda had dit een half jaar: ongeveer een op de vijf orderbevestigingen kwam niet aan. Het bleek een combinatie van PHP-mail zonder SPF en een host die uitgaande mail beperkte tot vijftig per uur; op drukke dagen vielen mails er gewoon af. Overstappen op een transactionele maildienst en de DNS-records op orde brengen loste het definitief op. Sindsdien controleren wij het maillog maandelijks als onderdeel van het onderhoud van hun WooCommerce-shop, omdat dit precies het soort probleem is dat stil terugkomt.

Volgende stap: plaats een testbestelling naar een Gmail-adres en bekijk de originele mail. Binnen vijf minuten weet u in welke van de drie lagen het probleem zit.