How to Add a Honeypot to a Mautic Form (to Mitigate Spam Submissions)

By /

Spam bots are a perennial pain when using forms. A honeypot is a non-intrusive technique: you add an input that is invisible to human users (via CSS or hiding) but visible to bots; if it is filled, you know a bot submitted the form. With Mautic’s flexibility, you can integrate a honeypot fairly cleanly and use campaign logic to discard the bad submissions.

In this tutorial, we’ll walk you through:

  1. Creating a custom contact field to serve as the honeypot
  2. Adding that hidden field to your form
  3. Configuring campaign logic (or form logic) to detect bot submissions and act on them
  4. Testing and caveats / enhancements

Let’s dive in.

1. Create a Custom Field for the Honeypot

First, you’ll need a contact field to map the honeypot input.

  1. In your Mautic dashboard, click the ⚙ (Settings / Configuration) icon in the top right, then choose Custom Fields (under Contacts).
  2. Click “+ New” (or “Add New Field”)
  3. Configure the field:
    • Label: e.g. Honeypot or Honey or any innocuous name
    • Object: Contact
    • Data Type: Text (string)
    • Group: You can put it in “Core” or whichever group you prefer
    • (Optional) You can leave it unpublished initially, but typically you’ll publish it so it’s usable.
  4. Save the field (Save & Close). The field is now part of your contact schema.

Note: in large Mautic installs, adding custom fields can lock the contacts table; newer versions or configurations might allow background creation of the underlying column. Learn more about Custom Fields at the Mautic documentation.

2. Add the Honeypot Field to Your Mautic Form

Next, embed the honeypot field into whichever form(s) you wish to protect.

  1. Go to Components → Forms
  2. Edit the form you want to protect (or create a new one)
  3. In the form editor, add a field:
    • Choose the field type: you can use a Text field mapped to your custom honeypot contact field
    • In Mapped Field (or Contact Field) dropdown, map it to the custom “Honeypot” field you just created
    • Label it (this is just internal; since the field will be hidden, users won’t see it)
    • Under Attributes (or “Field container attributes”), add:

      style="display:none;"

      This hides the field’s container from human view, but often bots (or automated form fillers) will still see it and fill it.
    • Alternatively, some tutorials embed CSS via an HTML area field to hide the honeypot. But using inline style="display:none;" is simplest and effective.
  4. Save the form.

Note: Mautic’s Forms documentation notes that Mautic “recognizes if there’s data in a honeypot CAPTCHA field and understands that it can’t be a human submitting the Form.” Also the documentation describes a “CAPTCHA” field type which may act in the same way (i.e. hidden answer field acting as honeypot).

Learn more about the honeypot method at the Mautic blog.

3. Use Campaign or Form Logic to Filter Out Bot Submissions

Now that the honeypot field is part of your form, you need logic to detect when it is filled (i.e. a non-empty value) and treat that submission as spam. A common approach is to start your campaign logic with a conditional test of the honeypot field, and if it’s non-empty, delete or discard the contact (or stop processing). If empty, let it proceed into the “real” campaign path.

Here’s a detailed flow:

  1. In Campaigns, open (or create) the campaign tied to this form
  2. As the very first step (or event) in your campaign, add a Condition:
    • Condition Type: Contact Field Value
    • Field: your custom Honeypot field
    • Operator: Empty
    • This condition checks: is honeypot blank? (i.e. good submission)
  3. The positive branch (honeypot blank) should lead into your normal campaign flow (e.g. send emails, assign segments, etc.).
  4. The negative branch (honeypot not blank) can have an Action like Delete Contact (or tag as “Spam” / remove from campaign). Many users prefer to delete to avoid polluting segments.
  5. Connect the campaign path accordingly:
    • Entry point from the form → Condition
    • If “true / positive” → continue normal campaign
    • If “false / negative” → execute the spam action
  6. Save the campaign and verify connectivity.

In your client-tutorial you already had similar logic: “if the honeypot is filled, delete contact; else proceed.” That is exactly the standard approach.

Important: ensure this honeypot condition executes before any other steps (emails, tags, etc.) in your campaign. Otherwise, a spam bot might trigger other side effects before being filtered out.

Also note: if the form is a Standalone form (i.e. not tied to a campaign), the logic has to live in the form’s Form Actions (if available), or you may instead route submissions into a campaign for handling. Many tutorials caution: “If you use a Standalone Form and you have the action to send email to user, you must disable that and replicate logic in a campaign” or otherwise you will bypass the honeypot logic.

4. Testing & Caveats

Testing

  • Publish the form and embed it where needed (on a landing page, website, etc.)
  • Submit a “normal” test: leave honeypot blank, fill in required real fields — ensure the contact moves through the positive path of your campaign
  • Simulate a “bot submission” test: Use browser dev tools or direct API/form POST, and populate the honeypot field with any dummy value — ensure the contact is captured by the negative branch and gets deleted / filtered
  • Check in Contacts → Recycle Bin (or deleted contacts) to verify deletion if applicable
  • Monitor over time for spam flood — see if this honeypot cuts down false entries

Caveats & Enhancements

  • Not perfect vs. advanced bots: Sophisticated bots might detect hidden fields or parts of your CSS and avoid filling them. A honeypot is a basic line of defense, not bulletproof. Some forum users recommend combining with CAPTCHA, rate-limiting, IP blocking, or other anti-spam measures.
  • Mautic version compatibility: The exact UI labels or location of “Mapped Field”, “Attributes”, or “Form Actions” may differ across Mautic versions (4.x, 5.x, etc.). Always check your version’s UI.
  • Hidden vs. CSS hidden: Some bots ignore CSS, others parse HTML and see the hidden field anyway. Using style="display:none;" is common but not absolutely stealth.
  • Form Actions for Standalone forms: As mentioned, if your form directly sends email or performs actions, you must control the submission path to include honeypot filtering.
  • Retention & logging: Some prefer tagging spam contacts instead of outright deleting, so you can audit them.
  • Multiple forms: If you have many forms, you might reuse the same honeypot field across them. But ensure each form has the hidden input.
  • Additional obfuscation: Some users rename the field label or input name unpredictably (e.g. xyz123) to reduce bot targeting.
  • CAPTCHA fallback: In especially aggressive spam scenarios, integrate reCAPTCHA or similar in addition to honeypot. Mautic supports CAPTCHA / reCAPTCHA as a field type.

Tips & Takeaways

  • Honeypots are effective, but not foolproof. Use alongside other defenses (rate limits, CAPTCHA, IP blocking).
  • For standalone forms, ensure any direct form actions (like immediate emails) are disabled or handled via campaign logic.
  • Rename or randomize the honeypot field name to reduce bot targeting.
  • Always test after migrating Mautic versions, since UI and field handling may change.

By following this setup, you can add a nearly invisible layer of spam defense to your Mautic forms — protecting your campaigns without frustrating real visitors.

Related Posts

Scroll to Top