Sender Score Blocklist: The RPBL and How to Get Delisted

A bounce string names Sender Score, the checker shows a red row against something called the Reputation Network, and the first search returns pages about a number between 0 and 100. The number is not the problem. Validity publishes two different things under the Sender Score name, and only one of them can block a message: the Return Path Blocklist, an IP list that receivers query, which the operator abbreviates RPBL. The score is a rating. The blocklist is a yes or no.

Getting that distinction right is most of the work, because the remedy for a low score is months of sending discipline and the remedy for a listing is a form the operator publishes and processes on request. This page is about the second object: what the Return Path Blocklist lists, what puts an address on it, how the removal request works and what to change so it does not recur. It follows the same shape as the SURBL page, which sits at the other end of the spectrum, keyed on domains inside a message rather than the address that sent it.

Two objects, one name

The operator's own pages draw the line. The Sender Score lookup page, as rendered on 18 September 2026, defines the score as a rating of an address: "Each Sender Score is a number between 0 and 100 that identifies the quality of your sender reputation and details how mailbox providers view your IP address." The same page lists what feeds it, and one of the inputs is named plainly as Blocklists, alongside Complaints, Infrastructure, Sender Rejected, Messages Filtered, Spam Traps, MBP Spam Rate, Unknown Users and Fluctuations in Send Volume. The bands it prints are Poor at 0 to 70, Fair at 70 to 80 and Good at 80 and above.

The blocklist lookup page, also rendered on 18 September 2026, defines the other object: "The RPBL Blocklist identifies spam-like sending practices and classifies emails based on specific criteria." It goes on: "These calculations are centered around sender behavior and content such as threatening attachments, spam trap hits, and authentication failures. An IP is listed when our system detects messages containing these indicators from that IP."

So a blocklist listing is one input to the score, and the score is not an input to the blocklist. A sender can hold a Good score and still be listed after one bad day, and a sender with a Poor score can be absent from the list. A score is not a listing and there is nothing to file against it; reading one as a proxy for the other is the mistake that sends people to the wrong remedy. The general version of that confusion, a private rating mistaken for a published list, is the subject of sender reputation, which describes the Sender Score family as a real measurement of one component among several.

What the list keys on

Every criterion the operator publishes is about the sending IP address, never the domain in the copy and never the score. The Blocklist Remover page, rendered on 18 September 2026, gives the causes in a list under the heading asking why an address is blocklisted: "When IPs are blocklisted, they usually engage in high-risk sending behavior, such as:" followed by four items, each a full sentence on the page: "Sending to email addresses that never subscribed to receive communications", "Sending email campaigns from botnets", "Sending messages containing suspicious attachments" and "Email authentication failures". The page adds a line about where those behaviours tend to come from: "Often these high-risk sending behaviors include security issues such as bad data partners or viruses sending mail through your network."

Three of the four are the ordinary failure modes of an outbound programme rather than of a criminal one. An unverified list produces the first (addresses that never subscribed, some of which are traps). A misconfigured sending domain produces the fourth. Attachments in a first-touch email produce the third. Only the botnet case is about a compromised machine, and even that one is a hosting-provider conversation more often than a sender's own fault.

What put the address on the list

• ~Depends: Mail went to addresses that never subscribed, which is where spam traps sit
• ~Depends: Mail failed authentication: SPF, DKIM or alignment between the two From values
• ~Depends: Messages carried attachments the receiver treated as suspicious
• ~Depends: Mail left through a botnet, a compromised machine or a shared server another customer abused

Who consults it, and how much weight to give the row

A listing matters in proportion to how many receivers query the list and what they do with the answer, and neither figure appears on the operator's lookup or remover pages as rendered on 18 September 2026. A receiver that does consult it has published how. Sinch Mailgun's help centre article on the list, titled SenderScore Return Path RBL and last updated on 18 May 2026 according to its own metadata, says: "Listings are done on an IP level, and overall have a low impact on message delivery. The list is offered to anyone free of charge, and each provider chooses for themselves if/how they implement the list." That is one receiver's assessment of its own use, quoted as such.

The operator's lookup page makes a related point from the other side: "The RPBL is just one of hundreds of blocklists, and they are not all created equal." It then says a listing here is usually a symptom of something wider, and that reading is the useful one. The row itself may cost few deliveries. The behaviour that produced it will be visible to every other list and every mailbox provider that watches the same signals, which is why the fix below is about the programme and not about the form.

The order in which to work a report that shows this row beside others, weighted by what each list costs, is in email blacklist check and recovery. This one belongs in the middle of that order: worth clearing, never the reason a Gmail inbox went quiet.

The removal procedure, step by step

The operator publishes a single self-service path and it is the same form behind two addresses. On 18 September 2026 both senderscore.org/act/blocklist-remover/ and senderscore.org/rtbl/ rendered the page titled Blocklist Remover, and the lookup page at senderscore.org/assess/blocklist-lookup/ carries the same request form under its listed result. Both pages refused a plain scripted fetch and rendered in a browser, so anyone checking from a script should expect the same.

1. Look the address up first. The lookup page takes an IP address or a domain and returns one of two verdicts, printed on the page as "The IP address is not currently listed on the Return Path Blocklist." or "The IP address is on the Return Path Blocklist." A note under the tool limits what it can tell you: "This free tool only checks for active listings on the Return Path Blocklist (RPBL). If your IP address was previously listed on the RPBL but has since been removed, you will not see information related to that listing." A checker's red row from last week may already be stale; the operator's own page is the current answer.

2. Establish whose address it is. Mail that leaves through Google Workspace, Microsoft 365 or a sending platform connects from an address the provider owns. A listing against that address is the provider's to clear, and the request should go to them. The test for which address a rejection is actually about, and why it is the one quoted inside the bounce rather than the one a browser reports, is in whose IP a blocklist lookup is checking.

3. Fix the cause before asking. The remover page frames the request as conditional in its own heading: "Improved your sending behavior? Ask to be removed from the Return Path Blocklist." Mailgun's article states the consequence of skipping this step: "Relisting can occur if the root problem has not been sufficiently addressed."

4. Submit the form. The listed result exposes a button labelled Request to be removed, and the form behind it asks for the address plus a first name, a last name, a company name, a work email, an estimated annual email volume chosen from bands that start at not sending mass email and run to over 120 million, a country, and consent to the privacy policy. There is no evidence upload and no free-text case to argue.

5. Read the reason that comes back. According to Mailgun's article, "After submitting the request, Return Path will share the reason for the listing with you so that you may address the issue if you have not done so already." That reason is the most valuable thing the process produces, because it names which of the four causes fired.

1

Look the address up

The lookup page returns listed or not currently listed. It shows active listings only.

2

Confirm the address is yours

A provider-owned address is the provider's request to file, not yours.

3

Fix the cause

The remover page asks whether sending behavior has improved before offering the form.

4

Submit the Blocklist Remover form

Address, name, company, work email, annual volume band, country. No evidence upload.

5

Read the reason returned

The operator shares the listing reason after the request; it names which cause fired.

What to change so it does not recur

The listing reason maps onto a specific change, and Mailgun's article lays the mapping out for its own customers in four cases that transfer to anyone. For attachments, review what has been sent and whether the content or the attachment type needs to change. For authentication failures, review the sending domains' DNS records for SPF and DKIM and, in the article's words, "review your traffic to ensure alignment between the Envelope From and Header From values." For spam traps, list hygiene. For botnet behaviour, the infrastructure provider.

For a cold outbound programme, two of those four are where the risk sits, and both are decided before a campaign sends rather than after a listing.

The first is the list. Addresses that never subscribed is the operator's first-named cause, and inside that population sit the traps that produce the spam trap hits its lookup page names. Verification before every send, one contact per company and no purchased or appended data are the whole of the defence; the mechanics of what a trap is and how one gets into a bought list are in spam trap.

The second is authentication. A sending domain with SPF, DKIM and DMARC published and aligned removes the fourth cause entirely, and the same records are read by mailbox providers whether or not the Return Path Blocklist ever sees the mail. The setup, in the order that avoids the alignment mistake, is in SPF, DKIM and DMARC for cold email.

Attachments are a copy decision. A first message to a stranger has no business carrying a file, and a programme that never attaches anything has closed the third cause at no cost. The botnet case is a hosting question: scan the machine, and if the address is a shared server another customer abused it will list again whatever a single sender does, so the answer is dedicated infrastructure or a different provider. Each of the four has an owner, and the table below names them.

Listing reason	What changes	Owner
Addresses that never subscribed, spam trap hits	Verify before every send; no purchased or appended lists	List owner
Authentication failures	SPF and DKIM published; Envelope From and Header From aligned	Domain owner
Suspicious attachments	Send no attachments in a first touch	Copy owner
Botnet behaviour	Scan the machine; move off a shared address another customer abused	Infrastructure provider

Where the score comes back in

Once the address is clear, the score is worth a look for a different reason. Its inputs, as the operator lists them, are the same signals a mailbox provider watches: complaints, unknown users, trap hits, rejected and filtered mail, volume swings. A programme that keeps those flat keeps itself off this list and off the others that watch the same signals, and the score is a free, if coarse, readout of whether it is doing so. What it cannot do is tell you why a specific message bounced. For that, the digits a receiver returns and the text after them are the evidence, and a rejection that names the Return Path Blocklist is answered by the procedure above, not by anything that moves the score.

Our own sending posture makes the whole question smaller. Outbound runs on dedicated sending domains that are separate from the corporate domain, every list is verified before a campaign sends, authentication is published and aligned before the first message, and each campaign carries one message and never a second in the same thread, so a non-responding audience is never mailed again on the same premise. Those are policies, not results, and they are the policies that keep the four causes above from firing.

The short version

Validity publishes a score and a blocklist under the Sender Score name. The score is a number between 0 and 100 with blocklists among its inputs; the blocklist is the Return Path Blocklist (RPBL), an IP list whose published causes are mail to addresses that never subscribed, botnet sending, suspicious attachments and authentication failures.

Removal is self-service. Look the address up on the operator's lookup page, confirm the address is yours rather than a provider's, fix the cause, submit the Blocklist Remover form, and read the reason the operator returns. Mailgun, one receiver that publishes how it uses the list, rates the delivery impact of a listing as low and warns that relisting follows an unfixed cause.

What prevents a repeat is decided before a campaign sends: a verified list, aligned authentication, no attachments in a first touch, and an address nobody else can abuse. If you would rather run on infrastructure where those four are set up before anything goes out, we plan the first campaign for free.

The definitions, listing causes, form fields and verdict strings above are taken from senderscore.org's blocklist lookup, Blocklist Remover and Sender Score pages as rendered in a headless browser on 18 September 2026 (the pages refuse plain scripted fetches), and from Sinch Mailgun's help centre article SenderScore Return Path RBL, whose metadata dates its last update to 18 May 2026, read the same day. Verify current list behaviour with the operator before relying on it.