Why WordPress email failures are hard to diagnose without the right tools #
When a WordPress site stops sending emails (WooCommerce order confirmations, Contact Form notifications, user registration emails, password reset links), the failure is almost always invisible. The site appears to process the action successfully. The customer sees a confirmation. The order goes through. The form submits. Nothing in the browser indicates a problem. The email just never arrives.
This is because WordPress’s email function (wp_mail) fires on the server, after the browser’s interaction with the page is complete. Any failure in the email pipeline produces no front-end signal. Without server-side capture, you’re debugging a problem you can’t see from the browser at all.
What Loupely captures from the email pipeline #
The Loupely WordPress Plugin instruments wp_mail and captures the following when an email event fires during a diagnostic session:
- Whether wp_mail was called at all (confirming the email was attempted)
- The result of the wp_mail call (success or failure at the PHP level)
- Any PHP Errors that fired during the wp_mail execution
- Whether a third-party SMTP plugin intercepted the call (and which one)
- The “to” address and subject line of the email that was attempted
What Loupely doesn’t capture: whether the email was accepted by the receiving mail server, whether it was filtered into spam, or whether it was delivered to the inbox. Those events happen outside WordPress’s control and outside the server-side capture layer. Loupely captures the WordPress side of the email pipeline.
The 3 email failure patterns Loupely identifies #
wp_mail was called but returned false #
wp_mail fired, but PHP reported a failure. This almost always means the underlying mail transport (the PHP Mail() function or an SMTP plugin) rejected or failed to send the message. The most common cause on shared hosting is that the server’s PHP Mail() function is disabled or misconfigured. The triage step for this pattern points to either configuring an SMTP plugin or contacting your hosting provider about their outgoing mail configuration.
wp_mail was not called at all #
The action that should have triggered an email (an order placed, a form submitted, a user registered) completed without wp_mail being called. This means something in the WordPress execution chain prevented the email hook from firing. A plugin conflict on the hook, a custom filter that removed the email action, or a WooCommerce email setting that disabled the notification type are all common causes. The triage step for this pattern focuses on the Hook Execution data to identify which plugin or filter interrupted the chain.
wp_mail was called and succeeded, but email isn’t arriving #
PHP reports success, but the email never reaches the inbox. This is outside Loupely’s capture layer: it means the email left WordPress successfully but was rejected by the receiving server, filtered as spam, or lost in transit. The triage step for this pattern points to email authentication (SPF, DKIM, and DMARC records on your domain) and to SMTP plugin configuration for improved deliverability. Loupely captures the evidence that confirms the WordPress side is working, which narrows the problem to the delivery layer.