data-netlify-honeypot="bot-field" since 2022; reCAPTCHA v2 added Dec 2024
I’ve had a Netlify form with honeypot enabled for several years on my live site (loumarcsigns.com , Netlify site: loumarc-signs.netlify.app ). Six months ago, I added reCAPTCHA due to increasing spam submissions. However, in the last month, spam submissions have significantly surged, now making up about 50% of all form submissions.
I’ve checked the forums and haven’t found any recent reports of similar spam increases. I’ve also been marking spam manually in the Netlify dashboard regularly throughout May.
Has there been any recent change in Netlify Forms spam filtering that might explain this sudden spike? Are there recommended adjustments I could make to improve the effectiveness of reCAPTCHA, or any other strategies worth considering?
When using ReCaptcha, the Akismet spam detection is automatically disabled. So if bots and spammers are surpassing ReCaptcha on your website, unfortunately there’s nothing that can be done. I don’t believe switching the captcha provider would essentially fix that, but if you think so, as I mentioned in that post, you can implement and Edge Function to use hcaptcha or any other spam detection tool that you’d like.
Why was this thread unlisted? I can see an icon of an eye with a slash on it and the following, “This topic is unlisted; it will not be displayed in topic lists, and can only be accessed via a direct link.”
Did I do something wrong that was against the forums rules to have it unlisted?
I recently set up CapJS with a Netlify function. It is working in that emails that do not pass the challenge are being sent to Spam submissions (in the dashboard), however email notifications are firing for these emails—so me and my client are still getting these spam emails. Can you confirm that email notifications from Netlify are fired before any submission-create.jsNetlify function is called and results returned? Did I just waste an evening of work installing CapJS only to realize I can’t use it with Netlify’s email notifications?
Hi, @frankstallone. I’ve opened a support ticket to track this question and find the answer. If you do not see an email about ticket # 399747, please let us know here. If you do see that email, please reply there with any follow-up questions or information.
Regarding why your post was unlisted, I see this happened to several of your posts but it isn’t transparent as to why this occurred. Maybe you are composing the posts in a different editor and then pasting them here. That can cause the bot protections here to make false positives. I’ve increased your trust level on this forum to hopefully prevent that from occurring again.
Ticket email received. Appreciate you helping out with this, and the odd behavior with my account and this forum. I promise I am human, my engagement is legit!
Not Netlify staff, but if you’re still fighting this, the key detail seems to be that reCAPTCHA disables Akismet for Netlify Forms, and form notification timing can make custom filtering feel frustrating if emails are sent before your own checks complete. For persistent spam on a static site, I’d consider moving the form submission path to a dedicated handler where the CAPTCHA or challenge is verified server-side, rate limits and simple reputation checks run before accepting the submission, and email notifications are only sent after the message passes those checks. That also makes it easier to test alternatives like hCaptcha, Turnstile, or CapJS without depending on Netlify Forms’ built-in notification flow. Curious whether your main blocker is stopping dashboard spam, stopping email notifications, or avoiding more custom backend code—I’ve been comparing approaches for static-site forms and would be happy to share notes.
Hey @goldenbruce, thanks for bringing this thread back. I appreciate it!
Your read is pretty much where I’ve landed after revisiting the setup. We’re no longer relying on Netlify’s built-in reCAPTCHA path. Right now the forms post to a /forms/submit route that is handled by an Edge Function first. That gate checks the honeypot, requires a CapJS token, validates that token server-side, and only then forwards the request along to Netlify Forms. So for missing/invalid tokens, the submission should never become a Netlify form submission and shouldn’t trigger the built-in Netlify email notifications.
I checked recent logs and saw bot-looking attempts getting stopped at missing cap-token, with no forwarding to Netlify Forms. So the current architecture is broadly aligned with what you’re suggesting: validate before accepting, rather than trying to clean up after Netlify has already created the submission.
That said, feels like you’re right about the next layer. CapJS alone isn’t a full spam strategy, especially if bots eventually get valid tokens. I’m looking at adding rate limits around /forms/\* and the CapJS endpoints, plus some simple reputation/content checks before forwarding accepted messages to Netlify Forms. I’m also revisiting the CapJS storage model, since serverless /tmp token storage may be too fragile long term.
Would definitely be interested in the notes you mentioned comparing static site form approaches. Thanks again for the thoughtful reply!
As previously advised by your team, I am reaching out after June 2nd to proceed with the release of the domain from the old Netlify account/team. This domain is currently blocking my ability to configure my active project
I am reaching out after June 2nd to proceed with the release of the domain from the old Netlify account/team. This domain is currently blocking my ability to configure my active project
I am reaching out after June 2nd to proceed with the release of the domain from the old Netlify account/team. This domain is currently blocking my ability to configure my active project
It sounds like you’ve already solved the biggest issue with Netlify’s built-in notification timing by validating before forwarding to Netlify Forms. At this point I’d probably treat CapJS as one layer in the flow rather than the whole spam strategy.
The next areas I’d look at are:
durable CapJS/token storage, instead of relying on fragile serverless-local state
route-level rate limits around `/forms/*` and the CapJS endpoints
lightweight content/reputation checks before forwarding accepted messages to Netlify Forms
clear logging around “blocked before Netlify” vs “accepted and forwarded”, so it’s easier to see which layer is failing
I’m currently trying to better understand how people are handling spam for static-site forms, especially when they want to keep the convenience of Netlify Forms but need more control before submissions and notifications happen.
If you’d rather not share implementation details or logs publicly, feel free to email me at qiuyanjun888@gmail.com. I’d be happy to compare approaches and better understand where the remaining pain is in your setup.
A few things I’d be curious about:
Is the main pain now client email notifications, dashboard spam, or maintaining the custom Edge Function flow?
Roughly how many spam submissions per day are still getting through?
Are the remaining spam submissions using valid CapJS tokens, or are they bypassing a different part of the flow?
