WooCommerce bestel- en transactionele e-mails worden niet verstuurd

Het symptoom: klanten krijgen geen bestelmails

Een klant plaatst een bestelling in je WooCommerce-winkel, betaalt, en krijgt vervolgens geen bevestiging. De beheerder-notificatie komt ook niet binnen. De bestelling staat wél in de admin, de betaling is via de payment gateway gegaan, maar aan beide kanten blijft de inbox leeg. Soms werkt één type mail (wachtwoord-resets) en een ander type niet (bestelbevestigingen). Soms laat de mail-log-plugin zien dat het bericht "verzonden" is, en toch komt er niks binnen in Gmail.

Wat dit symptoom eigenlijk betekent

WooCommerce heeft geen eigen e-mail-verzendstack. Elk transactioneel bericht, van "Bedankt voor je bestelling" tot de admin-melding "Nieuwe bestelling", wordt opgebouwd door een klasse die overerft van WC_Email en uiteindelijk doorgegeven aan WordPress' wp_mail()-functie. De WooCommerce Email FAQ is daar letterlijk over: "WooCommerce triggers the wp_mail() function. This function signals WordPress to process the email. However, since WordPress isn't an email server, it delegates this task to PHP."

Een ontbrekende WooCommerce-bestelmail is daarom eigenlijk één van vier faalmodes, en je moet eerst weten welke voordat je iets kunt fixen:

1. WooCommerce triggert de mail nooit. De bestelling is nooit in de status terechtgekomen die de trigger afvuurt (de meest voorkomende echte oorzaak is een order die in "In afwachting van betaling" blijft hangen), de mail staat uit in de instellingen, of een plugin-conflict breekt de hook-chain.
2. WooCommerce triggert de mail wél, maar wp_mail() wordt nooit daadwerkelijk aangeroepen. Er staat een achtergrond-queue aan, WP-Cron is stuk, en de queued action wordt stilletjes als "completed" gemarkeerd zonder dat de mail ooit is verstuurd. Of een HPOS-incompatibele plugin hangt aan het oude order-save-pad en vuurt helemaal niet meer bij moderne orders.
3. wp_mail() wordt aangeroepen en komt foutloos terug, maar de host levert het bericht nooit af. Dat is een WordPress-level probleem, geen WooCommerce-probleem. De fix is identiek aan waarom WordPress geen e-mail verstuurt en hoe je het oplost.
4. Het bericht verlaat de host wel, maar faalt bij de authenticatie aan ontvangerszijde. SPF, DKIM of DMARC wijst het af. Ook een WordPress-level probleem.

Als je de eerste twee lagen overslaat en meteen naar "het zal SMTP wel zijn" springt, verlies je uren aan een probleem dat in werkelijkheid een uitgevinkt checkbox of een pending-bestelling was. Werk ze dus in volgorde door.

Veelvoorkomende oorzaken, op volgorde van waarschijnlijkheid

Op een winkel waar de mails tot voor kort gewoon uitgingen, is de echte volgorde meestal:

1. De bestelling blijft hangen in In afwachting van betaling. Dat is by design: voor pending-orders wordt geen klantbevestiging verstuurd. Veruit de meest gerapporteerde "bug" die er geen is.
2. De IPN of webhook van de payment gateway heeft de site nooit bereikt, waardoor de bestelling nooit naar "Verwerking" is gegaan, waardoor de mail "Bestelling in verwerking" nooit afgevuurd is.
3. wp_mail() zelf is stuk op WordPress- of hostingniveau. WooCommerce is dan slachtoffer, niet oorzaak.
4. HPOS is aangezet en een oudere mail-gerelateerde plugin hangt aan save_post_shop_order, wat HPOS-orders niet meer triggeren.
5. De achtergrond-mailqueue staat aan, WP-Cron doet het niet op de server, en queued berichten worden stilletjes als "done" weggezet.
6. Het vinkje "Schakel deze e-mailmelding in" staat per ongeluk uit, omdat iemand de instellingen heeft aangepast of een plugin/thema-update aan de mail-opties heeft gezeten.
7. WooCommerce 9.5 heeft een nieuwe klant-failed-order-mail toegevoegd. Na de upgrade zagen sommige winkels nieuwe mails verschijnen die ze niet verwachtten, zijn ze dingen gaan aanpassen, en hebben ze per ongeluk legitieme mails uitgezet.

