InboxGrade

Listed on Spamhaus PBL (Policy Block List)

Your sending IP is in the Spamhaus Policy Block List, which flags address space the operator has declared should not deliver SMTP traffic directly to the public internet.

Impact — High impact

Receiving MTAs that query zen.spamhaus.org will reject or defer mail from a PBL-listed IP with a 550 response citing the listing, so direct-to-MX delivery stops working from that address. The PBL is not a reputation list — it is a policy declaration by the netblock owner (usually your ISP) that the IP is end-user space and should relay through an authenticated smarthost. Running Postfix, Exim, or sendmail on a residential, DHCP, or dynamic cloud IP will see widespread rejections at Gmail, Outlook, Yahoo, and anyone else using the Zen aggregate zone.

What causes it

  1. Sending directly from a residential, DSL, cable, or mobile IP that your ISP has declared as end-user space in the PBL.
  2. Running an outbound MTA on a dynamic or ephemeral cloud IP (common with new DigitalOcean, Vultr, AWS EC2, or Hetzner allocations) that the provider has registered as non-mail-sending.
  3. Recently assigned IP from a block the upstream ISP has preemptively listed to prevent abuse from compromised customer devices.
  4. Hosting provider policy forbids direct port 25 egress and has published the range to the PBL rather than only blocking the port.
  5. Self-listing by the IP owner through the Spamhaus PBL self-service portal that was never removed after repurposing the IP for a mail server.

How to fix it

Confirm the listing and read the exact return code

Query the Zen zone directly to confirm PBL versus SBL/XBL. A PBL hit returns 127.0.0.10 or 127.0.0.11; anything else means a different Spamhaus list and a different remediation path.

dig +short 4.3.2.1.zen.spamhaus.org TXT
# reverse your IP octets. Example for 203.0.113.5:
dig +short 5.113.0.203.zen.spamhaus.org A TXT

Relay through an authenticated smarthost instead of delivering direct-to-MX

The PBL is enforced by policy, not reputation — delisting a residential or dynamic IP will not stick. Configure your MTA to submit on port 587 with SMTP AUTH to a provider whose IPs are not PBL-listed. For Postfix, point relayhost at the smarthost and enable SASL.

# /etc/postfix/main.cf
relayhost = [smtp.postmarkapp.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt
smtp_sasl_tls_security_options = noanonymous

If this is a legitimate static mail server IP, request PBL removal

Only pursue removal when you own or lease a static IP with a signed AUP that permits mail, functional rDNS matching the HELO hostname, and a published SPF/DKIM/DMARC set. Use the Spamhaus removal form at https://www.spamhaus.org/pbl/removal/. Removal is instant but will reapply at the next ISP sync if the netblock remains in the ISP's PBL declaration — fix rDNS and port 25 egress with your ISP first.

# verify rDNS matches HELO before submitting removal
dig +short -x 203.0.113.5
dig +short mail.example.com

Prevent re-listing on cloud providers

On AWS, submit the EC2 reverse DNS and Port 25 throttle removal request before sending. On GCP, outbound port 25 is permanently blocked — use a relay. On DigitalOcean, Vultr, and Hetzner, open a support ticket to confirm the IP is cleared for SMTP and request a static PTR record matching your sending domain.

Fixed it? Run a fresh test to confirm.

Test my inbox →

Related errors