When to use this
Use this when fake accounts create operational load, abuse trials, submit spam, or damage your metrics.
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 Run Email Validation before account creation to identify disposable, role-based, unreachable, mistyped, or explicitly blocked addresses.
- 02 Verify a Shield token on the backend to separate legitimate browser interactions from automated submissions.
- 03 Apply narrow block-list rules for repeated email, domain, IP, CIDR, or country patterns supported by your abuse evidence.
- 04 Begin in logging or review mode when tuning a new policy, then enforce only signals with an acceptable false-positive rate.
- 05 Monitor blocked attempts and support reports so legitimate users have a recovery path and broad rules can be corrected quickly.
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.