Diagnose: achterhaal welke laag faalt

Doorloop deze checks op volgorde. Elke stap is non-destructief.

Stap 1: kijk vóór alles naar de orderstatus

Open WooCommerce > Bestellingen en zoek de bestelling waar het om gaat. Kijk naar de kolom Status.

• Verwerking: de gateway heeft de betaling bevestigd, WooCommerce had zowel de klantmail "Bestelling in verwerking" als de beheerdermail "Nieuwe bestelling" moeten afvuren. Door naar stap 2.
• Voltooid: zelfde als hierboven, plus de klantmail "Bestelling voltooid". Door naar stap 2.
• Mislukt: vanaf WooCommerce 9.5 horen zowel de beheerder als de klant een "Mislukte bestelling"-melding te krijgen. Door naar stap 2.
• In afwachting van betaling: stop. Dit is hoe het hoort. De WooCommerce Email FAQ zegt het expliciet: "If your new orders have a Pending Payment status, no email will be sent." Een pending-order betekent dat de gateway de betaling nooit heeft bevestigd. Spring naar de payment-gateway-sectie verderop.
• In de wacht: de klant had een "Bestelling in de wacht"-mail moeten krijgen. Check in stap 2 alleen dat specifieke maitype.

Je weet dat deze stap klaar is als: je precies kunt benoemen in welke status de bestelling staat én welke mail op basis van die status had moeten afvuren.

Stap 2: controleer of de mail daadwerkelijk aanstaat in WooCommerce-instellingen

Ga naar WooCommerce > Instellingen > E-mails. Je ziet een tabel met elk geregistreerd mailtype: Nieuwe bestelling, Geannuleerde bestelling, Mislukte bestelling, Bestelling in de wacht, Bestelling in verwerking, Bestelling voltooid, Terugbetaling, Klantfactuur, Klantnotitie, Wachtwoord herstellen, Nieuw account. Bij elke rij zit een beheer-knop.

Klik op de mail die je verwacht (voor een klantbevestiging van een betaalde bestelling is dat Bestelling in verwerking). Controleer:

• Het vinkje Inschakelen/uitschakelen bovenin staat aan.
• Het veld Ontvanger(s) klopt (voor klantmails blijft dit leeg, want WooCommerce pakt dan het factuur-e-mailadres van de bestelling; voor admin-mails moet daar een echt adres staan, meestal de shop-eigenaar).
• De From-naam en het From-adres onder Instellingen > E-mails > E-mail sender options zijn echt en staan op een domein waarvandaan je ook daadwerkelijk verstuurt.

Je weet dat dit werkt als: elke betrokken mail "Ingeschakeld" toont in de beheerweergave en de ontvanger-velden er goed uitzien. Sla het formulier ook op als je niks hebt gewijzigd. Ik heb winkels gezien waar het vinkje wel aanstond, maar de optie pas na een re-save daadwerkelijk naar de database werd weggeschreven.

Stap 3: stuur een handmatige test en vang hem met een mail-logger

Installeer Check & Log Email als je dat nog niet hebt. Je hebt een log nodig van elke wp_mail()-aanroep die WordPress verlaat, of WooCommerce die nou triggerde of niet.

Trigger nu de echte mail vanuit een bekende status. De schoonste manier om dat te doen zonder een echte testbestelling te plaatsen, is de "Opnieuw versturen"-actie van WooCommerce zelf:

1. Open WooCommerce > Bestellingen, klik op een getroffen bestelling.
2. Kies in het vakje Bestelacties rechts in het dropdown-menu Nieuwe bestelling-notificatie opnieuw versturen (of het relevante maitype) en klik op update/verzend.
3. Controleer het log van Check & Log Email.

Drie uitkomsten vertellen je welke laag het probleem is:

• Het log toont een rij met status "Sent" en de mail komt ook daadwerkelijk in de inbox aan. De WooCommerce-trigger, het WordPress-transport én de authenticatie bij de ontvanger werken allemaal. De oorspronkelijk missende mail was dan óf een eenmalige hiccup, óf hangt aan een statusovergang die nooit heeft plaatsgevonden.
• Het log toont een rij met status "Sent" maar er komt niks aan. wp_mail() is aangeroepen en kwam zonder exception terug, maar de host of de ontvanger heeft het bericht laten vallen. Dat is een transport- of deliverability-probleem, geen WooCommerce-probleem. Zie waarom WordPress geen e-mail verstuurt om de WordPress/hosting/DNS-laag te diagnosticeren.
• Het log is leeg. WooCommerce heeft wel getriggerd (de "Opnieuw versturen"-actie is onvoorwaardelijk) maar wp_mail() is nooit bereikt. Iets onderschept de aanroep voor hij WooCommerce verlaat. Dat wijst op HPOS, de achtergrond-queue, of een plugin die woocommerce_mail_callback wegfiltert.

Je weet dat deze stap klaar is als: je één van die drie uitkomsten kunt aanwijzen. Die uitkomst vertelt je welke sectie hieronder je moet toepassen.

Oplossingen per oorzaak

Orders blijven "In afwachting van betaling" en er gaat geen mail uit

Dit is de meest voorkomende non-bug in WooCommerce-mailtickets. De mail "Bestelling in verwerking" vuurt op de hook woocommerce_order_status_pending_to_processing_notification, en die vuurt alleen als een bestelling van Pending naar Processing overgaat. Die overgang wordt niet door WooCommerce zelf gedaan maar door de payment gateway, nadat die de betaling heeft bevestigd.

Gangbare redenen dat een bestelling in Pending blijft:

• De klant heeft het tabblad gesloten voordat de betaalredirect was afgerond (PayPal, iDEAL, Stripe Checkout).
• De kaart is geweigerd, maar de gateway heeft de order niet op Failed gezet.
• De IPN van de gateway (PayPal) of de webhook (Stripe, Mollie, Adyen) heeft je site niet bereikt. Gebruikelijke oorzaken: een firewallregel, HTTP Basic Auth op de site, een verkeerd ingestelde callback-URL in het gateway-dashboard, of de site zit nog achter een staging-wachtwoord.
• De gateway kreeg een timeout, of de site gaf kort een 500 tijdens de callback.

Hoe je het oplost:

1. Open het dashboard van de gateway (Stripe, Mollie, PayPal, Adyen, etc.) en kijk in het recente transacties- of webhooks-log. Je zoekt mislukte webhook-aanroepen naar jouw site. Het log van de gateway laat meestal de HTTP-status zien die hij terugkreeg.
2. Rapporteert de gateway dat de webhook mislukte: fix het bereikbaarheidsprobleem (haal basic auth eraf, whitelist de gateway-IP-ranges in je firewall, corrigeer de callback-URL).
3. Zodra het callback-pad weer werkt, kun je meestal in het gateway-dashboard de webhook voor de blijven hangen bestellingen "retryen" of "opnieuw versturen". Zodra WooCommerce hem binnenkrijgt gaat de order naar Processing en vuurt de klantbevestiging automatisch.
4. Voor bestellingen waar de klant de betaalflow bewust heeft afgebroken: stuur geen "neppe" bevestiging. Stel in plaats daarvan de Voorraad vasthouden (minuten) onder WooCommerce > Instellingen > Producten > Voorraad in, zodat pending-orders automatisch vervallen na een redelijke termijn (60 tot 120 minuten werkt voor de meeste winkels).

Je weet dat het werkt als: het gateway-dashboard geen mislukte webhooks meer toont voor recente bestellingen, nieuwe betaalde orders vanzelf op "Verwerking" landen en de klantbevestiging zonder handmatige tussenkomst binnenkomt.

