Getting one IP address off a blocklist: the removal portals one by one, who is allowed to file, and the ticket you send your provider

Before you file anything

Stop or fix the cause first, then prove to yourself that the address is quiet. Quiet means your own outbound logs, not the absence of new bounces: mail, but also the probes and the forwarding that some lists count against an address, which the whole range post spells out for UCEPROTECT. Spamhaus's own first instruction is the same one: check your mail server logs before taking any action, and if there are no bounces, there is no problem. Then read the rejection for what it actually names. A rejection from a list names the list, and usually the zone or the level; a rejection from a mailbox provider names the provider's own code, which may or may not point at a third party list behind it. Reading a bounce is the post for the codes; the map below is only the part that says where the removal is handled. Before any form, look the address up at that list's own checker, because a form submitted for an address that is no longer listed, or submitted while the source still runs, is the premature request every portal warns about; that a request is not a guarantee, and that no operator publishes a success rate, is the finding in proving a range changed hands.

Two checker habits save a day each. The checkers are for people, not scripts: Spamhaus says no automated lookups and answers perceived automation with a 403, and UCEPROTECT says only manual queries are allowed and locks out addresses that abuse its page. And a checker that pre-fills the visitor's own address, as UCEPROTECT's does, will happily test the laptop you are sitting at rather than the mail server; clear the box and type the address from the bounce.

Which rejection points at which portal

From what the receiver said to where a removal is handled, each row from the list's or the receiver's own page as read on 6 September 2026. Gmail is on the list because people look for a Gmail delisting form: its published rejections speak only of the reputation of the sending address or its rate and name no third party list; there is no delisting portal behind them, and the routes Google publishes are its sender contact form for mitigation requests and the Report delivery issue option in Postmaster Tools, the first open to any sender following the sender guidelines and the second only to a verified domain owner who meets them.

Two rows need a footnote. Barracuda's own pages that would carry its rejection text would not open on the day, so that row rests on the removal form alone; and Talos publishes no bounce string of its own because the receiver writes the rejection and, as Talos puts it, the reputation center does not block email or Internet traffic. For any Spamhaus rejection, a rejection quoting the zen zone may carry more than one code, one per dataset that lists the address, so read all of them: an address on CSS and XBL at once is two rows here and, Spamhaus said at the checker's launch in 2021, one removal request. The 127.255.255.x answers are lookup errors, not listings.

The portals one by one, for one address

Spamhaus. Everything runs through the IP and Domain Reputation Checker at check.spamhaus.org, which the XBL and CSS pages name as the only place their removals are handled, and whose general FAQ says removal requests made through other channels such as email cannot be handled; the SBL is the exception, since its own FAQ routes the ISP's request through the mailto link on the listing page, so for the SBL the email is the channel and for CSS, XBL and PBL it is not handled. For an SBL listing the checker shows the listing, by address, range or ticket number, and sends an end user to their provider: the request itself goes from the mailto link at the bottom of the SBL listing page, from the ISP in charge, and must say how the problem was solved. For CSS and XBL the checker is the only place removals are handled; a CSS removal is preceded by a troubleshooting step that shows the HELO values recently seen from the address and the results of PTR and HELO resolution, and Spamhaus says a red cross on any of those checks means a removal request is likely to be unsuccessful. XBL cannot be nominated by anyone and lists only what connected to Spamhaus's own detectors, so a removal that is followed by a relisting means the box connected again. For PBL the single IP exclusion, not the ISP account form, is the route for anything smaller than a /24, and Spamhaus lists the conditions: the address is static, it is an outbound mail server, it has what Spamhaus calls appropriate forward and reverse DNS, and it is assigned to the party performing the removal. A removal made from a free mail domain is invalidated by the PBL removal system's security checks; an address whose domain matches the mail server is accepted. At the checker's launch in 2021 Spamhaus said that where it could not process a removal immediately it would raise a ticket with its delisting team. The clocks and the escalation rules behind these zones are in the whole range post and are not repeated here.

