Stop turning contact form spam into a user problem

We put contact forms on websites quite a lot, and we check that the input data is valid and sanitized of all evilness, however after a few weeks the invariable contact form spam starts to filter in to the client’s inbox.

To the client the obvious answer is a CAPTCHA.

However I advise clients that putting a CAPTCHA or other similar element onto a contact form is shifting the problem of the spam to their legitimate users. Why should your user have to mess about trying to read two difficult to read words, just to contact your business? The user shouldn’t need to care about your spam problem.

That said, spam is annoying and if you are getting a lot of it, it may prevent you noticing legitimate contacts. So what should you do about it?

If you are getting an awful lot of spam, one method is to deploy Akismet, which has a simple API that can be hooked up to your contact form and which returns a true or false result, depending on whether it believes the message to be spam or not. As Akismet is used by WordPress they have a huge amount of data on what is and is not spam – there are also plugins available for several content management systems and frameworks.

Simon Proctor on the 11 May 2011:

I love Akismet, it’s wonderful. It’s just horribly depressing at the same time.

Oh look! I’ve got 14 comments on my blog! Oh look… they’re all spam. Sigh.

But yes, I heartily agree with this post.

Shelly on the 11 May 2011:

I use a honeypot. Basically, it’s a form field that’s set to a width/height of 0, with “visibility:hidden” in the CSS. The label is set to instruct the end user to do absolutely nothing with the field – to just ignore it – so if someone using a screen reader comes along, they’ll know not to bother with it.

If any input is put into that field, it won’t be sent. Spammers generally auto-fill every field there is, so most times, it turns away the spammers right then and there. A few do get through, but not many. No need for CAPTCHAs, no need to depend on a third party service (and if you do use the 3rd party service, it’s just a bonus level of protection).

Pete Lacey on the 11 May 2011:

Wholeheartedly agree. Spam isn’t a users problem, it’s yours.

I wrote a blog post in a similar vien the other year, having a bit of a go at people who write cryptic email addresses. I think the same rule applies to CAPTCHA and other strange forms of validation:

Nick on the 11 May 2011:

I use fun or silly Captcha’s when it’s appropriate. Very easy mathematical sums are also good. You don’t have to decipher ugly jumbled-up letters.

Rich Adams on the 11 May 2011:

I find using a honeypot is a good method. I have fields named “email”, “site”, etc. set to have no size and hidden in CSS and the real ones called “liame”, “etis” (backwards). The label for the honey pot ones just say “Only fill these in if you’re a spammer” so if someone has CSS disabled they won’t be trapped by it. If any of the honeypot fields are filled in I instantly discard it as SPAM since only a bot would’ve filled those in.

Work surprisingly well, I’ve had no SPAM since implementing this.

Originally I had a honeypot with just a random name, but the bots got smart and would only fill in the fields called “email”, etc. So switching around the names of fields seems to work for now.

Michael on the 12 May 2011:

I was just (a couple of days ago, but it’s still loaded in my browser) an article from 2007 titled “Stopping spambots with hashes and honeypots” which outlines various ways of preventing spam without bothering users (well, most users, some few do see the honeypots).

I personally don’t mind the occasional simple sum, or easy task (“what’s the square root of -1?” is one I saw recently, others I’ve seen include entering the domain of the website). In fact, what annoys me more is having to enter an email address when I intend to merely post a throw away comment, or where I don’t intend to ever have a conversation with the author. In such cases I normally put a fake email address. I do not know what the point of requiring an email address is.

Jared Smith on the 12 May 2011:

We use the honeypot method hidden with CSS. We also set a hidden field with the current timestamp when the page loads. On submission, we compare the submitted timestamp (when the page was loaded) to the current time stamp (when the form was submitted). If it is more than 30 minutes or less than 4 seconds, then it’s probably a bot.

Using these two things with a very short naughty words filter has brought one of our forms from ~1000 spam submissions to 2 or 3 per month (and these are paid human spammers or SEO ‘experts’), and with no user impact.

Many more techniques at

Martyn Drake on the 12 May 2011:

Add to that a good set of mod_security secfilters and you’re got yourself an excellent “bouncer” guarding your site.

David Radford on the 12 May 2011:

I agree with Rich and Jared – I have recently started using a CSS hidden honeypot with a ‘don’t fill this in…’ label screen readers etc. and it does work surprisingly well – but better not say it too loud in case those pesky spammers catch on…

Rachel on the 12 May 2011:

Loads of really helpful comments – thanks everyone :)

I’m seeing a lot of human entered spam on some sites which the honeypot method isn’t going to catch and Akismet often does. However for those really annoying automated posts that can flood in the honeypot method sounds to work well. So that’s another good option for people to try. Just make sure it’s obvious for people who do see the field that they should not fill it in!

Peter Bowyer on the 12 May 2011:

Rachel, you may think the honeypot won’t prevent human entered spam, however because the field is hidden it often does. For those that show the hidden fields, we still beat a number, because they’re asked to solve a math question (not leave the field blank).

Implementing this across two medium-traffic sites reduced contact form spam by 80-90%, keeping our CRM much cleaner than previously.

Andy Walpole on the 13 May 2011:

It’s best just to use Akismet as the last resort rather than as a matter of routine.

Use the CSS honeypot as detailed above but also add $_SERVER[‘HTTP_USER_AGENT’] to the validation process to weed out genuine users who use a browser and the bots that don’t:

if($_SERVER[‘HTTP_USER_AGENT’] === null) {

$error[] = ‘Your message has been marked as spam and will not be sent. If you have been wrongly accused of being a spammer and feel you are a miscarriage of justice then we apologise profusely. Please contact us at info@example instead’;


Aquaster on the 08 May 2012:

The problem in our case is that human filled forms on our websites are see as spam by Gmail filters. Also getting on blacklists (because of form sending from server). Does anybody know a solution for creating an email (send from a form) that is not checked as spam?

Posted a response? Enter the URL

This site uses Webmention. If you post a response to this post on your own site, and you also support Webmention I'll be notified automatically. If not you can add a link here.