When to use this
Use this when signup forms are hit by automated registrations, spam, promo abuse, or trial abuse.
How Verifence evaluates it
Shield protects the browser interaction around a form, while Email Validation evaluates the lead data inside it. The widget issues a short-lived proof-of-work challenge, evaluates client and server signals, and produces a signed, single-use token that your backend verifies before accepting the submission.
Domain-bound site keys
Each Shield site can restrict which origins may request challenges, preventing a public site key from being reused on an unapproved domain.
Proof of work
The browser completes a computational challenge before a valid token can be issued.
Browser and behavior signals
Fingerprint, automation, timing, interaction, and honeypot signals contribute to risk without being trusted as proof on their own.
IP and geography
Shield can apply IP reputation, country rules, account block lists, and automatic blocking for repeated failures.
Email and message checks
The siteverify request can include email and free-text fields so account email rules and spam classification are evaluated with the form submission.
One-time verification
Tokens are short lived, bound to a site and action, and consumed when verified to prevent replay.
How to do it
- 01 Create a Shield site, restrict it to the signup domain, and keep the generated secret on the backend.
- 02 Load the Shield widget on the form and include the hidden shield-token value with the submission.
- 03 POST the token to /shield/siteverify on the server and verify that it belongs to the expected site and signup action.
- 04 Include email, free-text, and honeypot values when the same decision should also apply email rules or spam classification.
- 05 Create the account only after verification succeeds, and follow the documented service-error behavior so a Verifence outage does not silently become a permanent signup outage.
How to act on the result
Accept the form when the backend verifies a valid, unconsumed token for the expected site and action.
Reject filled honeypots, missing or invalid tokens, replayed tokens, origin failures, and submissions that violate an enforced rule.
Use spam scores and non-terminal risk signals to queue ambiguous messages instead of treating every suspicious submission identically.
Follow the documented fail-open integration behavior for Verifence service errors so an outage does not take down a client form.
Implementation notes
- Create a separate Shield site for each client domain or protection boundary and keep the secret key on the server only.
- Always verify the token on the backend. A browser-side success state alone is not an authorization decision.
- Shield verifications use a separate monthly allowance from email, URL, and file scan credits.