When to use this
Use this when public WordPress forms receive spam, fake users, bot traffic, or abusive submissions.
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 Install and connect the Verifence WordPress integration, then create or select the Shield site for the protected domain.
- 02 Enable protection only on the registration, WooCommerce, comment, contact, or lead forms that need it, and test each form while logged out.
- 03 Use Shield verification for bot behavior and pass the submitted email when account rules should be enforced with the form.
- 04 Submit both legitimate and intentionally suspicious test cases before enabling strict blocking on a production client site.
- 05 Review stopped attempts and refine domain, IP, or country rules when a repeated source pattern becomes clear.
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.