De mail staat uit, de ontvanger klopt niet, of het From-adres is onbereikbaar

Dit klinkt te basaal om de echte oorzaak te zijn, maar bij ongeveer één op de vijf tickets is het dat wel. Een thema-update, een plugin-conflict, of iemand die de instellingen "even opruimt" kan een maitype uitzetten. En het standaard From-adres waar WooCommerce mee komt is wordpress@<server-hostname>, wat bij elke fatsoenlijke inbox-provider tegen DMARC aanloopt.

1. Ga naar WooCommerce > Instellingen > E-mails. Zet elk maitype aan dat je nodig hebt.
2. Voor de admin-mails (Nieuwe bestelling, Geannuleerde bestelling, Mislukte bestelling): zet een echt, gemonitord adres als ontvanger. Geen distributielijst die stiekem bouncet.
3. Helemaal onderaan onder E-mail sender options: zet de "From"-naam en het "From"-adres op een postvak dat je op je eigen domein beheert. Niet wordpress@jouwsite.nl, niet je persoonlijke Gmail. Heb je nog geen postvak op je verzenddomein? Maak eerst bestellingen@jouwsite.nl of noreply@jouwsite.nl aan.

Je weet dat het werkt als: het From-adres onder E-mail sender options op hetzelfde domein als je site staat, elk maitype dat je nodig hebt op "Ingeschakeld" staat, en een resend-test (stap 3 van de diagnose) in Check & Log Email een rij produceert met het nieuwe From-adres.

De HPOS-migratievalkuil: oude plugins missen nieuwe orders

High Performance Order Storage (HPOS) vervangt de oude wp_posts/wp_postmeta-opslag voor WooCommerce-orders door dedicated tabellen (_wc_orders, _wc_order_addresses, _wc_order_operational_data, _wc_orders_meta). HPOS werd voor het eerst als opt-in-feature aangeboden in WooCommerce 7.1 (november 2022), en is stabiel verklaard en standaard aangezet alleen voor nieuwe installs in WooCommerce 8.2 (oktober 2023). Bestaande winkels worden niet automatisch gemigreerd. Die moeten zelf opt-in.

Die geschiedenis is relevant voor mail-debugging omdat de faalmode heel specifiek is: plugins die aan save_post of save_post_shop_order hangen (een veelvoorkomend patroon bij oudere mail-log- en notificatie-plugins) krijgen geen signaal meer wanneer een HPOS-order wordt opgeslagen. De plugin stopt stilletjes met werken. Symptomen op een winkel die net op HPOS is overgegaan:

• Bestellingen blijven gewoon binnenkomen. De checkout werkt nog. De admin toont de orders gewoon.
• De mail-log-plugin stopt met registreren van WooCommerce-mails na de HPOS-cutover.
• Custom notificatie-plugins die order-data direct met get_post_meta() uitlezen, krijgen verouderde of lege data terug.
• De "laatste verzending"-timestamp van de Email Log-plugin staat bevroren op de dag vóór HPOS aanging.

Hoe je het oplost:

1. Open WooCommerce > Instellingen > Geavanceerd > Features en kijk naar de HPOS-rij. Die toont of HPOS actief is en, belangrijker, welke "incompatibele plugins" hem blokkeren of geen support declareren.
2. Voor elke plugin in die lijst: check de changelog of repo van de plugin voor een HPOS-compatibiliteits-release. De officiële richtlijn is om compatibiliteit te declareren via \Automattic\WooCommerce\Utilities\FeaturesUtil::declare_compatibility() en CRUD-methodes ($order->get_meta(), $order->update_meta_data()) te gebruiken in plaats van get_post_meta().
3. Update elke plugin naar de versie die HPOS-compatibiliteit declareert. Is een plugin niet bijgewerkt en verlaten? Vervang hem. FluentSMTP, WP Mail SMTP, Post SMTP en Check & Log Email ondersteunen HPOS al ruim.
4. Moet je tijdelijk tóch een HPOS-incompatibele mail-plugin draaien, dan kun je WooCommerce in "Compatibiliteitsmodus" houden, waarin zowel de oude posts-tabel als de nieuwe HPOS-tabellen in sync worden gehouden. Dat is trager en is een noodoplossing, geen eindstation. Zet "Compatibiliteitsmodus" pas uit als elke mail-gerelateerde plugin bekend-compatibel is.

