Table of Contents
TL;DR
- A WordPress message form has two jobs. Catch the visitor’s submission and store it. Send a copy to the site owner. The first job almost always works. The second job is the one that fails silently.
- The hidden problem is wp_mail. WordPress core uses PHP mail() under the hood, which routes through the host’s sendmail binary. The major mailbox providers blocklist that path on most shared hosts. The message leaves — the inbox never sees it.
- Two fifteen-minute checks split broken forms into two camps. Search the Gmail spam folder for the form’s notification subject. Send a test email from Tools > Site Health. The result picks the fix.
- The fix in most cases is one SMTP plugin connected to a transactional email account. The plugin authenticates with a reputable provider, sends through their IP block, and the deliverability problem disappears.
- AI helps with reading. Paste the SMTP plugin’s "send failed" message into an AI chat for a plain-English summary. AI cannot send a test email for you. You keep the verdict.
A freelance designer I worked with last summer noticed her contact-form inquiries had dropped to nothing for six weeks. The form on her site still submitted. The "Thank you" message still appeared. The emails were going nowhere.
She thought the dry spell was the season. The dry spell was the form.
The same week, the small business owner I help with quarterly cleanup pulled up his WordPress dashboard and asked why customers had stopped emailing. He had assumed the form was working because nobody had complained. Of course nobody had complained.
They had emailed. The emails never arrived.
This piece is the calm answer to a quiet failure. The reason WordPress contact forms drop messages without telling anyone. The two-check diagnosis that runs in fifteen minutes. The fix that costs nothing and lasts for years.
Why does a WordPress contact form silently stop delivering email?
A WordPress contact form has two jobs.
Catch the visitor’s message and store it. The form plugin handles this inside WordPress. The submission lands in the database. The "Thank you" message renders.
The first job almost always works.
Send a copy of the message to the site owner’s inbox. This is where the failure hides. The send-a-copy job depends on a chain that runs from WordPress through PHP through the host’s mail server through the receiving mailbox provider. Any one of the three can drop the message without telling anyone.
The silence is not a bug. The silence is the default behavior of the chain.
PHP’s mail() function returns "true" when the host accepts the message for delivery. The host accepts the message because the host trusts itself. The receiving provider rejects the message because the host’s IP is on a deny-list.
PHP never finds out. WordPress never finds out. The site owner never finds out.
The form is not broken. The path is broken.
What is wp_mail and why does it fail on most hosts?
The wp_mail function is what WordPress uses to send any email it generates.
Contact-form notifications. Password resets. Comment moderation. Woo order confirmations.
Anything that arrives in someone’s inbox from WordPress goes through wp_mail.
Under the hood, wp_mail is a thin wrapper around PHP’s mail() function. PHP’s mail() function asks the host’s local sendmail binary to deliver the message. The local sendmail binary is the program that came with the host’s Linux server, configured by the host years ago, possibly never reviewed since.
The local sendmail binary on a cheap shared host shares its IP with hundreds of other shared sites. Some of those sites send spam. The IP block ends up on Gmail’s deny-list. Gmail rejects every message from that IP block, including the legitimate contact-form notification.
The message leaves WordPress. The receiving mailbox provider rejects it. The site owner sees nothing. The form looks fine.
The honest framing is short. wp_mail is a default that works when the host pre-configures SMTP authentication. It fails silently when the host does not. Most cheap shared hosts do not. Most managed WordPress hosts do, but with limits that the contact form on a busy site exceeds without warning.
Which two checks should you run first?
Two checks isolate the failure in fifteen minutes.
Test the form yourself with a personal email address. Open Gmail and check the spam folder for the form’s notification subject line.
If the message lands in spam, the message is leaving the host. The receiving provider is filtering it. The SMTP fix below is the one you need.
Send a test email from the WordPress admin under Tools > Site Health, or use a free plugin like Check & Log Email. If the test email never arrives anywhere, the message is being blocked at the host or rejected by every provider.
Not the inbox, not the spam folder, nowhere. Still an SMTP problem. The urgency is higher because the failure is total.
The two checks split the population of broken forms into two camps with different fixes. The spam-filtered camp wins by switching to a real SMTP path. The total-block camp wins the same way but with a more careful provider choice.
Gmail’s free tier may not be enough. Brevo or Mailgun’s paid tier might be.
The two-check pattern saves the most time. The owner who skips it ends up reinstalling the form plugin three times before realizing the form was never the problem.
How does an SMTP plugin actually fix the problem?
An SMTP plugin replaces wp_mail behavior. WP Mail SMTP, Fluent SMTP, and Post SMTP are the long-running names. The wordpress.org plugin directory carries others.
Instead of asking the host’s local sendmail binary, the plugin authenticates with a real email account on a transactional email service.
Brevo. SendGrid. Mailgun. Amazon SES.
A Google Workspace mailbox the site owner already controls. The plugin signs the message with the account’s credentials and sends through the provider’s reputable IP block.
The receiving provider sees the message arriving from a known sender. A proper DKIM signature. An SPF record that matches the sending domain. An IP block that has not been on a deny-list for years.
The deliverability problem disappears.
The plugin is configuration, not code. The setup is a fifteen-minute job following the plugin’s wizard. The hardest step is creating the account on the transactional service, and the wizard walks through it. The provider’s free tier covers most small-site volumes — a small business with hundreds of contact-form submissions a month still pays nothing.
The fix lasts for years. The setup happens once. The maintenance is checking the dashboard every quarter to confirm the messages are still being sent.
What does the spam-folder check look like on a real client?
A small-business owner calls. The contact form on her site is broken. Nobody is reaching her.
The form submits cleanly when tested. The "Thank you" message appears. The notification email never arrives in her Gmail inbox. She has assumed the form was the problem.
The spam folder of the same Gmail inbox has 47 unread messages from her own contact form. Six weeks of inquiries. New customers. Existing customers asking follow-up questions.
One press inquiry from a regional newspaper. All of them filtered into spam by the receiving provider because the host’s mail path was on a deny-list.
An SMTP plugin reconfigured to send through her existing Brevo account fixes the deliverability problem in twenty minutes. The next test message arrives in the inbox without a detour.
The 47 messages also get answered. She sends a short apology to each contact, explaining the technical issue and offering a fifteen-minute call to anyone still interested. Eleven of the 47 are still interested. Three become paying clients within the month.
The cost of the silent failure was not the technical fix. The cost was the six weeks of unanswered inquiries. The fix was free. The damage was paid for in lost work.
When is the plugin the problem instead of the email path?
Three signs point to the plugin layer rather than the email path.
The form does not submit at all. The submit button shows a loading spinner forever. The submit button returns a generic error message. The browser console shows a JavaScript error.
None of these are email-delivery failures. The plugin is broken or the plugin is conflicting with another plugin.
The form submits but the success message never appears. The page reloads with no acknowledgment. The submission may or may not have been saved. The plugin is partially broken.
The form submits and the success message appears, but the form does not save the submission anywhere. No entry in the form plugin’s submissions screen. No entry in the database. No email anywhere.
The third case is the abandoned-plugin case more often than not.
Sort the Plugins screen by Last Updated. If the contact-form plugin sits at the top of the list and the date is more than 12 months ago, the plugin is the suspect. Switch to a maintained alternative. The deeper walkthrough for the bisection step lives in the AI-assisted plugin conflict diagnosis piece.
What can AI help diagnose when the form fails?
AI helps with reading three artifacts.
Paste the PHP error log line into an AI chat. The chat returns the file and the line number that crashed in plain English.
The cryptic "Fatal error: Call to undefined method WPF Send run" turns into a single line. "The form plugin’s send class is missing a method."
The likely fix is also one line. "Reinstall the plugin from the directory because the update is incomplete."
Paste the SMTP plugin’s "send failed" notification email. The chat returns the line that names the actual problem. Authentication, DNS, rate-limit, or quota. The owner does not have to read three pages of generic boilerplate to find the one sentence that matters.
Paste the form plugin’s submission log (the entries that did save) alongside the window where messages went missing. The chat returns the most likely point in the chain that is dropping the messages. The chat sometimes catches a pattern the owner missed. The owner verifies the suggestion before acting on it.
AI fails on the live site. It cannot reach your host. It cannot read your DNS records. It cannot send a test email itself.
The honest framing is consistent across WordPress diagnostics. The AI tool accelerates the read. You keep the verdict. The broader four-layer triage lives in the WordPress troubleshooting walkthrough.
Which check should you run first when the form goes silent?
Open Gmail and search the spam folder.
Type the subject line the form notifications use ("New message from", or whatever the plugin sends). The result tells you which fix you need.
If the messages are in spam, install one SMTP plugin and connect it to a transactional email account. The form starts working in twenty minutes. The 47-messages-in-spam scenario from the worked example is the most common version of this case.
If the spam folder is empty, send a test email from Tools > Site Health. If the test email never arrives, the path is fully blocked. The same SMTP plugin fix applies, but with a more careful provider choice.
If the test email does arrive, the form plugin layer is the suspect. Sort the plugins by Last Updated. The form plugin at the top of the list with a 14-month-old update is the abandoned-plugin case. Switch to a maintained alternative.
The two-check path covers the population of broken contact forms with two fixes. Neither costs more than fifteen minutes. Neither costs more than the price of a transactional email account’s free tier.
Other questions worth answering
What DNS records does a transactional sender need before messages reach Gmail reliably?
Three records matter. SPF lists which servers may send for your domain. DKIM adds a cryptographic signature each message carries. DMARC tells receivers what to do when SPF or DKIM disagree.
As of 2026, Gmail and Yahoo require all three records for bulk senders. Brevo, Mailgun, and SendGrid generate the values for you during onboarding.
How do you decide between a transactional service and an existing Google Workspace mailbox?
Two factors decide it. Volume and ownership. As of 2026, Google Workspace handles a few hundred messages per day without extra cost on plans you already pay for.
A transactional service like Brevo or Mailgun handles larger batches and gives you per-message logs. Pick Workspace when one inbox owns the conversation. Pick the service when several sites share the sending domain.
What happens to password resets and order receipts after switching to an authenticated sender?
Every email type WordPress generates routes through the new sender. Password resets, WooCommerce order receipts, Akismet comment notices, and admin notifications travel the authenticated path your visitor submissions use.
That gives the owner a single deliverability lever in 2026. One service to monitor, one set of records to renew, one log to read when a message goes missing.
When does a small site outgrow the free tier of a transactional sender?
Around three hundred messages per day is the common free-tier ceiling in 2026. Brevo, Mailgun, and SendGrid each offer entry-level allowances near that volume.
If you reply to five inquiries and a handful of order receipts daily, you stay free for years. A busy WooCommerce store with abandoned-cart notices crosses the ceiling within months.
Does a staging or multisite setup need its own sender credentials?
Yes, in most cases. Staging copies inherit the production database including your stored sender credentials. When the staging copy runs a workflow in 2026, it sends real messages from real accounts.
Set staging to use a sandbox sender from Mailtrap, or disable outbound sending entirely. Multisite networks can share one sender across sub-sites or assign per-site senders depending on the inbox layout.
Which broken contact form should you check first?
Have a WordPress contact form that has stopped delivering messages and nobody knows when it stopped? You can contact me here. Tell me the site URL and the rough date the inquiries dropped off. I will name the SMTP path, point at the likely spam-folder gap, and recommend the one fix worth doing first.
There is no pitch, no upsell, and the conversation is free.