This guide supports policy alignment between Talent Acquisition (TA), Legal, and Security teams when using the spam blocklist feature in Greenhouse Recruiting’s Real Talent suite.
The goal is to define a clear approach to security risk while protecting the candidate experience. By the end of these discussions, your organization should have clear answers to questions such as:
- What rationale must be present before IPs, email addresses, or email domains are blocklisted?
- Which roles are allowed to request, approve, and add/remove entries on the spam blocklist?
- What internal records are required for each blocklist entry?
- How should recruiters respond if a potentially legitimate candidate is affected?
Note: This document is intended as a reference for Greenhouse customers and their usage of Real Talent features. None of this is intended to be legal advice, neither are any of the answers provided intended to override or contradict the advice of your legal counsel.
Understanding the spam blocklist
The spam blocklist is a customer-configured security control that helps prevent malicious or unwanted applications from entering the recruiting pipeline.
Site Admins can add specific IP addresses, email addresses, and email domains to a blocklist in Greenhouse Recruiting. The blocklist can also be managed by Security through an API endpoint.
Applications originating from blocklisted sources are automatically rejected. They do not appear in the recruiting pipeline, and no rejection emails are sent.
This feature does not use AI or automated scoring. It enforces deterministic rules based on IP addresses and email domains selected by the organization. Its purpose is to filter obvious spam or malicious submissions before they reach recruiters.
Designing your spam blocklist process
Policies should define how the spam blocklist is used, who maintains it, and how decisions are documented and reviewed over time.
Key terms used below:
- Blocked sources: IP addresses, email addresses, or email domains added to the spam blocklist.
- Rationale: Concrete signals or events that justify adding or removing a source, such as repeated spam campaigns, malware links, or confirmed abuse reports.
Blocklisting is a strong control. Incorrect entries can silently exclude legitimate candidates who will not appear in the pipeline or receive rejection emails. Policies should balance security and efficiency against the risk of false positives.
1. Define when a source should be added to the spam blocklist
Policies should establish clear criteria for when blocklisting is appropriate and when less restrictive actions, such as monitoring or investigation, should be used.
Key Question: What rationale must be present before IPs, email addresses, or email domains are blocklisted?
| Example reason | How it might be implemented |
|---|---|
| High‑confidence malicious activity | Sources validated by Security as part of phishing, malware distribution, or other abuse incidents. |
| Repeated high‑volume spam | Sources generating a defined number of clearly irrelevant or abusive applications within a specified period. |
| Correlated with fraud findings | Sources repeatedly flagged through Fraud Detection processes. |
Recommendation: Use objective, repeatable thresholds, such as defined volume limits or confirmed Security incidents. Avoid blocklisting based on individual judgment or weak contextual signals.
2. Define roles and responsibilities for blocklist changes
Your policy should define distinct responsibilities for proposing, approving, and implementing changes.
Key Question: Which roles are allowed to request, approve, and add/remove entries on the spam blocklist?
| Example standard | How it might be implemented |
|---|---|
| Centralized Security ownership | TA proposes entries with rationale. Security reviews and approves. A designated Security or IT admin updates the blocklist. |
| Shared TA/Security model | Recruiters or TA Ops can submit suspected spam sources through a standard process. A joint TA + Security review group meets to approve additions/removals and makes changes to the blocklist. |
| Restricted implementation rights | Only a limited group of Site Admins can edit the blocklist. Proposals and approvals are tracked in a ticketing system or internal log. |
| Emergency blocklisting | During active abuse incidents, Security may add sources immediately, followed by documentation and review. |
Policies should clearly state who owns final decisions and how those decisions are recorded.
3. Define how decisions for blocklist standards are recorded
Although blocked applications do not enter the pipeline or receive rejection emails, internal documentation may be required for governance and edge cases.
Key Question: What internal records are required for each blocklist entry?
Your policy might require that, for each blocklisted IP, email or domain, the following be recorded in an internal log or ticket:
- The blocked source (IP address, email or email domain).
- The date added, and the requester and approver.
- The reason and supporting rationale, such as incident references or spam examples.
- Any reviews, updates, or removals, including dates and rationale.
These records support internal audits, incident response, and legal review.
4. Define candidate experience and communication
Policies should define how teams respond when a potentially legitimate candidate is affected.
Key Question: How should recruiters respond if a potentially legitimate candidate is affected?
Your policy should address:
- What recruiters are allowed to share about spam controls in general, and which topics are prohibited to prevent malicious actors from circumventing your controls?
- When is it appropriate to re-invite a candidate to reapply through an alternative channel?
- How are suspected false positives escalated to Security or TA Operations for investigation?