SpamAssassin RCVD_IN Rules and DNSBL Lookups in 2026

What Are SpamAssassin RCVD_IN Rules and Why Do They Matter?

You send a transactional email, and it vanishes into the void—no bounce, no error, just silence. You check your logs. The sender score is high. One line stands out: RCVD_IN_XBL 1.000. What does that mean? It’s not a typo. It’s SpamAssassin flagging your message based on a DNSBL lookup.

SpamAssassin RCVD_IN_ rules are automated checks that scan incoming mail against public DNS-based blocklists. They don’t examine content. They check if your sending IP or domain appears on a known list of compromised hosts or spam-sources. If yes, the message gets a reputation penalty—often enough to trigger filtering or delay.

Key takeaways

• SpamAssassin RCVD_IN_ rules evaluate inbound mail using real-time DNSBL lookups to assess sender reputation.
• High scores from RCVD_IN_XBL, RCVD_IN_PBL, or similar rules can cause inboxes to treat your message as spam—even if it’s legitimate.
• Even a single hit on a DNSBL like XBL or PBL can reduce deliverability, especially if the record isn’t removed.

How RCVD_IN_XBL and RCVD_IN_PBL Work in Practice

SpamAssassin’s RCVD_IN_XBL and RCVD_IN_PBL rules check your email’s sending IP against two key Spamhaus databases: XBL lists known spam sources and malicious hosts, while PBL blocks IP addresses assigned to end users (like home broadband) that shouldn’t be sending mail directly. Each match adds a spam score—typically +1 to +3—increasing the chance your message gets flagged or rejected. If you're sending from a residential IP or one with a poor reputation, these checks can stop delivery before it even reaches the inbox.

RCVD_IN_XBL: Tracking Known Spam Sources

When an IP appears in Spamhaus’s XBL, it means that same IP has been seen sending spam, phishing messages, or hosting malware. SpamAssassin checks this in real time using DNSBL lookups. If your mail server’s IP is found in the XBL, the rule triggers—adding a penalty score to the message. This isn’t a guess; it’s based on observed behavior from a global network of sensors, including email servers that report malicious activity directly to Spamhaus.

Because XBL is actively maintained and updated, a high score here usually means your IP has already been flagged in multiple systems. You can check your IP’s XBL status using tools like MxToolbox or Spamhaus’s own lookup services.

RCVD_IN_PBL: Preventing Misused End-User IPs

SpamAssassin’s RCVD_IN_PBL rule stops emails from IPs that should never be sending mail directly—like home broadband, mobile networks, or DHCP-assigned addresses. These are known as "residential" or "dynamic" IPs. Even if your IP isn’t bad, if it's on the PBL, it’s being flagged for not being a legitimate mail server.

For example, if you're sending from a personal hotspot or a shared hosting environment without dedicated outbound mail channels, your outbound messages will likely be rejected by systems using PBL. The PBL doesn’t penalize IPs for being bad—it flags them for being in the wrong place. This includes many cloud instances that aren’t set up as SMTP gateways. The Spamhaus PBL documentation explains the criteria clearly.

Let's be clear: these aren't optional checks. They're part of standard email filtering at major providers. If you're seeing high bounce rates or low inbox placement, one of these two rules could be to blame. Before you send, verify that your sending IP is not listed in PBL or XBL. Use a real-time email checker like MailTester’s email checker to test individual addresses and validate your setup. For larger lists, run a bulk verification to catch mis-sent or invalid addresses early—especially if your infrastructure has changed. You don’t want your reputation damaged by a single misbehaving IP. The fix is simple: use a proper mail server or SMTP relay service.

Common Causes of RCVD_IN_XBL and RCVD_IN_PBL Hits

You’re getting RCVD_IN_XBL or RCVD_IN_PBL hits when your IP is listed on a DNSBL maintained by SpamAssassin, typically because it's associated with spam-like behavior. This often happens when sending from residential or dynamic IPs, using shared infrastructure with bad reputation, failing to enforce email authentication, or sending to outdated or non-responsive addresses. These triggers indicate a send reputation risk and can cause inbox placement issues.

Identifying the Root Causes

• Using a residential or dynamic IP address—common with unmanaged mail servers or compromised home devices. Such IPs are rarely whitelisted and frequently appear on blocklists like XBL and PBL.
• Reliance on a shared mail server with poor reputation. If other users on the same infrastructure send spam or trigger complaints, your IP can be penalized even if you're not responsible. This is especially risky on low-tier hosting platforms.
• Failing to implement SPF, DKIM, or DMARC properly. Inconsistent or misaligned authentication can create reputational leaks, especially on shared infrastructure where alignment is hard to maintain. This makes it harder for receiving servers to trust your messages.
• Sending to old, invalid, or low-quality email addresses. High bounce rates or spam complaints from list hygiene oversights trigger automated systems that flag IPs for review. SpamAssassin’s PBL specifically lists IPs that send to known invalid addresses.