SpamCop. There is no removal request: SpamCop's FAQ answers the question with you cannot be removed, says the SCBL is time based and delists automatically when reports stop, and asks administrators not to write in to say the problem is fixed and ask for early delisting. A listed address stays on the SCBL for 24 hours after the last report, a listing with only two reports for at most 12 hours after the most recent reported mail, and reports older than a week are ignored, so the only thing that ends a SpamCop listing is the reports stopping. It says it may not respond if the writer is not the admin of the listed address. What it will review is an error: a technical error on its side, or a user error where somebody reported mail that was not spam, for which it wants the record of the recipient's closed loop confirmation. That review starts at the checker at spamcop.net/bl.shtml, from a role address such as postmaster or abuse, with the writer's relationship to the address stated, and SpamCop asks for up to a day for a response on its dispute resolution page. The checker shows a time to delisting; SpamCop says a zero means the delisting has begun and that it can take up to four hours to reach its mirrors. SpamCop does not list for missing or wrong reverse DNS, does not want whois records, traceroutes or logs, and says a legal threat sends the mail to its legal department and delays whatever it would otherwise have done.

Barracuda. The removal request page asks, in its own prose, for the mail server's address, an email address, a phone number and an optional reason; the form beneath it also carries Barracuda Customer Name and Barracuda Customer Email Address fields, and the page does not say what a non customer enters. Barracuda says the list is generated by automated systems, that requests without valid information are ignored, that multiple requests are also ignored, and that requests are typically investigated and processed within 12 hours of submission if provided with a valid explanation. Its reasons page lists a dynamic address previously used by a known spammer among the causes of a poor rating, which is the inherited case. Nothing on the readable pages states a reverse DNS or clean address condition, so do not assume one; the pages that might have said more would not open on the day.

Microsoft, for a Microsoft 365 recipient. The rejection in the 5.7.606 to 5.7.649 range names the Office 365 Anti-Spam IP Delist Portal at sender.office.com. The form takes an email address, the address to delist and a characters you see challenge; a confirmation message goes to the email address, its link returns you to the portal, and you then select Delist IP. Microsoft says to use the email address that received the NDR and the address named in the error, one of each per visit, and that results can vary widely and might take up to 24 hours or longer, and adds the relisting caveat in its own words: verify that messages are not abusive or malicious, otherwise the address might be blocked again. A 5.7.511 rejection cannot use the portal; that route is an email to [email protected] with the full NDR code and the address, and Microsoft says it will contact you within 48 hours. Two lookalikes are not Microsoft's list at all: 5.7.513 is the recipient tenant's own custom block list and 5.7.507 is the recipient organisation blocking the address, and both are resolved with the recipient. A 4.7.500 to 4.7.699 response is a temporary restriction for further evaluation; Microsoft says that if the activity is valid the restriction is lifted shortly, so there is nothing to file for it. If the rejections continue after the source is fixed, read the next code, because a later 5.7.606 to 5.7.649 is the portal's case.

Microsoft, for an Outlook.com recipient. The consumer service is a separate system with its own codes on the Outlook.com postmaster site: SC-004 is a block placed because of complaints about mail from the address, and the string recommends enrolling in the Junk Email Reporting Program; OU-001 and DY-001 send the sender to Spamhaus for the removal, so those two are a Spamhaus row in disguise; SC-001 and OU-002 cite content or reputation, carry no Spamhaus pointer, and have no route of their own beyond the same support form below; their strings send a non admin to the provider. The support form for a listed address sits behind the postmaster site's Support link and a Microsoft sign in, is limited to the consumer domains, and comes with Microsoft's own statement that submission guarantees nothing; no timing is published for it. The two tools worth knowing are not delisting tools. SNDS shows the health of your address space as Outlook.com sees it, including a Blocked status with its reason on its View IP Status page, which is current as of the last 24 hours with no history, while the daily data view keeps 90 days; access is automatic and keyed to the published contacts, postmaster or abuse at the reverse DNS domain or any email address in the RDAP allocation record, and Microsoft says it cannot process manual access requests. JMRP is the free feedback loop, enrolled through SNDS, that returns junked messages with headers; Microsoft says feedback typically starts within as little as 72 hours. Microsoft publishes no paid route on either service.

