Blacklist
| Field | Value |
|---|---|
| Audience | public |
| Page type | reference |
| Area | sg-admin |
| Updated | 2026-05-14 |
How the admin Blacklist module works — block unwanted submissions and patterns.
The Blacklist module in the admin is the per-site surface that blocks unwanted form submissions, IP addresses, and content patterns from reaching the site's capture surfaces. Where forms accept submissions and tracking captures events, Blacklist applies the rules that filter out submissions before they land as records. This page is the Reference definition.
What is this for?
Read this page when you want the structural definition of the Blacklist module — what gets blocked, what rules apply, and where blocked submissions surface.
Good use cases
- You hit a wave of spam form submissions and want to block the source.
- You are scoping spam protection for a new site.
- You are explaining to a stakeholder how SGEN handles unwanted-submission filtering.
What NOT to use this for
- Step-by-step procedures — open the relevant Guide.
- Per-release shipped change — open What's New or Changelog.
- Reputation management or legal blocking — out of scope.
How this connects to other features
- SG-Admin Overview — parent surface.
- Form Submission Workflow — the workflow Blacklist filters at.
Where to find it
Open SG-Admin for the active site. Blacklist is in the sidebar under the security or content-moderation group. Admin access is required to add, edit, or remove rules.
Definition
The Blacklist module is the per-site filter that blocks submissions and capture events matching defined rules. Rules can target IP addresses, email patterns, content patterns, or composite criteria. Submissions that match a rule are rejected at capture time; they do not become records and they do not fire downstream automation.
The defining property is filter-at-capture. Blocking happens before the Form Submission Workflow's record-landing handoff; blocked submissions never enter the platform.
Purpose
The purpose of this page is to define the Blacklist module as a Reference layer rather than as a configuration walkthrough. It explains what kinds of rules exist, what gets filtered, and where blocked submissions surface (if at all).
Scope
This page covers the Blacklist module at the Reference level.
The page covers:
- The rule kinds the module supports.
- What gets filtered and where the filter applies.
- Where blocked-submission state surfaces.
- The boundary against reputation management and legal blocking.
- Per-step rule configuration — Guides.
- Per-release shipped change — What's New or Changelog.
- Custom blocking logic beyond platform defaults — out of scope.
Rule kinds
IP-based rules
Block submissions arriving from defined IP addresses or IP ranges.
Email-pattern rules
Block submissions where the form's email field matches a defined pattern (specific domains, character patterns).
Content-pattern rules
Block submissions whose body content contains defined patterns (URL spam patterns, link counts above threshold, language patterns).
Composite rules
Combinations of the above for finer control.
Site · SG-Admin · Blacklist
Active rules
| Type | Pattern | Hits | Last block |
|---|---|---|---|
| IP | 192.0.2.0/24 | 147 | 14 min ago |
| *@spammail.example | 89 | 1h ago | |
| Content | contains: viagra OR cheap-loan | 234 | 3 min ago |
| Content | link count > 5 in body | 62 | 2h ago |
Where blocked-submission state surfaces
Blocked submissions do NOT land as records (that is the point). Their existence surfaces in the Blacklist module as hit-counts per rule. Operators reviewing rule effectiveness see how often each rule has blocked submissions in the visible time window.
Constraints and boundaries
The Blacklist module is a Reference area for the at-capture filter. It is not a substitute for reputation management or for legal blocking processes.
Use this Reference for:
- Understanding what the Blacklist module filters.
- Confirming where rules apply and where hit-counts surface.
- Reputation management — out of scope.
- Legal-mandated blocking — separate compliance process.
- Per-step rule configuration — Guides.
Public boundary
This page is intentionally public-safe.
Examples
Example 1 — Spam wave triggers IP-range block
A wave of submissions arrives from one IP range. The operator opens Blacklist, adds an IP-range rule, watches the hit-count climb as the rule blocks subsequent attempts. The submissions never reach My Forms.
Example 2 — Operator scopes content-pattern rules
The operator reviews recent unwanted submissions, identifies a recurring content pattern, adds a content-pattern rule. The rule blocks future matching submissions at capture.
Example 3 — Stakeholder asks "are we filtering spam?"
The operator opens Blacklist, shows the rule list and the hit-counts. The Reference grounds the conversation in the platform's filter model.
Documentation guidance
Use this page as the structural definition for the Blacklist module. Procedural detail belongs in Guides; per-release behavior change belongs in What's New or Changelog.
Reading order
Open this page when scoping spam protection or troubleshooting unwanted-submission questions.
Related reading
- SG-Admin Overview — parent surface.
- Form Submission Workflow — the workflow Blacklist filters at.
Vocabulary cross-reference
- Blacklist is the per-site filter that blocks submissions matching rules.
- Rule is one filter expression (IP-based, email-pattern, content-pattern, composite).
- At-capture describes when filtering happens — before record landing.
- Hit count is the number of times a rule blocked a submission in the visible window.
Maintenance discipline
When Blacklist behavior changes across releases (new rule kind, new filter scope, new hit-count surface), update this Reference and log the change in Changelog.
Related reading
| Topic |
|---|
| SG-Admin |
| Form Submission Workflow |