Prevention and Verification

Before sending to a list, validate each address to catch invalid, disposable, or role-based addresses. You can test deliverability with an inbox placement tool to see how likely your message is to land in the inbox. These tools simulate real-world filtering and can reveal if your IP or domain is being blocked.

For proactive reputation management, use a real-time email verification API or bulk checker to screen lists before sending. Many modern blocklists, including those used by SpamAssassin, rely on behavior signals—like complaint rates and delivery reliability—that are detectable in pre-send validation.

Test your email deliverability in real inboxes with MailTester’s inbox placement tool. It checks whether your messages pass filters and land in the inbox—helping you catch RCVD_IN_XBL and RCVD_IN_PBL warnings before they impact your sends.

For deeper insights, review the technical standards behind DNSBLs: RFC 5782 outlines best practices for mail authentication and reputation systems, providing a foundation for understanding how SpamAssassin evaluates inbound mail.

Why DNSBL Lookups Can Fail Even When Your IP Isn’t Bad

Even if your IP address is clean and properly configured, it can still be blocked by DNSBLs like SpamAssassin’s XBL or PBL because they rely on reputation data, not just ownership. If other users on the same network send spam, the entire IP range may get listed—your email can fail just because someone else abused the network. Delays in delisting after cleanup, or outdated data, can cause false positives, especially in automated or poorly monitored systems.

Reputation Over Ownership: The Real Reason DNSBLs Flag IPs

SpamAssassin’s RCVD_IN_XBL and RCVD_IN_PBL rules don’t check whether you own the IP—they check whether the IP has a history of abuse. This means a residential or shared IP might be blacklisted not because you sent spam, but because a neighbor did. Many ISPs host hundreds of users on a single IP pool, and one bad actor can bring down the entire range.

These lists are maintained by community-driven efforts like Spamhaus (Spamhaus), which collect abuse reports and correlate them to network ranges. An IP might remain listed long after the abuse stopped, especially if the reporting system doesn’t automatically update delisting status.

Why Delisting Delays Happen and What You Can Do

Some DNSBLs use automated processes for delisting, but they may require a waiting period—sometimes days or weeks—even after the underlying issue is resolved. This creates a window where legitimate email fails, particularly for senders who don’t monitor their delivery status in real time.

Even if you’re not doing anything wrong, your messages may land in spam folders or bounce outright when a receiver’s server checks the XBL or PBL. This is especially likely in transactional or time-sensitive campaigns where even one failure can hurt deliverability.

Let’s be clear: you can't control whether SpamAssassin or a third-party DNSBL flags an IP. But you can prevent false positives caused by unverified data. Use real-time delivery checks before sending. For example, test your email streams with inbox placement testing to see how your messages land across major providers—before the campaign goes live.

How to Verify an Email Address Before It Triggers SpamAssassin Rules

You can prevent emails from triggering SpamAssassin's RCVD_IN_ rules by validating addresses before sending—checking for known bad IPs, domains on DNSBLs, and mailbox validity. Tools like MailTester’s bulk verification and real-time API test each address against SMTP, DNSBL status, and mailbox existence in under a second, stopping invalid or blacklisted addresses before they reach your inbox or trigger spam filters.

Check Your Entire List Before Sending

Let’s say you’re about to send a campaign to 10,000 addresses. One bad domain on a DNSBL could get your whole list flagged. MailTester’s bulk verification scans your entire list for invalid, catch-all, or blacklisted domains—spotting trouble before you send. It checks MX records, SPF, and whether the mailbox is active. This is a hard stop for addresses tied to known spam sources or blocked blacklists like Spamhaus or SORBS.

Verify Email Addresses in Real Time

For automated systems or real-time sign-ups, use the real-time verification API. It returns results in under one second per address, checking SMTP connectivity, DNSBL reputation, and whether the mailbox actually accepts emails. This means you reject bad addresses during signup or onboarding—before they ever hit your sending infrastructure. If an address originates from a known spam IP or a blacklisted domain, the API flags it immediately.

These checks are rooted in industry-standard practices. DNSBL lookups (like those used by SpamAssassin) are designed to detect messages from known spam sources. The DNS-based Blackhole List (DNSBL) works by publishing IP addresses and domains associated with spam. When an email arrives from one of these sources, SpamAssassin applies rules like RCVD_IN_SBL, RCVD_IN_XBL, or RCVD_IN_PBL. These are signals that your message is likely spam, even if the content is clean.