Proofpoint. The Dynamic Reputation IP Lookup at proofpoint.com/us/ipcheck takes one address and a reCAPTCHA and, in Proofpoint's words, provides a means to submit information about your address if it is on the blocklist or experiencing sending delays. Proofpoint asks for the recipient of the blocked mail and the type of mail, and to mention any recent problem on the network such as an infected machine just removed; it strives to review submitted reports within one business day; delays clear automatically, usually within a few minutes, and a block lifts once the address stops sending spam for a period of time, while an address that continuously sends spam remains blocked. Proofpoint customers have an expedited route through their support community.

Talos. The reputation center shows the verdict; a Sender IP Reputation Support Ticket, which requires a Cisco CCO login or the free guest account Talos offers, is the dispute. Talos says those tickets are for disputing individual addresses wrongly flagged as malicious, for an address or domain you own, that disputes are processed by automation first and then reviewed by people, that submitting multiple disputes for the same entry will not influence or expedite the outcome, that customers should receive an initial response within 24 hours, and that a score should improve on its own after a fix, with a ticket the step Talos names if it has not within the days its sender reputation page gives. The contact form on the reputation center page is for incident response and explicitly refuses reputation requests. The recovery window after a fix, and Talos's statement that it cannot be hurried, are in the whole range post.

UCEPROTECT Level 1. The removal page says there is no need to request removal if you do not want to pay: an address temporarily listed at Level 1 expires on the clock given in the whole range post, and the page says nothing about what happens to a manual listing. The paid alternative is an optional immediate removal priced per address, the fee shown on the removal page as an image rather than text, payable by Stripe, carried out manually once payment is confirmed; the page tells a service provider that an address may be relisted if new abuse becomes known, and that provider is told to grep the last seven days of its logs for undeliverable outgoing mail at the time the database displays, after the removal policy page's instruction to query the database before doing anything else. The page also warns that a legal threat will be published. The Level 2 arithmetic is under the same ladder, and the paid options above Level 1 are under who owns the fix there.

Who is entitled to file: the holder, the announcing network, or the mailer

The question nobody writes down for a leased or reassigned address. Read across the operators' own words, there are four answers. Spamhaus's general rule is that removal requests must be made by the registered owner of the domain or IP address, from a source address that can be associated with the listed one, and it says they should not be made through a VPN or proxy or from a free or disposable mailbox; its SBL page narrows that to the Internet Service Provider in charge of the listed address; for PBL the condition is that the address is assigned to the party performing the removal. SpamCop will hear from the admin of the listed IP and tells an end user on a provider's server that the provider must solve the problem and contact SpamCop if it needs help. Talos wants an address or domain you own. Microsoft's portal asks for the mailbox that received the NDR and the address in the error, states no ownership check, and its SNDS authorises only the addresses its own algorithm derives from the reverse DNS domain, the RDAP record and, where one ASN covers the range, that ASN, and Microsoft says it cannot process manual requests. Barracuda and Proofpoint publish no rule. And Outlook.com's rejection strings tell anyone who is not an email or network admin to contact their provider.

