Contact Form Spam: What reCAPTCHA Can and Cannot Stop

You add reCAPTCHA to a contact form, yet unwanted messages keep reaching the inbox. The next step is to find out which part of the process needs attention. The form may not be checking verification correctly, the messages may be passing the configured checks, or what looks like spam may actually be a repeated genuine submission.

Start by separating three questions: did the website accept the submission, did it save one enquiry or several, and how many notification emails were sent? Answering these independently gives your developer a clearer starting point than simply asking for a stronger CAPTCHA.

First, identify what you are receiving

Review a small sample of unwanted messages before changing settings. Use the form's own records where available, rather than assuming every email with a familiar subject came through the website.

• Unrelated promotions: accepted messages that do not fit the purpose of the form.
• Repeated enquiries: the same plausible request received more than once.
• Missing enquiries: a customer reports success, but staff cannot find the message.
• Rejected visitors: a genuine customer cannot complete verification or submit.

These symptoms can overlap. Save the approximate time, page address and any request reference. Redact personal information before sharing examples beyond the people responsible for investigating.

A visible CAPTCHA is only part of the integration

For reCAPTCHA v2 and v3 integrations using Google's verification endpoint, the browser supplies a response token and the server must verify it. Google's response verification documentation states that tokens expire after two minutes and can be verified only once. Showing a widget without enforcing the server response leaves a gap.

Ask your developer to confirm that failed or missing verification cannot enter the normal accepted-enquiry workflow. The secret key belongs on the server. Checks should also validate the expected site context, rather than trusting any successful-looking browser response. Use the documentation for the exact reCAPTCHA integration you operate; other Google Cloud integrations use a different assessment flow.

A visitor who takes time to write a detailed request should not lose their work because verification expires. Preserve their text and provide a usable retry path.

Passing verification does not make a message useful

reCAPTCHA v3 returns a risk score rather than presenting an interactive challenge. Its official integration guide explains checking the expected action and deciding how to respond to the score. A threshold needs evaluation against your traffic; it is not a universal spam setting.

The business relevance of a message is a separate question from its verification result. Treat a successful check as one signal, not a guarantee that the sender is a prospective customer. Conversely, do not label every rejected submission as spam without reviewing whether legitimate visitors are struggling.

For a practical review, compare examples of accepted unwanted messages with reports from blocked genuine visitors. This helps the developer see whether the problem is incomplete integration, an unsuitable decision rule or content that needs a separate review process.

Limit repeated submissions at the receiving endpoint

Rate limiting restricts matching requests over a defined period. Cloudflare's rate limiting documentation describes the request criteria, counting period and action involved. Similar controls can be implemented in an application, depending on its framework.

Protect the endpoint that processes the form, not just the page displaying it. Choose limits using observed legitimate activity and monitor the effect. An overly strict IP-based limit can affect unrelated visitors sharing a network, while a distributed sender may not remain behind one address.

A useful acceptance check is whether repeated submissions trigger the intended restriction while an ordinary visitor can still submit and retry after a validation error. Arrange this in a controlled test environment; do not flood your live form or a third-party website.

Validate fields without rejecting real names and messages

Browser checks improve usability, but the server must enforce input rules. OWASP's input validation guidance distinguishes structural checks from whether an input makes sense in context. For a contact form, that includes required fields, reasonable length limits and valid choices for a service selection.

A correctly formatted email address does not prove that the sender owns it. Likewise, a message within the length limit can still be unwanted. Validation helps keep data within expected boundaries; it is not a complete spam classifier or a replacement for safe output handling.

Test real-world input such as apostrophes, international names and multi-paragraph descriptions. Broad rules that reject punctuation or unfamiliar characters can exclude the people the form was built to serve.

Handle duplicate requests separately from spam

Consider this hypothetical example: a visitor submits a quote request on a slow mobile connection, sees no confirmation and presses Send again. Two identical records reach the business. The customer has not necessarily done anything abusive.

Ask the developer to give each intended submission a reference and make retries of that submission safe. This is often called idempotency: processing a retry should not create another copy of the same enquiry. Disabling the button while a request is pending can help the interface, but the server still needs to handle retries consistently.

Be careful with blanket duplicate rules. Two people may legitimately send similar messages, and one customer may need a second service. Deduplication should distinguish a retry from a new request rather than silently discard anything that looks familiar.

A test checklist to give your developer

• Ordinary request: valid input produces one accepted enquiry and the intended notification.
• Failed verification: the request is not accepted, and the visitor has a clear retry option.
• Long completion time: verification can refresh without erasing the message.
• Invalid input: server validation identifies the field that needs correction.
• Repeated click or network retry: the same intended submission does not create multiple records.
• Submission burst: the configured limit applies without blocking unrelated site navigation.
• Notification failure: staff can tell that delivery failed and locate any enquiry the application saved.

Record the expected result, actual result and person responsible for each failed check. A short completed test record is more useful than a screenshot showing that an anti-spam plugin is enabled.

Measure legitimate enquiries as well as blocked traffic

Review accepted spam, reported false rejections, duplicate records and failed notifications as separate outcomes. Fewer emails alone does not demonstrate improvement: a broken form also produces a quiet inbox. Pair changes to filtering with an end-to-end test from the page through to the staff workflow.

For the wider context, read our guide to website security layers. If you need help investigating a form, contact MaxMindSecurity with its page address, the observed symptom and approximate timing. Keep secret keys and customer message contents out of the initial enquiry.

Editorial note: prepared with AI assistance using the linked Google, OWASP and Cloudflare documentation. The retry example is hypothetical. The featured image is an AI-generated illustration, not a customer form or inbox.