You can verify DNSBL status yourself using tools like MxToolbox or by checking RFC 5321 (SMTP) and RFC 5322 (message format), which define how mail systems validate sender and recipient addresses. But scanning thousands of addresses manually isn’t practical. That’s why automated verification is essential.

With MailTester, you’re not just checking syntax. You’re validating real-world deliverability. You avoid sending to domains on blacklists, disposable mailboxes, or catch-all systems that increase spam risk. This directly reduces bounce rates and keeps your sender reputation healthy.

How MailTester Detects DNSBL-Related Issues in Real-Time

You can catch DNSBL-related delivery problems before they hurt your inbox placement. MailTester checks every address against active blocklists like Spamhaus XBL and PBL in real time, flagging IPs tied to spam or poor reputation. This prevents bounces, spam complaints, and sender reputation damage.

How the Real-Time DNSBL Check Works

1. Initiate a real-time DNSBL lookup for each email address using its originating IP. MailTester queries Spamhaus, MXToolbox, and other live sources to check if the IP appears on any active blocklists. This step happens instantly during verification.
2. Map the IP to known reputation databases. We check against Spamhaus XBL (known spam sources), PBL (IPs assigned to end-users, not servers), and others. If the IP is listed, it signals a high risk of messages being blocked.
3. Correlate findings with email delivery behavior. An IP listed in PBL or XBL often means the sender lacks proper infrastructure, making deliverability unlikely. We detect this and tag the address accordingly.
4. Assign a clear verdict based on findings. If the IP is flagged, the system returns invalid, risky, or catch-all — not just a "neutral" result. These help you avoid sending to addresses tied to poor sender reputation.
5. Provide actionable feedback. The report includes the specific list names (like zen.spamhaus.org) where the IP is listed. You can verify that data independently via Spamhaus's ZEN list or MXToolbox’s Blacklist Check.

Why This Matters for Deliverability

Even one flagged IP can hurt your sender reputation. Email providers like Gmail and Outlook use DNSBLs as part of spam filtering. If your IP is on a known blocklist, your messages may be delayed, quarantined, or outright rejected. MailTester flags these risks early.

Let’s be clear: a single "risky" verdict isn’t a death sentence, but it’s a red flag. If you’re sending to hundreds or thousands of addresses, this step prevents cascading delivery failures. You’re not just cleaning invalid syntax — you're auditing sender legitimacy.

Use MailTester’s bulk verification to test entire campaigns. Or integrate our real-time API to verify emails on signup, before any email touches your server.

Spam filtering today combines reputation, behavior, and known bad infrastructure. Checking DNSBLs isn't optional — it's fundamental to modern deliverability.

What Each Verification Verdict Means in Deliverability Terms

You’re not just checking if an email exists—you’re assessing how likely it is to land in the inbox. A "valid" address means a real mailbox with good deliverability potential. "Invalid" means hard bounce territory. "Catch-all" signals a server that accepts all mail, often housing spam traps. "Risky" means the address matches known spam sources or has poor sender reputation, increasing blocklist exposure. These verdicts directly impact your deliverability health and sender reputation.

Understanding the Impact of Each Verification Verdict

Each verdict reflects a real risk or signal in the email delivery pipeline. Let’s break down what they mean in practice, and how they connect to systems like SpamAssassin’s RCVD_IN_ rules and DNSBL lookups.

SpamAssassin uses DNSBL lookups (like those from Spamhaus) to assess an address’s reputation. If an IP or domain is in a DNSBL, it can trigger rules like RCVD_IN_SBL or RCVD_IN_XBL. These are not just theoretical—they’re used by over 90% of enterprise mail servers. The Spamhaus Project maintains the most widely used blocklists, and many mail systems rely on them to filter incoming mail.

MailTester’s verification system checks against public DNSBLs like Spamhaus, as well as internal reputation models. You can test your own lists with bulk verification to catch risky and invalid addresses before sending.

Preventing RCVD_IN_ Issues by Fixing Your Senders and List Hygiene

RCVD_IN_ rules trigger when your message passes through a known spam source—often because your email list includes invalid, disposable, or catch-all addresses. These addresses are frequently abused by spam operations, so email receivers flag any mail sent to them. Clean your list regularly with MailTester to eliminate these risks before they affect your sender reputation. You’ll reduce bounce rates and improve inbox placement by ensuring only valid, deliverable addresses receive your campaigns.

Use real-time verification to catch bad addresses before they cause trouble

