Website security

How to protect your contact form from spam and bots

A robot, a shield with a check mark and an envelope beside a chat window

The contact form on your website used to bring in a few requests, all of them real. Then dozens of messages a day started arriving: suspicious links, SEO offers in English, strings of text that mean nothing. The employee sorting them gets tired and stops reading carefully, and a real customer's request gets lost in the pile. Bots do this to any form exposed on the internet, however small the site.

Why does your contact form get spam?

Automated programs crawl the web looking for any form that accepts text and links, and they fill those forms in bulk. They aren't targeting your site in particular. All it takes is a form that exists and accepts submissions without checking them. Some messages are written by real people who are paid to post them, and those are harder to catch.

What is the best way to protect a contact form?

Several light layers running on the server work better than one annoying barrier. Each layer stops one kind of message, and a real visitor doesn't notice most of them.

  1. Hidden fieldBots fill it in; people never see it
  2. Server tokenProves the form was opened from your page a moment ago
  3. Sending limitA capped number of messages per IP address
  4. TurnstileA background check that the sender is human
  5. Content filteringLinks, words and known patterns
The protection layers, in the order a message passes through them

What is a honeypot field and how does it work?

It's an extra field in the form, hidden from visitors with CSS, with a name that looks ordinary to a bot, such as website or company. A person can't see it, so they leave it empty, while a simple bot fills in every field it finds. If the field arrives filled in, the server quietly rejects the message, or shows a success message without sending anything. Hide the field from screen readers as well, and turn off browser autofill on it, so a real visitor doesn't fill it in without realizing.

Why do you need a temporary token from the server?

Many bots never open your page at all. They send the data straight to the address that receives the form. When the server puts a signed temporary token in the form that records when the page was opened, it can confirm on submission that the token came from it, hasn't expired and hasn't been used before. The same timestamp tells it how long passed between opening the page and sending the form, and a form filled in within one second wasn't filled in by a person.

How do you limit the number of messages sent?

Set a cap on how many submissions one IP address can make within a set period, such as a few messages an hour. A real visitor rarely sends more than one or two, and a bot trying to send hundreds stops at the cap. Word the rejection message politely and clearly, because a whole office sharing one connection may be behind that address.

Do you need a CAPTCHA or Cloudflare Turnstile?

"Select all the images with traffic lights" tests annoy visitors and cut the number of people who finish the form, especially on mobile. Cloudflare Turnstile is an alternative that checks the browser in the background and doesn't ask most visitors to solve anything. You can use it for free even if your site doesn't run through Cloudflare.

A point that often gets forgotten: the widget in the browser doesn't protect the form by itself. Your server has to send the token the widget produces to Cloudflare for verification before it accepts the message. The token is valid for five minutes and can be accepted only once.

How do you filter the content of messages?

The last layer reads the message itself. Common signs include more than one link in a short text, words that keep turning up in spam such as Google ranking offers and cryptocurrency, a message in a language your customers don't usually write in, or an address from a disposable email service. It's better not to delete these messages outright. Mark them as suspicious and put them in a folder that someone reviews every week, since a real customer may be among them.

Why do form messages sometimes never reach your inbox?

A common mistake is having the form send the message as if it came from the visitor's own email address. The receiving mail server sees a message claiming to be from gmail.com that is actually coming from your website's server, so it often rejects it or files it as spam. The right way is to send from an address on your own domain and put the visitor's email in the Reply-To field. When you hit "Reply", your answer goes straight to them.

Also save a copy of every message in a database or a simple dashboard, so no request is lost if email breaks one day. And send a test message through the form every month.

If your real messages are the ones landing in your spam folder, the problem is usually in your email settings. We explain it in why your company email goes to spam.

We build contact forms with these layers into the websites we develop as part of our website design and development service. Send us your website link and the kind of messages you're getting and we'll suggest the layer your form is missing.

Questions our partners ask

Is a honeypot field enough on its own?

It stops simple bots, and there are plenty of those. Smarter bots ignore hidden fields, so combine it with a sending limit and server-side checks.

Will this protection bother real visitors?

Visitors never see the hidden field, the temporary token or the sending limit. Most visitors pass through Turnstile without being asked to solve anything.

Written by the Visual Innovate team, the people who build, host and follow up systems, websites and apps for our clients in Jordan, Saudi Arabia, Oman and Egypt.

Are you our next Success Partner?

Tell us the problem as you see it. Within one working day we'll come back with how we understand it and a clear first step.