Je weet dat het werkt als: WooCommerce > Instellingen > Geavanceerd > Features geen incompatibele plugins meer toont en een nieuwe testbestelling een log-regel produceert in zowel Check & Log Email als je notificatie-plugin.

De achtergrond-mailqueue dropt berichten zonder waarschuwing

WooCommerce heeft het filter woocommerce_defer_transactional_emails. Als een plugin of snippet true teruggeeft op dat filter, stopt WooCommerce met het inline versturen van transactionele mails tijdens de request en duwt ze in plaats daarvan in WC_Background_Emailer, die WordPress Action Scheduler (en dus WP-Cron) gebruikt om ze op een latere request te dispatchen. De tradeoff: de checkout-pagina is sneller, maar als WP-Cron op de server stuk is worden de queued jobs stilletjes als "completed" weggeschreven zonder ooit een mail te versturen. Geen exception, geen error-log. De queue laat de action als "completed" zien, en de klant krijgt niks.

Zo check je of dit jou raakt:

1. Ga naar WooCommerce > Status > Geplande acties en filter op de hook woocommerce_send_queued_transactional_email. Recente acties horen op "Compleet" te staan, met een recente timestamp.
2. Zie je veel In afwachting-acties die nooit naar Compleet opschuiven, dan zit Action Scheduler zelf vast, bijna altijd omdat WP-Cron stuk is. Test WP-Cron door jouwsite.nl/wp-cron.php?doing_wp_cron in een browser te openen. Die hoort binnen een seconde of twee een bijna-lege pagina terug te geven.
3. Is WP-Cron stuk, zet dan de kapotte in-HTTP-cron uit en configureer een echte server-cron die wp-cron.php elke minuut aanroept. Open eerst wp-config.php in de bestandsbeheerder van je hostingpaneel (of download het via SFTP) en voeg deze regel toe boven het /* That's all, stop editing! */-commentaar:

define( 'DISABLE_WP_CRON', true );

Voeg daarna een cronjob toe in het hostingpaneel (meestal onder "Geplande taken" of "Cron Jobs" in cPanel/Plesk) die elke minuut draait met het commando:

wget -q -O - https://jouwsite.nl/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Heb je SSH-toegang? Dan kun je dit ook direct aan je crontab toevoegen:

* * * * * wget -q -O - https://jouwsite.nl/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Als je WP-Cron niet meteen kunt fixen, is de snelste workaround om transactionele mail gewoon niet meer te deferreren. WooCommerce stuurt dan weer synchroon. Maak een bestand disable-wc-email-defer.php aan in wp-content/mu-plugins/ via de bestandsbeheerder van je hostingpaneel of een SFTP-client, met deze inhoud:

<?php
// wp-content/mu-plugins/disable-wc-email-defer.php
add_filter( 'woocommerce_defer_transactional_emails', '__return_false' );

Dit brengt het oude gedrag terug: mails gaan tijdens de checkout-request uit, ten koste van een iets tragere bedankpagina. Op een winkel met weinig volume is dat prima. Op een drukke winkel: fix WP-Cron, en laat deferring aan.

Je weet dat het werkt als: WooCommerce > Status > Geplande acties laat zien dat woocommerce_send_queued_transactional_email op tijd draait, en Check & Log Email registreert echte sends voor elke nieuwe testbestelling.

Payment-gateway-gerelateerde mailproblemen

Bestelmails hangen aan orderstatussen. Orderstatussen hangen aan de payment gateway. Is de gateway verkeerd ingesteld, dan blijven orders in Pending steken en vuurt er geen klantmail. Dit is dezelfde faalklasse als de pending-sectie hierboven, maar de gateway-side-checks zijn het apart noemen waard:

