Your contact form probably still works. What stopped is the email it sends afterward. In almost every case we look at, the form saves the submission fine and then hands the message to a mail system that quietly refuses to deliver it — because the site is sending mail as itself instead of through an authenticated mailbox, or a plugin update changed how mail leaves the site.
The visitor sees "Thanks, we will be in touch." You see nothing. Nobody gets an error. That is why this is the most common "our website is broken" email we receive, and why it is usually weeks old by the time anyone notices.
Why forms fail silently
A form does two separate jobs. First it accepts what the visitor typed. Second it tries to notify you. The first job almost never fails — the plugin writes the entry to the database and shows the success message immediately. The second job happens after the visitor is gone, on a different system, with nobody watching.
When that second job fails, there is no one to tell. The bounce notice goes back to whatever address the site claimed to be sending from, which is usually a fake address nobody reads. So the failure disappears into a void.
A visibly broken form gets reported the same day by a customer who could not submit it. A silently broken form costs you leads for a month while everyone assumes business is just slow.
Cause one: the site is sending mail as itself
By default, WordPress hands outgoing mail to whatever mail program happens to exist on the server, and stamps it with an address like [email protected]. Nobody ever logged into that address; it has no mailbox. The message is being sent by a web server, not a mail server.
Ten years ago that mostly worked. It does not any more. Google, Microsoft, and every serious mail provider now check whether the sending server is authorized to send for your domain. If it is not, the message gets rejected or filed as spam. Your web server is almost never on that list unless somebody put it there deliberately.
The fix is to send through a real authenticated mailbox or a dedicated sending service, so mail arrives with credentials attached instead of arriving anonymously and hoping for the best.
Cause two: a plugin update changed the send method
Form plugins, SMTP plugins, and security plugins all touch outgoing mail. An update to any of them can reset a send method, drop stored credentials, or switch a setting back to a default. The update installs cleanly. The site looks fine. Mail stops.
We see this most often after a plugin changes ownership or does a major version bump. The settings screen still shows your mail configuration, but one field silently reverted, and now the site is back to sending as itself. This is one reason real maintenance means checking that things still work after an update, not just confirming the update ran.
Three more quiet failures
Spam filters are eating it. Sometimes the mail leaves correctly and gets filed into spam or quarantine at the receiving end. This is common when notifications go to a Microsoft 365 or Google Workspace mailbox and the sending domain has no authentication records. It also happens when the form is set to send from the visitor's own address, so a message claiming to be from a stranger's Gmail account arrives from your web server. That looks exactly like forgery, because technically it is. The visitor's address belongs in the reply-to field, not the from field.
The mailbox is full, gone, or forwarding into nothing. The least technical cause and a surprisingly common one. The notification address belongs to someone who left two years ago, or forwards to a personal account that stopped accepting mail, or hit its storage limit and is rejecting everything. Worth checking first, because it is trivial to rule out and it explains the pattern where forms worked for years and then stopped on an ordinary Tuesday.
The integration broke, not the form. If your form pushes submissions into a CRM, a mailing list, or a scheduling tool, that connection has its own failure modes. Keys expire. A service changes its authentication requirements. A list gets renamed. Check both paths separately: email arriving does not prove the CRM got it, and a CRM record does not prove the email went out.
The ten-minute self-test
You can diagnose most of this yourself without touching any settings.
- Submit your own form from an outside address — a personal Gmail account, or your phone on cellular data. Not the same mailbox the notification goes to. Use an obvious test name so you can find it later.
- Wait five minutes and check the destination inbox. Then check its spam folder. Then check quarantine if you are on Microsoft 365, which holds mail somewhere most people never look.
- Open the form plugin's entries or submissions log in WordPress. Most decent plugins store every entry regardless of whether the email sent. If your test entry is there but the email is not in your inbox, the form is fine and the mail path is broken. That single distinction eliminates half the possible causes.
- Check whether the plugin logs failed sends. Some record the reason the mail server gave. That message is often the whole answer.
- Look at the entries list for a gap. If submissions stop cold on a specific date, compare it to when plugins were last updated. There is your suspect.
If the entries log is empty too, the form itself is failing — usually a caching or JavaScript conflict — and that is a different repair.
What authenticated sending actually means
Three DNS records decide whether the rest of the world trusts mail claiming to come from your domain. They sound intimidating and they are genuinely not.
SPF is a list of who is allowed to send mail for your domain. DKIM is a signature proving the message was not altered and really came from an authorized sender. DMARC tells receiving servers what to do when something fails those checks, and can report back to you. Together they are the difference between mail that gets delivered and mail that gets treated as suspicious.
The catch is that these records have to match how your site actually sends. Adding one that authorizes a service you are not using does nothing. Removing one because a tool complained can break mail you did not know depended on it. This is a place where guessing costs more than asking.
What we do about it
On sites we host, outgoing mail goes through an authenticated sender rather than leaving the web server anonymously, and the domain's SPF, DKIM, and DMARC records are set to match. When we take over a site, checking the mail path is part of the migration, because a form that has been quietly failing is one of the most common things we find.
After that, updates get applied and then checked. If an update resets a send method, that should surface in review rather than in a customer complaint six weeks later. Our monitoring and recovery work covers the site being reachable and restorable, and the mail path is treated as part of the same job — a site that loads perfectly and swallows every lead is still broken.
And if you email us about it, a real engineer reads it and answers the same day. Most form problems are a fifteen-minute fix once someone actually looks. The expensive part is the month nobody did.
One honest caveat. If you get very little form volume, elaborate mail monitoring is overkill — a monthly test submission from your phone tells you the same thing for free. Not every problem needs infrastructure. But any business that depends on inbound enquiries should know, without guessing, whether its forms delivered anything this week. If you are not sure, tell us the domain and we will look.
Frequently asked questions
How long can a broken form go unnoticed?
Longer than anyone expects. Because the failure is silent and enquiry volume varies week to week, most owners assume a quiet stretch is just a quiet stretch. Sites we take over have often been dropping form mail for a month or more before anybody tested it.
Will an SMTP plugin fix it on its own?
Usually it helps, but only if it is pointed at a real authenticated mailbox or sending service and the domain's DNS records agree. Installing the plugin and leaving it on defaults changes nothing. The credentials and the DNS side are where the actual fix lives.
Do I need a separate email service just for form notifications?
Not always. Your existing business mailbox is fine for ordinary contact-form volume. A dedicated sending service earns its place when you send transactional mail at scale — receipts, account notices, order confirmations — or when you want delivery logs showing what left and what bounced.
