Why HubSpot CAPTCHA still misses some form spam paths

You enabled HubSpot CAPTCHA or spam protection. The form still looks exposed. Spam still shows up somewhere in the form workflow. The tempting conclusion is "reCAPTCHA does not work."

That is too broad. HubSpot's native protection does work for many teams, and it is worth turning on when it fits your form path. The more useful question is narrower: which submission paths does CAPTCHA cover, and which paths can still create operational noise?

This matters because HubSpot form spam is not one path. It can arrive through a visible embedded form, an old form GUID that is still active, a non-HubSpot form captured on a tracked page, or a direct POST to a known submission endpoint. Those paths have different defenses.

What HubSpot CAPTCHA actually covers

HubSpot's own documentation says HubSpot forms use Google's invisible reCAPTCHA v2. If Google considers the visitor suspicious, the visitor has to solve a challenge before the form submits.

The same page has the caveat that matters for technical buyers: if CAPTCHA is turned on for a form, submissions from the Submit data for a form API or other form integrations are not accepted.

That caveat cuts both ways.

If a bot tries to submit into a CAPTCHA-on HubSpot form through the official submission API, HubSpot can reject it. That is good.

If your setup depends on server-side forwarding into that same HubSpot form, CAPTCHA can also block your own integration. In FormAegis setup, the destination form must be a no-CAPTCHA hidden form because FormAegis scores the submission first, then forwards clean submissions server-side. The protection is moved in front of HubSpot instead of relying on HubSpot's page-level challenge.

So the problem is not "HubSpot CAPTCHA is broken." The problem is that CAPTCHA is one control in a larger ingestion map.

Why spam can still show up

There are four common reasons a team can still feel like CAPTCHA missed something.

1. An older no-CAPTCHA form GUID is still alive

HubSpot forms have public identifiers. Once a bot learns a portal ID and form GUID from an old embed, cached page, copied source, or logs, it can keep posting to that form as long as the form accepts submissions.

The direct-submit endpoint shape is public in HubSpot's developer docs:

POST https://api.hsforms.com/submissions/v3/integration/secure/submit/{portalId}/{formGuid}

That does not mean every direct POST will succeed. CAPTCHA-on forms and HubSpot spam rules can still reject or quarantine traffic. But it does mean a visible page challenge is not the only thing to audit. If the old form is still active, the bot does not have to load your current page to attempt a submission.

2. The submission went to HubSpot's spam submissions view

HubSpot's spam protection is not always a "nothing happened" experience. HubSpot separates detected spam into a spam submissions index, where operators can review, release, or delete it.

That is the correct behavior for many cases. HubSpot's docs say spam-marked submissions do not create or update CRM records, do not trigger form automation, and are deleted after 90 days if not released.

But it can still create daily work. If a Marketing Ops person expects CAPTCHA to prevent the submission from appearing anywhere, a growing spam submissions view still feels like failure. The CRM may be protected, but the operator still has a queue to clear.

3. Non-HubSpot and captured form paths behave differently

HubSpot distinguishes normal HubSpot forms from captured forms. In the Forms API guide, hubspot forms are created and managed as HubSpot forms, while captured forms correspond to HTML forms on external websites when the non-HubSpot forms tool is enabled.

Those paths are useful, but they expand the audit surface. A team might say "our HubSpot form has CAPTCHA" while a different external form or collected path is still feeding HubSpot. In that case, tightening the visible HubSpot form will not explain all spam.

4. Some spam is low-signal or human-assisted

CAPTCHA is best at proving something about the browser interaction. It is not a full lead-quality system.

A real person, a CAPTCHA-solving service, or a bot with a normal-looking browser can still submit low-quality content. HubSpot also documents several spam indicators beyond CAPTCHA: URL in the name field, HTML in the name field, unregistered site domain, gibberish detection on eligible plans, excluded IP or referrer sources, and blocklisted email addresses.

That is why a good response is usually layered:

1. Turn on the native controls that fit the form.
2. Audit every still-active form GUID and external form path.
3. Decide which suspicious submissions should be blocked, quarantined, or allowed through.

Where FormAegis fits

FormAegis is not a replacement for HubSpot. It is a small firewall layer in front of a HubSpot form path.

The setup pattern is:

1. A public form submits to FormAegis.
2. FormAegis scores the submitted fields, referrer, user agent, honeypot state, and blocklists.
3. Clean submissions are forwarded to a hidden HubSpot destination form.
4. Risky submissions are held in FormAegis quarantine before they can create CRM noise.

That is why our beta setup is deliberately narrow: Forms scope only. No Contacts API scope. FormAegis needs enough HubSpot access to read a form structure and create the hidden destination form during assisted setup. It does not need to read or sync your existing contacts.

The first rules are intentionally boring because boring rules are explainable:

The key difference is control. Native HubSpot protection decides inside HubSpot. FormAegis decides before HubSpot, then gives the operator a release or delete workflow.

In the public demo, the right panel sends a payload without filling the visible form. The lower panel shows recent submissions on the original HubSpot form. That screenshot is not a universal claim that every bot post bypasses every HubSpot defense. It is a concrete reminder to audit the active no-CAPTCHA paths bots may already know.

A practical audit before adding another tool

Before buying anything, map the ingestion paths.

Start with HubSpot:

1. Open Marketing > Forms and sort for forms with recent submissions.
2. Add or inspect the Spam Submissions column.
3. For each spam-hit form, confirm whether CAPTCHA is on.
4. Check whether the spam type is URL in Name Field, Filtered by reCAPTCHA, Unregistered Site Domain, Gibberish, Blocklisted Email Address, or something else.
5. Review blocked email domains and free-provider settings on the form.

Then inspect the site:

1. Search the public site source for old HubSpot embeds.
2. Check WordPress, Webflow, landing page builders, and old campaign pages.
3. Confirm whether non-HubSpot forms are enabled and which domains are tracked.
4. Retire old embeds only after checking workflows, reports, automations, and integrations that depend on the old form ID.

Finally, decide where you need control:

1. If the spam is already isolated by HubSpot and the queue is manageable, native protection may be enough.
2. If real leads are getting mixed with spam and operators need review control before CRM creation, add a quarantine layer.
3. If bots are hitting old public GUIDs, do the hardening work: remove old embeds, retire form IDs when safe, and stop treating page-level CAPTCHA as the only boundary.

The bottom line

HubSpot CAPTCHA is useful, but it is not the entire form-spam model. It protects a specific kind of visible form interaction. HubSpot's spam submissions view protects CRM records for many detected cases. Neither one automatically explains old no-CAPTCHA GUIDs, non-HubSpot capture paths, or the operator workflow after spam is detected.

If you are still getting spam with reCAPTCHA, do not start by adding a louder challenge to the page. Start by drawing the path the submission actually took.

That path tells you whether the fix is native HubSpot configuration, form cleanup, tracked-domain cleanup, or a firewall layer before the CRM.