Get the next one in your inbox.
One email when we publish something worth reading. No spam — appropriately enough, we'd know.
If your WordPress contact form says 'sent' but the email never arrives, the cause is almost always wp_mail() and your host's mail configuration — not the form plugin.
Get an instant summary, key takeaways, action items, and answers to your questions about this article.
WordPress's wp_mail() function defaults to PHP's mail(), which many hosts don't configure to deliver reliably, and which reports success before the email is actually delivered. Connecting an authenticated SMTP provider, or a form backend that handles SMTP for you, fixes delivery reliably.
This is one of the most common WordPress support threads there is: a contact form shows a success message, but the email never shows up — not in the inbox, not in spam, nowhere. The form itself is almost never the problem; the mail delivery underneath it is.
WordPress's built-in wp_mail() function, which most contact form plugins call to actually send the email, defaults to PHP's mail() function unless something has explicitly configured it otherwise. That depends on the server having a properly configured local mail transfer agent (MTA) — and on shared hosting in particular, that's frequently not set up at all, rate-limited, or blocked outright by the host to control abuse from other customers on the same server.
Critically, mail() reports success back to WordPress the moment it hands the message to the local mail system — not once it's actually been delivered. So a form can genuinely show "message sent" while the email is dropped, rejected, or silently swallowed several steps later, with no error surfaced anywhere in wp-admin.
Even when the message does leave the server, it commonly lacks proper SPF/DKIM authentication for the sending domain, so receiving mail servers (Gmail, Outlook, and so on) quietly file it as spam or reject it outright — which looks identical to "never sent" from the site owner's side.
The reliable fix is to stop relying on the server's local mail() function and send through an authenticated SMTP connection instead — either a transactional email provider (SendGrid, Postmark, Amazon SES, Google Workspace, and similar) configured directly, or a form backend that handles that connection for you.
If you're already moving your form logic to FormBridge, this is built in rather than a separate step: notifications and autoresponders send through FormBridge's infrastructure by default, and if you want mail to originate from your own domain, add your SMTP host, port, encryption, username, and password once under Account → SMTP Configurations and assign it to the form — no server-level mail configuration to debug.
Check the form's own activity log first — FormBridge shows a per-submission log (received → spam-checked → notified → auto-responded) — rather than just the inbox. If "notified" never fires, the issue is upstream of delivery. If it fires but nothing arrives, it's the receiving side filtering the message, which points back to sender authentication.
PHP's mail() function, which wp_mail() calls by default, reports success as soon as it hands the message to the local mail system — not once it has actually been delivered — so failures downstream are never surfaced back to WordPress.
Usually not by itself — most form plugins call the same wp_mail() function underneath, so the mail delivery problem persists until an authenticated SMTP connection replaces the server's local mail() function.
One email when we publish something worth reading. No spam — appropriately enough, we'd know.