How to contact SURBL and what are their policies regarding delisting and support for ESPs?
Published 14 Jun 2025
Updated 16 Oct 2026
12 min read
Summarize with
Updated on 16 Oct 2026: We clarified SURBL's delisting follow-up steps, ESP access rules, and category-specific evidence requirements.
Start a SURBL delisting request through its lookup and removal workflow. Use the SURBL lookup page, check the listed domain or IP, then follow the removal form. The SURBL contact page directs general questions to the discussion list and provides routes for announcements and data-feed access. It tells people not to send removal requests to the discussion list.
For email service providers (ESPs), the important expectation is that the standard SURBL removal process is not a feedback loop. SURBL's public MULTI dataset is a URI reputation blocklist (blacklist). In email filtering, it checks domains and IP addresses used as websites in message bodies, rather than SMTP sending IPs or sender addresses. An ESP should not expect the removal process to identify the exact customer, provide a complaint sample, or explain the listing like a mailbox provider abuse team.
The practical process is to confirm the listed domain or host, find every tenant or campaign that used it, stop the bad traffic, document the fix, and submit the removal form linked from the lookup result. SURBL's current contact instructions do not name a separate email fallback for failed form submissions. Keep your own message and redirect logs because the public removal process does not promise account-level attribution.
How to contact SURBL
SURBL Lookup domain or IP field for checking blacklist status before a removal request.
The best first contact is the removal workflow tied to the lookup result. SURBL's public wording is consistent: start with lookup, then follow the form. The discussion list is for general questions, not delisting. Use the web lookup manually; its form prohibits automated lookups. Automated checks belong on an authorized DNS or data-feed service.
|
|
|
|---|---|---|
Lookup form | Removal | Primary path |
Discussion list via contact page | General questions | No removal requests |
Announcement list | Dataset and service updates | Low volume |
Data feed form | Professional data access | Access request |
Use the route that matches the request.
Removal support does not promise customer attribution
SURBL publishes removal steps, but the standard process does not promise sender-account attribution or a complaint sample. Prepare a concise incident summary and keep the affected domain contained while SURBL reviews the request.
- Test the domain or IP shown in the message body, then retain the exact URL, redirect chain, tracked link, and hosted landing page for attribution. Do not start with the sending IP unless the IP itself appears as a website.
- Follow SURBL's removal form. The SURBL FAQ repeats the lookup-first process.
- Do not send removal requests to the discussion list or publish customer evidence there.
- Save the lookup result, listed set, submission time, message IDs, and any delisting reply. That history helps when the same customer or domain appears again.
SURBL usage and support rules for ESPs
SURBL separates removal requests from data-service support. Its usage policy describes free use for organizations with fewer than 1,000 users or fewer than 250,000 scanned messages per day, but separately prohibits Free Query Service use by organizations with 1,000 or more users. Read these clauses together; low message volume does not override the user limit. Free access also excludes embedding SURBL data in a paid product or service. High-volume systems should arrange data-feed access and query a local copy.
|
|
|
|---|---|---|
Free-use description | Free Query Service, subject to exclusions | Under 1,000 users or under 250,000 messages daily; user and commercial restrictions still apply |
1,000+ users | Sponsored Data Service | Free Query Service prohibited |
High-volume scanning | Data feed and local queries | Avoid public-query load |
Product or service using SURBL intelligence | Valid SDS usage agreement | Paid embedding is excluded from free access |
SURBL's published access rules for professional users.
Technical support does not replace removal evidence
SURBL says a Sponsored Data Service subscription includes unlimited access to its technical support team. That support is for data use; the published terms do not promise priority delisting or a removal deadline. An ESP requesting review of a listed domain is not the same as an ESP licensing SURBL data. Keep tenant attribution and incident evidence in your own systems.
What SURBL expects before delisting
SURBL expects the condition behind the listing to be removed. Its list removal instructions require CR, PH, and MW requesters to clean and secure the website, content-upload systems, and DNS infrastructure. For an abuse or click-tracker listing, stop the responsible campaign and contain the account or redirect involved. A request that only says the sender is legitimate does not explain why the domain will stay out of the blacklist.
SURBL delisting workflow with lookup, URL identification, containment, evidence, form submission, and recheck.
Match the evidence to the category. SURBL describes CT as click-tracker domains used for email sent without confirmed opt-in, including mail reaching spamtraps. Review consent records and list-acquisition practices for a CT case. DM identifies disposable mail domains, so that category alone does not establish a compromised website. If you believe a listing is a false positive, explain the category mismatch and provide supporting evidence through the same removal form.
Prepare the removal request like a small incident report. Show ownership, scope, remediation, and why the listing should not recur. If the domain belongs to thousands of customers, explain how the ESP narrowed the source. That makes the request actionable without asking SURBL to investigate the entire tenant base.
Suggested evidence for a SURBL removal requesttext
Domain: example.com Listed set: ABUSE, PH, MW, CR, CT, DM, or unknown Relationship: ESP shared domain or customer link domain First observed: YYYY-MM-DD HH:MM UTC Recent sends: relevant campaign IDs and message IDs Message evidence: full original headers and body, if requested URLs seen: exact body URLs and redirect chain Consent evidence: acquisition source and confirmed opt-in records, where relevant Remediation: action taken, affected account or URL, and completion time Recurrence controls: what prevents the same abuse Request: review removal after remediation, or explain the suspected false positive
SURBL does not publish a delisting deadline
The public removal instructions do not specify a response-time guarantee. Treat estimates such as one or two days as anecdotes, not an SLA. The quick SURBL response checklist explains how to submit a clearer request.
If SURBL does not answer your removal request
Recheck the domain in the official lookup before following up. No reply does not establish whether it is still listed. If you received a confirmation ticket, follow its reply instructions and keep the case history together. Raymond Dijkxhoorn's 2014 SURBL mailing-list reply explicitly directed requesters to reply to the ticket created by the form. This is historical guidance; follow any newer instructions in your confirmation.
- Check spam folders and quarantine for the confirmation or reply. Make sure the contact address accepts messages about listed URLs.
- Follow up on the existing ticket with the current lookup result, completed remediation, and any new evidence. Avoid duplicate submissions that fragment the case history.
- If the form fails, record the error and time. Use the contact page for a general question about the broken workflow, without posting the removal request or private evidence to the discussion list.
- If SURBL shows the domain as clear but delivery problems continue, compare fresh bounce messages with the affected URLs. Ask the receiving administrator to check cached reputation data or another filtering rule.
These are troubleshooting steps, not an escalation timetable. SURBL controls its dataset; receiving systems control their own filtering decisions. Removal does not guarantee inbox placement.
What ESPs should expect
An ESP usually wants the customer ID, sample recipients, and the precise campaign that caused the listing. SURBL's public removal process focuses on the listed domain or IP, so it does not promise that account-level evidence. The lookup can confirm a listed domain or IP, but the ESP has to map that object back to a customer.
What ESPs often want
- The tenant, campaign, template, and sender responsible for the listed URL.
- A sample message, recipient domain, timestamp, or trap source that explains the listing.
- A clear note that the domain was removed and the reason it was listed.
What the public process provides
- The listing status of the checked domain or IP in a SURBL dataset.
- A form-based path for review after the sender or site owner fixes the source.
- No published promise of a customer name or account-level reason.
Shared infrastructure exposes unrelated customers to the same listing. A single tracking domain can handle traffic for many customers. If that domain enters a blocklist or blacklist, unrelated tenants can experience delivery problems even when one sender caused the event. Document how the abusive path was isolated and closed; saying that most traffic is opt-in does not explain the fix.
- Use customer-specific tracking domains to improve attribution. Different subdomains under one listed parent do not guarantee isolation: SURBL's implementation guidelines explain that wildcard queries also match subdomains of a listed domain.
- Log every redirect target, including destinations beyond the first click domain, because SURBL checks can involve URLs in and behind messages.
- Use Suped's email tester to inspect a real message when bounce text or filtering clues are inconsistent. Keep the original message for the investigation.
How to identify the customer behind a SURBL listing
The fastest ESP workflow is a join between the listed domain or host and message logs. Start with the lookup result, then expand to exact URLs, redirects, link shorteners, landing pages, and customer-uploaded content. If the result maps to a shared click domain, group sends by customer and template during the alert window. If it maps to a final destination, group by customers that placed that destination in campaigns.
Log join pattern for ESP attributiontext
Find every send that used the listed domain or host: - tracked_link_domain = listed host or affected subdomain - redirect_target_host = listed host or affected subdomain - message_id -> customer_id -> campaign_id - send_time between first alert minus 7 days and now Group by: - customer_id - campaign_id - template_id - redirect_target - complaint rate - bounce text The seven-day window is a starting point, not SURBL policy. Extend it to cover older campaigns and still-active redirects.
Look for the outlier. A customer with a sudden volume spike, a new imported list, a new redirect destination, or a complaint jump gives the incident team a concrete lead. If the ESP has poor link attribution, the SURBL listing exposes a logging gap that should become part of the incident remediation.
|
|
|
|---|---|---|
New URL | Unreviewed destination | Review destination and account |
Volume spike | Changed behavior | Investigate and limit risky sends |
Complaint increase | Recipient objections | Review consent and contain abuse |
Redirect change | Different final destination | Trace the full chain |
Useful signals when one listed domain maps to many tenants.
Do not submit before containment
A delisting request before containment creates a repeat-listing risk. Pause the account, block the URL, disable the redirect, or remove the compromised page first. Then submit the request with exact times and remediation details.
SURBL listing categories and DNS query policies
SURBL's public MULTI list checks URI domains and IP addresses used as websites. A clean sending IP does not clear a listed link domain. Check the category and query status before deciding whether to request delisting or fix your data access.
- Start with domains and URLs in the message body, including tracking links and final destinations.
- The removal path starts at lookup and continues through the form. Public discussion lists are not the delisting queue.
- The public MULTI dataset combines DM, PH, MW, CT, ABUSE, and CR. The DNS response's last octet is a bitmask, so one result can indicate more than one category. Use SURBL's dataset definitions to interpret the result.
- A 127.0.0.1 response from the public nameservers means query access is blocked. It is not a listing category for the checked domain.
- Large ESPs and commercial filtering services must follow the data-access agreement rather than assume public DNS queries are unrestricted.
- SURBL does not publish a complete list of receivers using its data. Compare a listing with fresh bounce text and message URLs before attributing delivery problems to it.
Blocklist checker
Check your domain or IP against 144 blocklists.
Suped's blocklist checker provides a broader check after the SURBL lookup. A view across blocklists helps distinguish one URI listing from a wider reputation issue. Use that evidence to decide whether the response needs a delisting request, a customer suspension, or a wider investigation.
Operational response timing
These bands are internal incident targets, not SURBL commitments.
Triage
0-2h
Confirm listing and affected host.
Contain
2-8h
Pause sender or remove URL.
Submit
8-24h
Send evidence after fixing source.
Escalate
48h+
Recheck and update evidence.
Where Suped fits
Suped's product connects blocklist monitoring with DMARC reporting and SPF and DKIM checks. An ESP or MSP can review the affected domain, check authentication changes, and route the investigation to the team responsible for the customer or brand.
Blocklist monitoring page showing domain and IP checks across blocklists with importance and status
Suped's alerts and multi-tenant visibility help teams track affected domains and recurring listings. Use the ESP's own message and redirect logs for customer attribution; SURBL controls delisting.
Check domain authentication and sending health alongside the SURBL investigation. Suped's domain health checker provides that first pass. DMARC changes do not remove a SURBL listing. Handle authentication failures and listed URLs as separate findings.
A practical monitoring workflow
- Use monitoring alerts to begin investigating a blocklist or blacklist event.
- Pause the customer, URL, redirect, or template that maps to the listing.
- Send SURBL a short incident summary with evidence and remediation.
- Keep monitoring after removal to detect repeat listings.
If SURBL appears alongside poor inbox placement, review complaints and fresh bounce messages as well as recent list imports and redirect changes. The SURBL deliverability practices explain how to investigate the sending controls behind repeat listings.
A practical way to handle SURBL
Start at lookup, collect evidence, fix the source, submit the removal request, and monitor the domain after removal. If you run an ESP, use your message logs and redirect records to identify the responsible customer. Follow up through the existing ticket when its instructions allow replies; do not rely on a separate ESP delisting queue.
Frequently asked questions
SURBL does not publish a separate ESP delisting queue. ESPs use the same lookup and removal workflow. Sponsored Data Service subscribers receive technical support, but the published terms do not promise priority delisting or a removal deadline. Licensing SURBL data and requesting review of a listed domain are separate activities.
Use the lookup form. SURBL's current contact instructions and FAQ direct removal requests there and do not name a separate email fallback. Follow the reply instructions on any confirmation ticket you receive.
The public removal process does not promise customer attribution. Match the listed domain or IP to your own message logs, redirect logs, customer IDs, and campaign records.
SURBL does not publish a complete live list of every receiver or filter stack using its data. Receivers decide how to use that signal. A listing alone does not establish which mailbox providers will reject or filter a message.
No. DMARC evaluates email authentication against the visible From domain, while SURBL MULTI checks domain and URI reputation. A message can pass DMARC and still contain a listed link. Fix the listed URL or abuse source and use SURBL's removal process; investigate authentication failures separately.
