The form itself may be working fine. WordPress hands the message to PHP’s mail function on your server, and if nothing on that server is set up to carry it out the door, it never leaves. The visitor sees a thank you either way, so weeks can pass before anyone notices.
What happens when someone hits send
Your form plugin does not send email. It calls a WordPress function named wp_mail and lets go.
The WordPress Advanced Administration Handbook, on its Mail page, is blunt about what happens next. That page was published on August 19, 2025 and updated on September 26, 2025. It says WordPress “has never provided either a MUA or an MTA by default.” In plain terms, WordPress does not run a mail server. It only passes a message to something else that does.
By default, the handbook says, wp_mail “informs the PHPMailer library to use the PHP’s internal mail() function that requires the presence of a sendmail-compatible binary acting as the MTA.” That means a mail program has to be installed and set up on the server. The handbook scopes the warning to people running their own server: if you have no mail server set up and the mailing environment is not configured properly, “the outgoing mail won’t be sent.”
You can read the same thing in the WordPress source file wp-includes/pluggable.php, published by WordPress on GitHub. Inside wp_mail it picks the mail route with a single line, isMail. That file carries no update date.
So three parties touch every form message: your form plugin, WordPress, and the server. Only the third one actually sends anything, and it is the one you cannot see.
Why the form still says thank you
The comment sitting above wp_mail in that same source file says it outright. “A true return value does not automatically mean that the user received the email successfully. It just only means that the method used was able to process the request without any errors.”
PHP’s own manual page for the mail function says the same about the layer below. A true result means the mail was accepted for delivery, and acceptance does not mean it reaches where it was going. That page carries no update date.
So the green success box on your form means the handoff worked. It is not proof that anything left the building.
Worse, WordPress writes nothing down. When the handoff fails, wp_mail returns false and fires an action named wp_mail_failed. The WordPress developer reference page for that hook, published December 9, 2015 and last modified August 20, 2026, says it fires after a PHPMailer exception is caught, and that it arrived in WordPress 4.4.0. Nothing listens to it unless a plugin or a developer sets that up.
Here is the part nobody likes. There is no screen in WordPress that lists failed mail, so you cannot go back and count the leads you already lost. You can only stop the next one from going missing.
Your host may be the reason nothing leaves
The handbook says that on managed hosting “there is typically nothing extra that needs to be done to send emails,” and that mailing questions “should be directed to your webhost.” That is the right first phone call.
Hosts do cap this, and some block it. WP Engine’s support page on sending email, updated July 28, 2025, says port 25 is not allowed, ports 587 and 465 are allowed, and port 2525 is recommended. It also caps how much mail can leave in an hour, enough for the odd password reset but not for a mailing campaign, and it says outright that it will not share the exact amount. You cannot look that number up. You have to ask.
PHPMailer’s own troubleshooting page, last edited October 29, 2025, describes the same wall from the other side. It names GoDaddy as blocking outbound mail on ports 25, 465 and 587 to every server except its own, and says you have to send through their servers instead.
Ask your host two questions. Does this account send mail through PHP at all, and is there an hourly cap? A host that answers “this plan does not send mail from the server” has ended the guessing in one line.
What an SMTP plugin changes, and what it does not
An SMTP plugin stops your server from being the sender. It signs in to a real mail service instead, and posts the message from there.
The WP Mail SMTP listing in the WordPress plugin directory puts it in one sentence: “We reconfigure the wp_mail() function to use proper SMTP host credentials or an SMTP mail provider.” That same directory page shows over 4 million active installations, a number you can go and read for yourself. PHPMailer’s troubleshooting page backs the approach, calling SMTP “faster, safer, and easier to debug than using mail().”
It is not a cure for everything. An SMTP plugin does not fix:
- a wrong or dead recipient address saved in your form settings
- a form plugin that never fires in the first place
- what happens to the message after a mail service accepts it, which is a separate problem with separate fixes
Two more honest notes. The handbook warns that routing mail through a remote server “will cause a performance degradation,” so the page can sit for a moment while the message goes out. And if your mail already arrives every time, do not install one of these. Adding a plugin to a working site is a cost, not a repair. Install one at most. Two plugins fighting over the same function is a fresh problem of its own. While you are in there, it is worth checking whether your form plugin is still maintained.
Keep a copy on the site, not just in email
Email is a bad place to keep your only copy of a lead, so it helps to know where a form submission actually goes. Some form plugins already save every submission inside the site, and some do not.
Flamingo, listed in the WordPress plugin directory with more than 800,000 active installations, exists for that reason. Its description says it was made for Contact Form 7, “which doesn’t store submitted messages,” and that with messages saved you no longer worry about losing them to mail server trouble or a bad mail setup.
Turn that on before you touch anything else. Then a broken mail path costs you a delay, not a customer.
What to do next
Work through these in order. The first three cost nothing.
- Open your form settings and read the recipient address out loud. An old staff address, a typo, or a mailbox nobody opens will do it, and this is the cheapest thing on the list to rule out.
- Turn on message storage in your form plugin, so every submission is saved on the site itself.
- Submit the live form from your phone, not the plugin’s built in test button, and watch for it.
- Call your host and ask the two questions above. Write down the answer.
- If mail is blocked or capped, connect one SMTP plugin to a mail service, then test the live form again.
If this is the fourth thing that has broken on the site this year, the form is a symptom, and the real question is whether to keep fixing it or rebuild. A site built without PHP and a database has no wp_mail and no server mail program in the path at all, so there is nothing there to go quiet on you. That is how the website build is put together, and pricing sets out what each month covers.
Fix the address first, though. It is free, and it takes a minute.