• Stripe: open Developers > Webhooks in het Stripe-dashboard. De endpoint die naar /?wc-api=wc_stripe wijst hoort recente succesvolle deliveries te tonen. Zie je 401 of 403, dan blokkeert de site Stripe's IP's of staat er basic auth voor de site.
• PayPal Standard: IPN moet aan staan op account-niveau in PayPal, en je IPN-URL onder Profile > Instant payment notifications moet wijzen naar https://jouwsite.nl/?wc-api=WC_Gateway_Paypal. PayPal logt IPN-pogingen onder IPN History.
• Mollie, Adyen, Buckaroo, MultiSafepay, Sisow: elk heeft z'n eigen webhook-URL in het gateway-dashboard, meestal van de vorm /?wc-api=<gateway_name>. Kijk in het delivery-log van de gateway naar 4xx- of 5xx-responses.
• Handmatige bankoverschrijving: orders blijven terecht in "In de wacht" staan totdat jij ze handmatig als verwerkt markeert. De klantmail "In de wacht" vuurt bij de overgang naar On-hold, niet bij Processing. Wil je dat klanten sneller een bevestiging krijgen, zet dan specifiek dat maitype aan.

Je weet dat het werkt als: het gateway-dashboard voor recente orders succesvolle webhook-aflevering toont, de orders zonder handmatig ingrijpen naar Processing gaan, en de mails automatisch uitgaan.

SMTP-configuratie voor WooCommerce

Er is geen WooCommerce-specifieke SMTP-configuratie. WooCommerce erft gewoon wat er op WordPress-niveau is ingesteld. Zodra je een SMTP-plugin in WordPress installeert en configureert, lopen álle WooCommerce-mails er automatisch doorheen, zonder extra stappen.

Voor de volledige walkthrough van het installeren van een plugin, het kiezen van een verzendprovider (Gmail, SendGrid, Mailgun, Amazon SES, Postmark) en het end-to-end verifiëren van bezorging, zie WordPress SMTP-configuratie. Als je die walkthrough hebt doorlopen, hoort een WooCommerce-testbestelling een logregel te produceren in het log van de SMTP-plugin, met hetzelfde From-adres dat je daar hebt ingesteld.

Eén WooCommerce-specifieke opmerking: draai je een winkel met hoog volume die zowel transactionele mail als marketing-mail verstuurt, splits die twee dan over verschillende verzendstromen. Gebruik een transactionele provider (Postmark, Amazon SES) voor bestelmails en een aparte stream of subdomein (mail.jouwsite.nl) voor marketing. Een spam-klacht op een nieuwsbrief beschadigt dan niet de deliverability-reputatie van je bestelbevestigingen. Het artikel SPF, DKIM en DMARC voor WordPress e-mail-deliverability behandelt de alignment-eisen als je twee streams draait.

E-mail-logging om bezorgproblemen te diagnosticeren

Een logging-plugin is het verschil tussen "WooCommerce heeft hem niet verstuurd" (wat je kunt bewijzen of ontkrachten) en "niemand weet wat er is gebeurd". Installeer er één op elke WooCommerce-winkel, ook wanneer alles nu naar behoren werkt.

Waar je op let als een klant meldt "ik heb nooit een bestelmail gekregen":

• Er is een log-rij voor de verwachte mail, status "Sent". WooCommerce heeft de mail getriggerd en wp_mail() heeft hem geaccepteerd. Het probleem zit tussen je host en de inbox van de ontvanger. Check de headers van het bericht op het From-adres, kijk in de spam-map van de ontvanger, en laat indien mogelijk de ontvanger in z'n eigen bounce-logs kijken. Een "sent"-status in een WordPress-log bewijst nooit bezorging, alleen dat PHPMailer de overdracht accepteerde. WordPress Trac #23642 documenteert dat wp_mail() true kan retourneren terwijl het versturen op transportniveau is mislukt.
• De log-rij bestaat met status "Failed". De log-plugin heeft een PHPMailer-exception gevangen. Klik op de rij voor de foutmelding. Veelvoorkomend: verlopen API-key bij de SMTP-provider, ongeldig From-adres, of het From-adres is naar iets veranderd dat de provider niet heeft geverifieerd.
• Er is helemaal geen log-rij. wp_mail() is voor deze bestelling nooit aangeroepen. WooCommerce heeft niet getriggerd. Terug naar de "orderstatus"- en "HPOS"-secties.

