Advanced Regex + Server-Side Email Validation to Block Bot Form Submissions

Marketing & Content Hub Lead Capture Tools
1

Hi everyone — looking for guidance and also proposing a product enhancement.

We’re seeing a large volume of bot form submissions that follow a very consistent and predictable pattern in the local part of the email address.

The pattern involves repeated substrings, which is simple enough to detect using modern regex — but not possible using HubSpot’s current validation tooling.

The pattern looks like:
lastnamelastname.firstname@realemaildomain.com

No real individual exists for these submissions, and emails bounce.

Anyone else run into this?

What we’ve already tried

  • Client-side JavaScript validation (bots bypass this by POSTing directly to the HubSpot forms endpoint)
  • This rule for the email property, which Hubspot cannot support:
    • ^(?![^@]*([A-Za-z]{3,})\1)[^@]+@[^@]+\.[^@]+$
  • Standard HubSpot email validation rules
  • CAPTCHA / anti-spam toggle
  • Behavioral filtering (no cookie, 0 page views, offline source, etc.) after the contact is created… no luck so far here
  • Honeypot fields - the bots appear too smart to fill in these hidden fields
  • Workflows + suppression lists… can’t seem to add regex for the contact email field unless I upgrade to Ops Hub enterprise? Would prefer not to if possible, especially because at that point the bot is already in our CRM.

None of these prevent the bad contact from being created, which pollutes reporting, wastes marketing contacts, and frustrates the sales team.

How can we add better regex support for form fields?

At the very least, how can I filter these bots out asap in workflows if they do enter Hubspot?

What HubSpot Support confirmed

  • HubSpot’s email validation uses the RE2 regex engine, which does not support advanced regex features like lookaheads, capture groups, or backreferences.
  • There is no server-side validation layer where advanced pattern checks can run before the contact record is created.
  • No native feature exists today to block contacts based on repeated-substring or structured email patterns.
  • No announced roadmap items for advanced regex or pre-contact filtering.

Why this matters

These bots are highly consistent and trivial to detect with regex — but impossible to block natively in HubSpot. Cleaning them up post-creation isn’t ideal.

What I’m requesting

1. Support for advanced regex (lookaheads, backreferences, capture groups) in form field validation, especially for the Email property.

2. A server-side “pre-contact filter” layer allowing HubSpot to reject bad submissions before creating a contact record.

3. More granular workflow time filters (seconds/minutes) to detect “submits too fast to be human” behavioral patterns.

These enhancements would massively improve form hygiene and reduce CRM noise.

If anyone has additional workarounds to catch repeated-pattern emails before contact creation, I’d love to hear them — and I encourage HubSpot Product to consider expanding regex and server-side validation capabilities.

For reference, I’m a super admin on a Marketing Hub Professional account with Sales Pro and Service Pro seats.

Thanks!

2

Hey @MMcLaughlin1 :waving_hand: and welcome, it’s a pleasure to have you here!
Thanks for sharing your suggestions with the HubSpot Community!
I’ve noticed a similar idea already present in our Ideas Forum: Add RegEx and wildcard support to list and workflow criteria.
To contribute, you can upvote the existing idea and share more details about your specific use case in the comments.
Now, let’s consult our Top Experts: Hi @SteveHTM, @Gaurav_Aggarwal and @Anton can you think of a workaround to help @MMcLaughlin1, please?
Thanks so much and have a wonderful weekend! :sun_with_face:
Bérangère

3

Your diagnosis matches what I would expect: once bots are posting directly to the HubSpot forms endpoint, client-side validation is no longer part of the path. Regex in the browser, honeypots, and page scripts can be useful for normal visitor submissions, but they do not help much when the request skips the page.

The part I would be careful with is forwarding clean submissions into a HubSpot form that has native CAPTCHA enabled. HubSpot’s form-level CAPTCHA can block direct API submissions, but it also blocks legitimate server-side forwarding into that same form with `FORM_HAS_RECAPTCHA_ENABLED`. So the intermediary pattern usually needs a no-CAPTCHA destination form that is not publicly exposed.

The architecture I would test is close to what you described:

1. Public form submits to a server-side handler you control.

2. The handler runs advanced regex / domain / payload checks before HubSpot.

3. Clean submissions forward into a hidden HubSpot destination form.

4. Risky submissions go to quarantine instead of becoming contacts.

5. False positives can be released once, with an idempotency key so two operators do not create duplicate contacts.

That last quarantine/release piece is the bit I would not skip. Pure reject/drop logic is fine for obvious bot patterns, but with email regex it is easy to hit edge cases where you want a human review lane rather than silently losing a real lead.

I’m working on a small HubSpot Forms-specific tool around exactly this setup. Basic assisted setup uses forms scope only, not contacts read/write. Happy to share the checklist if useful.

5

This is exactly the challenge we’re facing as well. Since HubSpot’s RE2 regex has some limitations and workflows run only after the contact is created, is there any reliable third-party tool that can perform server-side validation and block spam or bot submissions before they reach HubSpot?

7

We ran into a similar issue, and Form Guard has worked well for us. It performs server-side validation before the data is sent to HubSpot, so a lot of spam gets blocked upfront.

8

That’s interesting. How does Form Guard integrate with HubSpot? Does it sit between the website form and HubSpot, or does it work as a HubSpot app?

9

It sits between the website form and HubSpot. The form submission is first sent to Form Guard, where it performs server-side validation and spam checks. Only if the submission passes those checks is it forwarded to HubSpot to create or update the contact.

10

Thanks for the explanation! That sounds like the kind of approach we’re looking for. Besides spam detection, does Form Guard also validate email deliverability, phone numbers, and disposable email addresses before forwarding the submission?