`wp_mail()` Silently Fails and Zero Emails Arrive? Your Managed Host Disabled PHP `mail()`

A WordPress site I maintain had a simple contact form: a visitor fills in name, email, message, hits send, and the handler calls wp_mail() to notify the client's inbox. It worked locally. It worked on staging. Then in production, for several days, not a single lead came through. Not a few — zero. The form looked successful to the visitor, the thank-you page appeared, but the email never arrived. Those leads just vanished.

What made this maddening was the total absence of errors. No PHP fatal, no notice, no red message on screen. The error_log was clean. The form returned a success state to the browser. From the outside, everything looked healthy. The only evidence anything was wrong was the client's empty inbox, and that only surfaced when she asked why no prospects were reaching her through the site.

The symptom

I started with the easiest thing to check. I submitted a test through the form myself: the success page rendered, the email did not arrive. I checked the spam folder — empty. I checked error_log again — genuinely clean. Since wp_mail() returns a boolean, I added logging around the call to see what it was actually reporting:

$sent = wp_mail( $to, $subject, $body, $headers );
error_log( '[contact] wp_mail returned: ' . var_export( $sent, true ) );

The result confused me for a moment: wp_mail returned: false. So WordPress itself knew delivery had failed, but it failed silently, throwing nothing up the stack. The false return was the only signal, and nobody was catching it. That is exactly why the form felt successful while no email ever went out.

Tracing the root cause

A false return from wp_mail() means the PHPMailer underneath failed to hand the message to any transport. By default, wp_mail() uses PHP's native mail() function, which on most servers shells out to a local sendmail binary. So the question narrowed: can mail() on this server actually send anything?

I wrote a tiny probe script to test it directly, bypassing the entire WordPress layer:

<?php
$ok = mail( 'test@example.com', 'probe', 'body' );
var_dump( $ok );

It returned bool(false). That is where the puzzle came apart. This site is on a managed host, and managed hosts like Kinsta deliberately disable PHP's mail() function at the server level. Their reasoning makes sense from their side: unauthenticated mail() is a spam magnet and a deliverability liability, so they require sending through authenticated SMTP instead. The consequence is that wp_mail()'s default transport, which relies on sendmail, has nothing to hand the message to. PHPMailer tries, finds no destination, and fails — without surfacing a friendly error, because from WordPress's side this is "just" a false return.

So this was not a bug in my code. My code was correct for an environment that has mail(). The problem was an assumption I carried in: that wp_mail() always has a working transport. On a managed host, that assumption is wrong.

The fix

I fixed two things, and the order matters. The bigger lesson is not about SMTP — it is about never making email your only lead storage.

The first and most important fix: make lead capture independent of email entirely. I changed the handler to persist every submission to the database as its own custom post type, using wp_insert_post(), as the durable source of truth. If email fails, the lead is still stored safely in the database:

$inquiry_id = wp_insert_post( array(
    'post_type'   => 'inquiry',
    'post_status' => 'private',
    'post_title'  => sanitize_text_field( $name ) . ' - ' . current_time( 'Y-m-d H:i' ),
    'meta_input'  => array(
        'email'   => sanitize_email( $email ),
        'message' => sanitize_textarea_field( $message ),
    ),
) );

The second fix: configure a proper SMTP transport as a notification layer on top of that storage, not as a replacement for it. The fastest and most reliable route is the WP Mail SMTP plugin with an authenticated account. I used Gmail with a dedicated App Password, not the real account password. Once SMTP is in place, wp_mail() has a legitimate transport and starts sending again — but now that delivery is a bonus layer, not the sole support:

// wp_insert_post() already stored the lead. Email is only a notification.
$notified = wp_mail( $to, $subject, $body, $headers );
if ( ! $notified ) {
    error_log( '[contact] notification failed, but inquiry #' . $inquiry_id . ' is safe in the DB' );
}

With this pattern, even if SMTP breaks again someday, no lead is lost. The client can open the inquiry list in the admin dashboard at any time, and email just speeds up how quickly she learns one came in.

Checklist

• If wp_mail() returns false with no error, suspect the transport, not your form code.
• Test mail() directly with a tiny probe script; if it returns false, the host is likely blocking it.
• Remember that managed hosts like Kinsta disable PHP mail() and require authenticated SMTP.
• Configure SMTP via WP Mail SMTP with an authenticated account (e.g. a Gmail App Password), not the real account password.
• Persist every submission to the database via wp_insert_post() as the source of truth, then layer email notification on top.
• Never make email your only lead storage. Dual storage means leads never vanish even when email fails.