Website contact form spam, notifications and where submissions go
Contact forms are the part of a client site that quietly fails. How to stop website contact form spam, route notifications and keep every submission findable.
The contact form is the part of a client site most likely to be failing right now without anyone knowing. It looks fine. It submits. The visitor sees a thank-you message. And the notification goes to the inbox of someone who left the business in March, or lands in a spam folder, or arrives alongside two hundred messages offering backlinks, so the one real enquiry gets deleted with the rest.
Nobody notices for months, because a form that fails quietly doesn't produce a complaint. It produces silence, which the client reads as a slow quarter.
Most of this is fixable in an afternoon, and preventable with five minutes a month. Here's how to deal with website contact form spam, route notifications properly, and make sure every submission can be found.
The three ways forms fail
Notifications go to the wrong place. An old address, a person instead of a role, a developer's test inbox left over from the build, or a mail filter that decided the form's emails look automated.
Spam buries the real messages. Once a form is found by bots, volume can go from a few a week to dozens a day. People start skimming, then ignoring, then filtering. Real enquiries go with the junk.
Nobody knows where submissions are stored. If the only copy of a submission is an email, then email is the database. Delete the email, or lose access to the inbox, and the enquiry is gone.
Each needs its own fix.
Spam: start invisible, escalate only if you need to
Spam protection is a trade between how much junk you stop and how much you inconvenience real visitors. Start with the measures that cost visitors nothing.
A honeypot first. A hidden field that people never see and bots fill in. A submission with the field filled is marked as spam. It's free, invisible and stops a surprising share of automated spam. It doesn't stop a bot written for that specific site, or a human paid to fill in forms.
A challenge when the honeypot isn't enough. A service such as Cloudflare Turnstile checks whether the visitor is likely a person, usually without asking them to do anything. When it does need to ask, it's a moment of friction for a real visitor. Use it when spam is a real problem, not as a default on every form.
Rate limits. Capping how many submissions a single source can send in a short window stops floods without affecting normal visitors. Most platforms and hosts offer some form of it; it's worth checking what yours does.
Avoid the puzzle. Picture grids and distorted text cost real visitors far more than they cost bots now. They are the measure most likely to lose the enquiry you wanted.
Whatever you use, test it with a genuine submission afterwards. Over-eager spam protection that blocks real people is worse than spam, because it's silent.
Notifications: a role, not a person
Send form notifications to a role address, such as enquiries@ or hello@, that the client controls and that more than one person can read. People leave, go on holiday and change jobs. Roles don't.
Then check that notifications actually arrive, and keep checking. Automated emails are often caught by filters, especially when the sending domain is new. Test on launch day from the live domain, not just from staging, and confirm the message lands in the inbox rather than in spam. Make sure the notification includes enough of the submission to act on, so nobody has to log in just to read a phone number.
Storage: email is not the database
Every submission should be stored somewhere the client can open, independently of email. A submissions inbox in the site's own admin, with each enquiry listed, searchable and kept. That way a missed or deleted notification isn't a lost enquiry.
Two features make that inbox usable. A way to mark something as spam, or rescue something wrongly marked, by hand. And a way to export submissions, usually as CSV, so the client can move them into whatever they use to follow up. Tell the client where this inbox is at handover. Most don't know it exists.
Automations: keep them simple
Once submissions are stored, it's tempting to route them everywhere: a notification, a CRM, a spreadsheet, a chat channel, an auto-reply. Each extra step is another thing that can quietly break when someone changes a password or a plan.
Keep it to what the client actually uses. Usually that's one notification to a role address and the stored inbox. Add a second route only when there's a named person who will act on it.
How Contentive handles forms
On Contentive, forms are part of the core platform rather than an add-on. Each one has a public submit endpoint that is rate-limited, a honeypot, optional Cloudflare Turnstile, a notify email, a redirect after submitting, and a submissions inbox in the Studio with a manual spam toggle and CSV export. A form is placed on a page as a form block, so the client can move it without touching markup. Routing beyond the notify email is an automation, such as "form submitted, send email", built from a short list of triggers and actions rather than a plugin.
What it costs
Every protection layer has a price. A honeypot costs nothing but stops only the simplest bots. A challenge stops more and occasionally costs you a real visitor. A stored inbox means one more place the client has to look. And every routing step you add is another thing to test at each launch and each change of staff. The aim isn't the strongest possible protection; it's the least that keeps the real enquiries readable. If you've ever spent an evening on a form plugin's update, you'll recognise the argument in every plugin is a decision you have to keep making.
The five-minute monthly check
For every live site, once a month:
Submit each form yourself, from the live site, with a recognisable test message.
Confirm the notification arrived at the role address, in the inbox and not in spam.
Open the submissions inbox and check the test is there.
Glance at the spam marked since last month for anything real.
Confirm the notification address still belongs to someone who reads it.
Five minutes, every site, every month. Put it in the care plan and the handover checklist, and add the first run to the pre-launch checklist.