Why wp_mail() silently eats your form notifications — and how to fix it for free

You build a contact form. You submit it. The "Thank you" message shows up. Everything looks fine.

Three weeks later a client mentions they never heard back. You check WordPress — the submission is right there in the database. The form worked. The email didn't.

This is one of those bugs that stays invisible until it costs you something, and it's far more common than it should be.

Why it happens

When WordPress calls wp_mail(), it hands the message to PHP's built-in mail() function, which asks your web server to deliver it directly. On a dedicated server with a properly configured MTA, this works. On the shared hosting plans that most WordPress sites actually run on, three things go wrong:

1. No authentication. Gmail, Outlook, and corporate mail servers expect email from an authenticated sender. A bare mail() call carries none, so it lands in spam or gets rejected outright.
2. No SPF or DKIM. These DNS records tell the world which servers are allowed to send for your domain. Shared hosts send for hundreds of domains and can't be listed in everyone's SPF. Result: soft fail → spam folder.
3. Silent failure. mail() returns true when it hands the message to the local mail daemon — not when the message actually arrives. If it bounces later, WordPress never finds out. No log, no error, no trace.

The ugly part: you can have a contact form running for months, fully "working," with half the notification emails going nowhere — and you'd have no idea.

The fix: a dedicated SMTP service

SMTP replaces the guesswork with a proper handshake. You authenticate with a service that has managed IP reputation and DNS records, and you get a delivery log you can actually read. The good news: the free tiers are generous enough that most small sites never need to pay.

Here's the short version of the comparison:

For most WordPress sites with a contact form, Brevo is the right starting point — 300 emails per day, no credit card, five-minute setup. If deliverability matters most (bookings, payment confirmations), go with Mailgun. If you're still building or testing, start with Mailtrap — its sandbox catches every outgoing email and shows you the full render before a real inbox ever sees it.

How to tell if you're affected

Before you sign up for anything, confirm you actually have a problem. If you use a form plugin that has a built-in email test (CraftForms has one under SMTP Servers — send a test email, get a 6-digit code, enter it to confirm), run that first. If the email arrives, your default mail works and you can stop here.

If it doesn't — or if you've had the "I never got your email" conversation even once — set up SMTP. Ten minutes now saves weeks of missed emails later.

---

I wrote the full walkthrough — all six providers compared in detail, step-by-step setup, email logging, and how to route different form actions through different SMTP servers — on my blog:

👉 Best Free SMTP for WordPress — Setup Guide

Disclosure: I build CraftForms, the form plugin I used for the examples. The SMTP providers and the underlying wp_mail() problem are the same regardless of which plugin you use.