Spam Filter is not a separate SDK, a separate <script> or a separate endpoint. It's a rule set that runs inside every Procaptcha verification — the same /verify call your backend already makes to Prosopo when a user submits a form or hits a protected endpoint. Enable the filters you want in the dashboard; the next verification enforces them. No new integration surface, no extra network hop, no code deploy.
Two rule layers evaluated per verification:
- Email Filter — matches on the email address the form submitted (or that your backend passed to
/verify). Curated patterns for throwaway addresses, optional normalisation, custom regex blocklist, disposable-domain detection via DNS. - Traffic Filter — matches on the network the request came from. Eight independent toggles for VPN, proxy, Tor, datacenter, crawler, mobile, satellite, and generic "abusive" networks scored by our upstream reputation feed.
Each layer can be toggled independently per site key, so the same Prosopo account can run tight rules on your signup endpoint and permissive rules on your comment form.
If your inbox is filling up with fake signups, your contact form is generating obvious junk, or your WordPress site keeps sending spam emails you didn't author, the cause is almost always the same: a bot is submitting your form directly, faster than any keyword filter or honeypot can keep up. The fix isn't a smarter inbox rule. It's stopping the submission before the form processes it.
Anti-spam measures that only run after submission (Akismet, server-side keyword filters, post-hoc email validation) treat the symptom. Prosopo's Spam Filter treats the cause — it evaluates during the Procaptcha verification, so an abusive request is rejected before your form's success flow runs.
Most signup spam doesn't come from random email accounts. It comes from a small set of evasion techniques that turn a single mailbox into thousands of apparent addresses, or from networks of disposable inboxes that exist only to bypass verification.
The Email Filter catches both:
- Throwaway address normalisation. Throwaway variants from Gmail, iCloud, Yahoo and other major providers all resolve to the same mailbox. The filter optionally normalises addresses before applying your rules, so one rule catches every variant.
- Curated default patterns. A maintained ruleset that targets throwaway address tactics from the major providers used to bypass signup verification.
- Custom blocklist. Add your own patterns to block addresses unique to abuse you're seeing.
- Disposable-domain detection. Optionally rejects addresses from known throwaway providers — and follows the domain through redirects, CNAMEs and MX records so freshly-registered throwaway domains can't slip through by pointing at a known backend.
The Traffic Filter rejects requests by the type of network they came from. Each filter is an independent toggle, so you can build the exact policy your audience needs:
| Filter | What it blocks | Recommended for |
|---|
| Abusive networks | Networks with a strong abuse signal | Everyone — on by default for all accounts |
| VPN | Known consumer VPN services | Sites with high signup-fraud exposure |
| Proxy | HTTP, HTTPS and SOCKS proxies | API endpoints and high-value forms |
| Tor | Tor exit nodes | Most consumer-facing forms |
| Datacenter / Hosting | Cloud and hosting IP space | Sites whose users browse from residential networks |
| Crawler | Known automated bots | Most forms (excluding documentation/marketing pages) |
| Mobile | Cellular networks | Niche — only when fixed-line access is required |
| Satellite | Satellite internet | Niche — only when ground-based access is required |
Blocks are reported back to your application with a distinct reason for each filter, so you can show users a tailored message ("Please disconnect your VPN and try again", "This form isn't supported over Tor", and so on) rather than a generic failure.
- Free tier accounts get abusive-network blocking on by default. It's the single highest-signal traffic filter and is safe to leave on for any account. The remaining seven traffic filters and the Email Filter are opt-in per site.
- Professional and Enterprise include every filter, per-site tuning, custom regex patterns and Gmail-style address normalisation.
Because Spam Filter runs inside the Procaptcha verification, you need Procaptcha (or Prosopo Protect) on the endpoint first — the widget on a form, or the server-side / edge Protect integration in front of an API. If you haven't yet, start with Procaptcha for a form-level integration or Prosopo Protect for a whole-site / API deployment; then turn Spam Filter on in the dashboard.
Full capability Partial / caveat Not available
| Capability | Prosopo Spam Filter | Akismet | reCAPTCHA / hCaptcha |
|---|
| Network-level blocking (VPN, Tor, datacenter) | ● | ● | ● |
|---|
| Email signup-evasion blocking | ● | ● | ● |
|---|
| Disposable-domain detection | ● | ● Limited | ● |
|---|
| Custom blocklists | ● | ● | ● |
|---|
| Per-block reason codes for tailored user messages | ● | ● Limited | ● |
|---|
| GDPR-compliant data handling | ● | ● Varies | ● |
|---|
If you're trying to stop spam on a specific form plugin or platform, jump to the install guide:
Full details of the Email Filter rules, the eight Traffic Filter toggles and their block reasons are in the docs: