Home › Guides

Email Blacklisted? How to Read the Bounce and Get Off a Blacklist

Published 2026-11-03 ／ Updated 2026-11-03 ／ By Yuki Nakazawa

If your email is blacklisted, the bounce message usually tells you so. Open the rejection you got back and look at three things: the three-digit code, the dotted code after it (such as 5.7.1), and the text. A code starting with 4 is a temporary failure; a code starting with 5 is permanent. If the text names a blocklist, that list is the one to deal with first.

Before chasing blacklists, rule out the simple causes in order: a typo in the address, a full mailbox, a problem on the recipient's side, and missing SPF, DKIM or DMARC. Getting off a blacklist works the same way almost everywhere: find and stop the cause, submit one removal request if the list requires it, then wait. Nobody can promise a delisting, and repeated requests without a fix tend to make things worse.

Facts about specific lists and mailbox providers below are taken from their official pages as of November 2026. Policies change, so confirm details on the operator's own site before acting.

How to read the bounce message

A bounce (non-delivery report) quotes the reply the receiving server gave. A typical blacklist rejection looks like this:

<user@example.com>: host mx.example.com[203.0.113.25] said:
    550 5.7.1 Service unavailable; Client host [203.0.113.10]
    blocked using bl.example.org (in reply to RCPT TO command)

1. The reply code (550). Under RFC 5321, a 4yz reply means the error is temporary and the same request may be tried again. A 5yz reply is a permanent failure, and the sending server should not simply repeat the same request.
2. The enhanced status code (5.7.1). Defined in RFC 3463 as class.subject.detail. The middle number tells you the area: 1 is the address, 2 the mailbox, 4 network and routing, 7 security or policy. A 5.7.x code means the receiver refused you on policy grounds, which is where blocklists and reputation show up.
3. The free text. Receivers often name the list (blocked using bl.example.org) or give a lookup URL. Copy the whole bounce; you will need it for any removal request or support ticket.

Common codes and what they point to. The 5.7.25, 5.7.26 and 4.7.x descriptions come from Gmail's published error list; other providers may word or use the same codes differently.

With a 4xx error your server keeps retrying on its own. RFC 5321 recommends waiting at least 30 minutes between attempts and says the give-up time generally needs to be at least 4 to 5 days, which is why you may get a "delayed" warning long before a final failure.

Check the causes in this order

Work from the cheapest and most common causes toward the rarer ones. The early checks take seconds, so do them before anything else.

1. Address typo. A 5.1.1 has nothing to do with blacklists. Fix the address.
2. Full mailbox. 4.2.2 or 5.2.2 is the recipient's problem. Reach them another way.
3. Only one recipient fails. If mail to other companies and to Gmail gets through, the recipient's own filters are the likely cause. Send their administrator the full bounce text.
4. SPF, DKIM and DMARC. Gmail requires every sender to set up SPF or DKIM, and senders of more than 5,000 messages a day to set up SPF, DKIM and DMARC. Yahoo's requirements are similar, with bulk senders needing a DMARC policy of at least p=none. Outlook.com began enforcing the same requirements on domains sending over 5,000 messages a day on May 5, 2025. See the SPF, DKIM and DMARC setup guide.
5. Sending IP and domain reputation. Check that the sending IP has valid forward and reverse DNS (PTR), that you send over TLS, and that complaints are low. Gmail and Yahoo both ask senders to keep the spam rate below 0.3%; Gmail recommends staying at or under 0.10%.
6. Blacklist check. If a bounce names a list, or several unrelated recipients return 5.7.1, look up your sending IP and domain with a blacklist checker.
7. Content and volume. Look for anything that changed: a sudden large send, an old list mailed in one go, a web form being abused to send mail to strangers.

If only Gmail rejects you, the Gmail delivery troubleshooting guide goes deeper into its specific codes.

What an email blacklist (DNSBL) is and how to check it

Most email blacklists are DNSBLs: lists published through DNS. When your server connects, the receiving server looks up your IP in the lists it trusts and then rejects, scores or tags the message based on the answer.

RFC 5782 describes the lookup. For IPv4, the octets are reversed and prepended to the list's domain. A listed address returns an A record, conventionally 127.0.0.2, and may have a TXT record explaining why. An address that is not listed has no records at all. IPv6 uses a nibble-reversed form of the full address.

$ dig +short 10.113.0.203.bl.example.org A
127.0.0.2
$ dig +short 10.113.0.203.bl.example.org TXT
"Listed - see https://bl.example.org/lookup"

A few points that trip people up:

• Check the IP of the server that sends your mail, not your laptop or office connection. Find it in the bounce (Client host [...]) or in the Received headers of a message you sent.
• Domains can be listed too. Some lists cover sending domains or domains that appear in links. Check both the IP and the domain.
• A listing only matters where it is used. Each receiver decides which lists to consult. Being on a list that your recipients do not use changes nothing for them.

Querying dozens of lists by hand is tedious; a blacklist checker does it in one pass and shows which lists return a hit.

Which listings actually matter

Not every listing deserves the same attention. A rough order of priority:

• The list named in your bounce. That is the one actually blocking you. Handle it first.
• Large, widely used lists. A listing here affects many receivers at once.
• One or two hits on small or obscure lists, with no bounce naming them, are usually not why your email is blocked. Look at authentication and reputation before spending time on them.

How some well-known lists describe themselves, based on their official pages as of November 2026:

Two things to keep in mind. First, lists that cover whole ranges, like UCEPROTECT Levels 2 and 3, can include your IP even if you never sent spam, because of other addresses on the same network. Second, where a list offers paid express removal, a free automatic expiry usually exists alongside it, and paying does not fix whatever caused the listing. If the cause remains, the listing comes back. Spamhaus has several lists with different removal paths; see how to get off Spamhaus.

How to get off a blacklist

The process is much the same for every list:

1. Find and stop the cause. Typical culprits are a compromised mailbox password, a malware-infected machine, a contact form that sends to any address entered, an open relay, or mailing people who never opted in. Change passwords and close the hole before anything else.
2. Read the operator's lookup page. Most lists let you enter an IP and see why it is listed and what the removal path is. Follow that, not a third-party guess.
3. If the list expires entries on its own, wait. SpamCop drops a listing 24 hours after reports stop; UCEPROTECT Level 1 after 7 days without new spam.
4. If the list takes requests, send one. Say plainly what happened and what you changed. Barracuda, for example, states that duplicate requests are disregarded.
5. Resend and watch. Removal can take time to propagate. SpamCop notes it can take up to 4 hours to reach its mirrors and the servers that use the list.

Submitting the same request again and again, or asking for removal before the cause is fixed, is counter-productive. Even if it works, the listing returns as soon as the problem recurs, and the operator has the final say either way.

Also remember that a DNSBL is only one input. When Gmail rejects mail with a 550 5.7.1 citing the very low reputation of your sending IP or domain, that is Gmail's own assessment. Getting off a DNSBL will not change it; better authentication, cleaner lists and fewer complaints will.

Shared hosting and VPS: when the IP is not only yours

On shared hosting, many customers send through the same outbound IP. Someone else's compromised site can get that IP listed, and your mail is blocked along with theirs.

• Shared hosting. The host controls the IP, so open a support ticket with the full bounce and the listed IP rather than filing removal requests yourself. Range or network listings, such as UCEPROTECT Levels 2 and 3, can only be addressed by the provider.
• VPS or dedicated server. A freshly assigned IP may carry history from a previous tenant. Check it before you start sending, and set its reverse DNS (PTR) to match your mail server's hostname, usually through the provider's control panel.
• Sending directly from a home or dynamic IP. These ranges are what the Spamhaus PBL is for. Route mail through your provider's or mail service's submission server with authentication on port 587 or 465.

If you cannot control the IP and the provider cannot fix it, moving outbound mail to a different authenticated sending server is often the practical answer.

How to avoid being listed again

A delisting only lasts if the cause stays fixed. Keep these habits:

• Authentication and basics. Keep SPF, DKIM and DMARC valid, keep reverse DNS correct, and send over TLS. Update SPF whenever you add a new sending service.
• Account security. Use strong passwords and two-factor authentication, and watch for sudden jumps in outbound volume or queue size.
• Protect forms. Rate-limit contact and signup forms so they cannot be used to send mail to arbitrary addresses.
• List hygiene. Mail only people who asked for it and remove addresses that bounce. Gmail and Yahoo require bulk senders to support one-click unsubscribe.
• Avoid sudden spikes. A send far larger than usual can trigger rate limits and complaints.
• Check periodically. Looking up your sending IP and domain now and then lets you catch a listing before customers report missing mail.

FAQ

Official pages used

The facts in this article were checked against the official pages below at the time of publication. Policies and behavior change without notice, so check the official pages before relying on anything important.

• RFC 5321: Simple Mail Transfer Protocol
• RFC 3463: Enhanced Mail System Status Codes
• RFC 5782: DNS Blacklists and Whitelists
• Google Workspace: Gmail SMTP errors and codes
• Google: Email sender guidelines
• Yahoo Sender Hub: Best Practices
• Microsoft: Outlook.com Postmaster
• Spamhaus: Policy Blocklist (PBL)
• SpamCop FAQ: SpamCop Blocking List delisting
• SpamCop Blocking List
• Barracuda Central: Removal Request
• UCEPROTECT: Removal Policy Level 1
• UCEPROTECT: Removal Policy Level 2
• UCEPROTECT: Removal Policy Level 3

Related guides

All guides →