What that means for the three usual shapes. If you run the mailer on your own assignment with your own registry record, you are the holder and the ISP in charge at once, and every door is yours to knock on. If you are a customer on a provider's space, which is the shared address case reading a bounce sorts into the address branch, or a lessee of leased space whose registration still carries the lessor's name, the holder-only doors are shared, and Spamhaus's two wordings do not settle a lease: its SBL FAQ names the ISP in charge of the address, which the whole range post reads as whoever operates it whether or not the record carries their contact, and its general FAQ names the registered owner, so a lessee files first from an address Spamhaus can associate with the listed one and, if refused, asks the lessor to file; a customer on shared space has no such claim and SBL removal goes through the provider or the lessor, SNDS access goes to whoever reads the record's abuse mailbox unless they delegate it to you by forwarding the authorisation, and a PBL exclusion is yours only if the address is assigned to you and the ISP's PBL policy allows end user removals, which the ISP may also have set to expire sooner than a year. The published abuse contact on the record is the party those doors expect and where the list's notice most likely landed, which the whole range post reads off the report, and running an abuse desk is where that inheritance is explained. Under a lease, what the lessee should ask the lessor to do is what the lease should already say, and leasing space out safely has the clause. Under a reassignment, the way to become a party a portal will correspond with is a record of your own, and SWIP and reassignment records is how a customer gets one. The doors that ask for no record, Microsoft's portal and Proofpoint's form, are open to the party with the bounce and the fixed box. CSS and XBL are self service at the checker, but Spamhaus's general rule still applies to them: the request comes from the party authoritative for the address, from a source Spamhaus can associate with the listed one, so on a provider's space the customer whose box is the listed address files first, from that address, since Spamhaus's XBL FAQ addresses the user of the listed IP and publishes no ownership check for it, and if the request is refused, the record holder is the one to file.

The ticket you send your provider, and what a good desk does with it

When the door is the provider's, the ticket has to carry everything the portal will ask them, because Spamhaus lists what it wants in any removal request, what caused the spam issue, what action you took to solve it, when you solved it, and what further actions you took to prevent it happening again, and its SBL page adds that it always needs to know how the problem was solved. So the ticket carries the address, the rejection text verbatim with its date and time zone, the list and the zone or code it names, the cause you found and the date and time you fixed it, what your outbound logs show since, what the list's own checker showed and on which date, and exactly which door you are asking the provider to knock on. For a listing that predates your use of the address, the dated sentence from the warm up post and the exhibit that proves it, from proving a range changed hands, go in as attachments rather than argument.

Subject: delisting request, 203.0.113.25, Spamhaus SBL, please file as ISP in charge

Address:        203.0.113.25 (our assignment 203.0.113.0/26 under your allocation)
Rejection:      550 [verbatim text of the bounce], received [date and time, UTC]
List and zone:  Spamhaus SBL (return code 127.0.0.2, listing SBL000000 per the checker)
Cause:          compromised web app on this host relaying mail; found [date and time, UTC]
Fix:            host suspended [time, UTC], app removed, credentials rotated, outbound mail
                restricted to the relay; reinstated [date and time, UTC]
Since the fix:  outbound logs show no mail and no relay connections from this host
Checker:        check.spamhaus.org on 2026-09-06 [time, UTC] still lists the address on SBL
Asking:         please submit the SBL removal from the listing page as the ISP in charge,
                and tell us the ticket number so nobody else files

On the desk side, the rules are the ones the portals impose in reverse. Verify that the address is quiet from your own logs before filing, since a request for a source that is still running is the relisting Spamhaus, Microsoft and UCEPROTECT all describe. One filer and one thread per list, and tell the customer who filed, where and when, so nobody double submits into a portal that ignores multiple requests. Answer from a mailbox that works and check its spam folder, which is Spamhaus's own advice to people who are waiting for a reply that never seems to arrive. Close the ticket with the date the list's own checker cleared, not the date you filed. The desk's own process, and where its published contact comes from, is running an abuse desk; a provider whose abuse mailbox is dead is the case in how to report abuse, and it is the reason a listing arrived without any notice reaching you.

Resubmitting, paying, and removal services