• Run every new list through MailTester's bulk email verification to catch catch-all, disposable, and invalid addresses before sending.
• Use the real-time verification API in your signup flow or CRM to validate addresses on the spot—preventing bad data from ever entering your list.
• Review the valid, invalid, catch-all, and risky verdicts to understand why an address fails—this clarity helps you refine your list acquisition and filtering logic.

Test inbox placement to confirm your messages aren’t getting blocked

• Use inbox placement testing to simulate real-world delivery and see if your messages land in spam folders due to RCVD_IN_ triggers or other spam filtering rules.
• Check your campaign delivery across major inboxes (Gmail, Outlook, Apple Mail) to spot if your current sender reputation is being impacted by past sender behavior or poor list hygiene.
• SpamAssassin’s RCVD_IN_ rules are based on DNSBL lookups—sources such as Spamhaus (https://www.spamhaus.org/) and SORBS (https://www.sorbs.net/) list IPs and domains known for sending spam. If your sending infrastructure matches any of these, your messages risk filtering.

DNSBL lookups are part of a broader defense mechanism used by receivers to reduce spam without manual review. The more known spam sources your email provider or sending infrastructure appears on, the higher your risk of being filtered—especially if your list contains addresses that route through known spam-friendly networks. Regular list hygiene reduces your exposure.

Integration with tools like Mailchimp, HubSpot, Klaviyo, or SendGrid ensures verification happens automatically at scale. When you send a campaign, MailTester checks the list in real time, flagging any addresses that could trigger RCVD_IN_ filters. This proactive approach avoids sending to risky addresses and protects your sender reputation.

How to Check if Your IP is Listed in XBL or PBL

You can check if your sending IP is listed in SpamAssassin’s XBL (Exploits Block List) or PBL (Policy Block List) using free tools like mxtoolbox.com or spamhaus.org. These services query global DNSBLs in real time. If your IP appears, it’s likely flagged due to past abuse, misconfiguration, or poor sending practices. Addressing the root issue — not just the listing — is key to restoring deliverability.

Step-by-Step IP Lookup Process

1. Go to mxtoolbox.com and enter your sending IP address in the "Blacklist Check" tool. This queries multiple DNSBLs, including SpamAssassin’s XBL and PBL, in a single request. It’s fast and gives clear visibility.
2. Visit spamhaus.org and use their "Query" tool to check if your IP appears in any of their blocklists, especially the XBL (malicious activity) or PBL (unauthorized sending on residential IPs). Spamhaus is one of the most respected blocklist providers in email deliverability.
3. Review the results carefully. If your IP is listed in the PBL, it likely means you’re sending from a residential or dynamic IP — which is not allowed by most email providers. The XBL flags IPs associated with known spam or malware.
4. Check your server and list hygiene. If you're sending from a shared hosting provider, a home network, or a compromised system, you're at high risk. Clean your email list and ensure only authenticated, legitimate emails are sent.
5. Submit a delisting request if needed. For Spamhaus, you can request removal via their form — but only after resolving the underlying issue. You must demonstrate that the IP is no longer associated with spam or abuse.

Prevent Future Listings

Residential IPs and shared hosting environments are commonly listed in the PBL because they’re typically not configured for bulk sending. If you're using such a connection, ensure your email traffic is limited to low-volume, authenticated use. For reliable sending, use a dedicated IP on a properly configured mail server with reverse DNS, SPF, DKIM, and DMARC.

Let’s be clear: fixing a blocklist listing isn’t about quick fixes. It’s about building a clean sending reputation over time. You can’t trust an IP that’s been flagged without cleaning up the source. Tools like inbox placement testing help you spot delivery issues before they become problems.

For a more scalable solution, use bulk email verification to audit your list for invalid or risky addresses. A clean list improves sender reputation — which makes your IP less likely to be targeted by DNSBLs in the first place.

Why Sending to a Risky Address Can Still Fail Even If the Domain is Valid

Even if an email address has a valid mailbox and a legitimate domain, the message can still be rejected if the sending IP is listed in a DNSBL like XBL or PBL. SpamAssassin checks the full path of the transaction—not just the recipient—and a risky origin can trigger rejection, even with a valid destination. You might send successfully to some addresses, but one high-risk recipient can harm your sender reputation and reduce deliverability across the board.

The Full Transaction Path Matters

SpamAssassin doesn’t just validate the final email address—it analyzes how the message reached that inbox. If your sending IP appears in the DNSBL list maintained by Spamhaus, which includes networks known for sending spam, the email can be blocked regardless of the recipient’s validity. The XBL (Exploits Block List) tracks IP addresses known to be compromised or used for malware, while the PBL (Policy Block List) flags IPs that shouldn’t be sending email directly—like residential or dynamic IPs.

Even if the domain is clean and the address is deliverable, an IP in the XBL or PBL can cause your message to fail during the SMTP handshake. Many mail servers refuse connections outright from known bad sources, which is why you might receive a rejection like “554 5.7.1 Message rejected due to spam content or sender reputation.” This isn’t a problem with the recipient—it’s a problem with the sender’s reputation and infrastructure.

One Risky Address Can Hurt Everyone

Bad actors often compromise legitimate accounts or lease IPs from risky networks, making even one problematic send in a batch enough to hurt sender reputation. Reputable email providers use real-time, automated risk scoring. A single failing delivery can trigger a temporary reputation dip, increasing the chance of future emails being filtered—or blocked—without warning.

That’s why bulk verification is crucial. Before sending to thousands of contacts, you should screen your list for risky senders, domains, or addresses that could expose your entire campaign. Tools like MailTester can test your list in real-time, flagging known bad IPs, disposable domains, and catch-all addresses before you send.

For example, the Spamhaus Project maintains the XBL and PBL, and their real-time lists are used by over 90% of major email providers. These are not optional filters—they’re foundational to modern filtering. You can’t control every third-party system, but you can control the quality of your sender reputation.

Use MailTester’s bulk email verification to catch risky recipients and IP-level flags before they impact your deliverability. Clean lists reduce bounces, protect sender reputation, and improve inbox placement across platforms.

Final Tip: Preventing SpamAssassin RCVD_IN_ Issues Starts Before Send Time

SpamAssassin’s RCVD_IN_ rules trigger when an email originates from an IP or domain listed on a DNSBL. These blocks aren’t caused by your message content alone—they’re rooted in sender reputation and list hygiene.

Waiting for bounces or delivery failures is too late. The real fix is pre-send validation: catch invalid, risky, or high-fraud-risk addresses before they ever enter your send queue.

MailTester’s 98.9% accuracy identifies invalid, catch-all, disposable, and risky addresses early, helping you avoid DNSBL triggers and protect your sender reputation. With 100 free verifications to start and credits that never expire, testing your list has no risk.

Keep reading

• Email blocklists: monitoring, causes and delisting (complete guide)
• Why Predictive Inbox Placement Models Fail on Temporary Blacklists
• Open Source Solution for Monitoring Blacklists and Sender Reputation
• Avoiding Blacklisting When Adding a Second Sending Domain
• Comparison of Historical Email Behavior Scoring: Barracuda, Mimecast, Cisco

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What does SpamAssassin RCVD_IN_XBL mean?

It means the sender’s IP is listed in the Spamhaus XBL, a DNS-based blacklist of known spam sources. This can trigger spam filtering or rejection.

How do RCVD_IN_PBL hits affect email delivery?

RCVD_IN_PBL indicates the sending IP is assigned to end users (like home networks) and should not be sending email. Messages may be blocked or marked as spam.

Can a valid email address still trigger RCVD_IN rules?

Yes — if the address's origin IP is listed in XBL or PBL, even a valid mailbox can cause delivery issues due to reputation filters.

How can I check if my IP is on the XBL or PBL?

Use tools like mxtoolbox.com or spamhaus.org to query your IP. If listed, resolve the issue by cleaning outbound mail and fixing server configuration.

Does MailTester check DNSBLs like XBL and PBL?

Yes — MailTester performs real-time DNSBL lookups against Spamhaus and other sources as part of its verification process.

How does list hygiene help avoid RCVD_IN_ issues?

Cleaning your list removes addresses from risky IPs, catch-all domains, and disposable or role-based accounts that trigger reputation filters.

Can MailTester prevent my messages from being rejected by SpamAssassin?

Not directly, but by identifying and removing bad addresses before send, it reduces the chance of triggering RCVD_IN_ rules and improves inbox placement.

What happens if I send to an IP listed in the PBL?

SpamAssassin may apply a high spam score, leading to message filtering or rejection by the receiving mail server.

Is using a shared server safe for email if it's not on the XBL?

Even without XBL listing, shared servers can be flagged by PBL if they use end-user IPs. Reputation is shared — one sender's abuse affects all.

How often should I verify my email list?

Before every send — especially if the list is older than 3 months. Use MailTester’s API or bulk checks to maintain accuracy.

What’s the difference between XBL and PBL?

XBL lists known spam sources and malicious IP addresses. PBL lists IP ranges assigned to end users that should not be sending email directly.

Does MailTester integrate with my email service provider?

Yes — MailTester works with Mailchimp, HubSpot, Klaviyo, and SendGrid to verify lists before campaigns, improving deliverability and sender reputation.