Form protection

Overview

Form protection is designed for SaaS signups, newsletters, lead capture, free trials, waitlists, and checkout forms. Each integration has a public site key, an exact or wildcard origin allowlist, an independent rate limit, usage analytics, and its own revocation boundary. It never exposes a developer API key.

Quickstart

1. Open Form protection and choose Protect a form.
2. Name the integration and add each origin that hosts the form, such as https://example.com. Origins contain a scheme, host, and optional port, never a path.
3. Select verification depth and a blocking policy. Quick is the lowest-latency default and costs 0.5 credit per conclusive check.
4. Copy the generated script tag before the closing body tag.

<script src="https://api.mailtooth.com/form-protection/embed.js" data-mailtooth-key="YOUR_PUBLIC_SITE_KEY" defer></script>

By default, every form containing an input[type="email"] is protected. Set custom selectors in the dashboard when only specific forms should be intercepted.

What the script does

1. Finds matching forms on load and whenever the DOM changes.
2. Adds an off-screen, non-tabbable honeypot field.
3. Verifies on email-field blur and caches the decision for that exact value.
4. Pauses submission until a decision is available and preserves each submit button's previous disabled state.
5. Uses native setCustomValidity and reportValidity for accessible validation.
6. Resubmits with requestSubmit, preserving the clicked submit button and existing submit handlers.

Script configuration

<script src="https://api.mailtooth.com/form-protection/embed.js" data-mailtooth-key="YOUR_PUBLIC_SITE_KEY" data-mailtooth-form="#signup" data-mailtooth-email="input[name=email]" data-mailtooth-fail-open="false" defer></script>

To render errors in your own element, add data-mailtooth-error="element-id" to the email input. The script updates that element and marks it as an ARIA live region.

Blocking policy

Invalid syntax, missing domains or MX records, disposable domains, and conclusive undeliverable mailbox results are always blocked. An integration can additionally block the following outcomes.

Quick costs 0.5 credit, Standard costs 1 credit, and Deepcheck costs 2 credits. Unknown outcomes are refunded through the same ledger as API verification.

Browser events

Events bubble from the protected form. Use them for analytics or presentation changes, not as server-side authorization signals.

document.querySelector("#signup").addEventListener("mailtooth:blocked", (event) => {
  analytics.track("signup_email_blocked", { reason: event.detail.reason });
});

SPAs and dynamic forms

No reinitialization is needed after client-side navigation or modal rendering. The embed observes added elements and enhances each form once. Remove duplicate script tags so a form is not managed by multiple site keys.

Existing synchronous and asynchronous submit listeners still run after verification. The normal browser submission path is retained, including the original submitter when supported.

Security and privacy

• The site key is public by design. It can only request policy decisions and cannot call developer, billing, team, or bulk APIs.
• Browser requests must match the stored origin allowlist. Use separate integrations for production, staging, and local sites.
• Only the email, public site key, and honeypot value are sent to MailTooth. Raw verification evidence is not returned to the page.
• Revoke a copied or retired integration immediately. Its earlier analytics remain available.

Failure behavior

The default is fail open: if verification times out or is unavailable, submission continues so an outage does not lose a signup or purchase. Set data-mailtooth-fail-open="false" for a strict flow. Fail-closed mode shows a retry message and prevents submission.

In-flight checks are canceled when the address changes. A per-integration rate limit returns HTTP 429 when exceeded; the script then applies the selected failure behavior.

Troubleshooting