Each operator states its own version of the same trap. Spamhaus: a request for an unfixed source gets relisted, XBL relists the next time the box connects, and after an XBL removal Spamhaus asks for 24 hours before opening a new ticket because networks sync at different speeds; after any removal it says to wait one to two hours and, in rare cases where one network has sync problems, hours or days, and to update the removal ticket only if all networks still block. PBL exclusions are reversed at once if spam is detected and individuals who remove many addresses may find their access revoked and their removals reversed. SpamCop: do not write to ask for early delisting. Barracuda: multiple requests are ignored. Microsoft: one address per visit, and a delisted address that sends abusive mail is blocked again. Talos: multiple disputes for the same entry do not influence or expedite the review. UCEPROTECT: the relisting caveat on the paid removal is on the terms above. The relisting reading for CSS, a removal followed by a relisting being the list telling you the source is still active, is in the whole range post.

Paying. Only UCEPROTECT sells a single address removal among the portals here, on the terms above; Spamhaus says there is never any charge or fee for removing any Spamhaus listing, that it has no affiliation with anyone offering a blocklist removal service, and that no third party can influence or expedite removals from any Spamhaus database; Microsoft, SpamCop, Barracuda, Proofpoint and Talos publish no paid route. The caution on paying for an express removal, and the case of a list that has shut down, are both in how addresses come off, and the paid options above Level 1 are in the whole range post. Removal services, the kind that offer to get you off every list for a fee, are not named here and need not be: none of the portals above publishes a route for a third party that it does not publish for you, Spamhaus says it has no affiliation with anyone offering a blocklist removal service and that no third party can influence or expedite removals from any Spamhaus database, and its own rule is that the request comes from the registered owner, from a source address that can be associated with the listed one. The only expedited routes published are Proofpoint's and Talos's, for their own customers. For a range you have just acquired, the warm up post has the delisting step in its place.

What a subnethistory lookup shows for that address, and what it cannot

Look the address up and the report shows what the reputation feeds it reads say about it, which is a different thing from what the list says. On the address card a chip reads on N blocklists when a feed reports a count or names any list, and beneath it a red Blocklisted on line names every list a feed reported for the address, unioned across feeds; when two or more names are present a finding also names up to three of them. The names are the report's short labels for the sources the feed consulted, and none of them is a portal on the map above: the feeds carry aggregate and abuse sources rather than the mail zones, and the one Spamhaus name they can carry refers to the DROP range list, which Spamhaus describes as a subset of the SBL that leaves DROP when the SBL record is removed, so that name sends you to the SBL rung of the whole range post rather than to a single address portal. Below the card, the collapsed Per-source detail section lists each feed's reading with Source, Verdict, Risk, Blocklists and Checked columns; the Blocklists cell prints the count, none for a feed that answered zero, and n/a for a feed that had no blocklist verdict at all, which is not zero; the Checked cell prints the date of the feed's last reading and how many readings stand behind it. The Registration panel shows the Organisation, the Type as the registry wrote it, and the published abuse contact, and the collapsed Enclosing blocks table names the blocks above with their Type and Country, so you know which record to look up next; it does not settle who files, which is the reading in the whole range post.

After the delisting, look it up again, and read what the second read can carry. It adds a dated point for that day only. If a feed's blocklisted verdict flipped between the two reads, the flip appears under Verdict changes we have recorded, dated to the read that saw the new value and not to the list's removal; a count falling from four lists to three is not a flip and shows only in your own comparison of the two reads, which monitoring your own ranges covers field by field. A removal at the portal reaches this report only when the feed is next read and has itself caught up, on the archive semantics in monitoring your own ranges; the portal's own checker is the only proof that the listing is gone, and a feed can lag it in either direction.

What the report cannot do, stated in the same breath. It does not query any list's own zone, so it cannot say which Spamhaus zone or which UCEPROTECT level carries the address, or confirm that a removal went through. It holds no listing reason, no listing date and no removal date. The general limits, no monitoring, no alerts, no re-read on demand, an abuse contact shown without saying whether it is the block's own or a parent's, and no registry children, are in monitoring your own ranges. Two limits are specific to a delisting: the report submits nothing on anyone's behalf, and it cannot say who inside a provider's allocation runs the mailer. A clean read here means no feed the site reads reported a listing on the day; it does not mean the address is off any list, and the customer who asks for that proof should be sent the screenshot of the list's own checker, dated.