Op winkels waar omzet aan hangt haak ik daarnaast wp_mail_failed in een must-use plugin, zodat failures ook in wp-content/debug.log belanden, niet alleen in het plugin-log. Dat vangt exceptions die gebeuren voordat de log-plugin ze te zien krijgt. Maak een bestand log-mail-errors.php aan in wp-content/mu-plugins/ via de bestandsbeheerder van je hostingpaneel of een SFTP-client, met deze inhoud:

<?php
// wp-content/mu-plugins/log-mail-errors.php
add_action( 'wp_mail_failed', function ( WP_Error $error ) {
    error_log( 'wp_mail_failed: ' . $error->get_error_message() );
    error_log( print_r( $error->get_error_data(), true ) );
} );

Je kunt debug.log daarna bekijken via de error-log-viewer in je hostingpaneel, of door wp-content/debug.log te openen in de bestandsbeheerder.

Je weet dat het werkt als: elke resend vanuit WooCommerce > Bestellingen binnen een seconde of twee een rij produceert in het plugin-log, met status "Sent" en het juiste From-adres.

Wanneer je moet escaleren

Heb je orderstatus, instellingen, HPOS, de achtergrond-queue en SMTP doorlopen en komen de bestelmails nog steeds niet betrouwbaar aan, verzamel dan het onderstaande voordat je een ticket opent bij je host of ontwikkelaar:

• WooCommerce-versie en WordPress-versie (Tools > Site Health > Info).
• Staat HPOS aan, en zijn er onder Instellingen > Geavanceerd > Features incompatibele plugins gemeld?
• De status van één getroffen bestelling, en of het gateway-dashboard voor die bestelling een geslaagde webhook toont.
• Een screenshot van WooCommerce > Instellingen > E-mails met de betrokken mail als ingeschakeld, mét de sender options onderaan.
• De exacte foutmelding uit wp-content/debug.log (de regel die begint met wp_mail_failed:), als die verschijnt.
• De log-rij voor de getroffen mail uit Check & Log Email of uit het log van je SMTP-plugin, inclusief het From-adres en de ontvanger.
• Een kopie van het log van woocommerce_send_queued_transactional_email onder Scheduled Actions over de afgelopen 24 uur.
• De volledige lijst met actieve plugins (Tools > Site Health > Info > Active Plugins).
• Je huidige SPF-, DKIM- en DMARC-records zoals ze in DNS staan.

Een support-engineer met dat hele pakket kan het probleem meestal in één sessie oplossen. Zonder dat pakket krijg je vooral een paar dagen van heen-en-weer.

Hoe je voorkomt dat het terugkomt

• Route WooCommerce-mail vanaf dag één altijd via een geauthentiseerde SMTP-provider, niet via PHP mail().
• Houd HPOS-compatibiliteit zichtbaar: volg de changelogs van elke mail-gerelateerde plugin op de winkel, zodat je de compatibility-releases ziet landen zodra ze er zijn.
• Draai Action Scheduler op een echte server-cron, niet op WP-Cron over HTTP. De in-HTTP-cron is veruit de meest voorkomende stille failure bij deferred transactionele mail.
• Houd een mail-logger geïnstalleerd met 30 tot 90 dagen retentie. Als een klant klaagt, wil je een log om in te kijken, geen gok om te maken.
• Kijk wekelijks naar het webhook-log van de payment gateway. Mislukte webhooks zijn de leidende oorzaak van orders die in "Pending" blijven hangen en nooit een mail triggeren.
• Laat het WooCommerce-From-adres nooit wijzen naar een postvak waar niemand in kijkt. Een hard bounce op je eigen From-adres sloopt je deliverability voor weken.