[ Deliverability & sender rules ]

Spamhaus PBL versus abuse listings: choose the appropriate response

Recognize PBL as a direct-to-MX policy signal and choose supported submission or eligible removal rather than assuming abuse.

By the EmailAuth research team · 3 min read

[ Key points ]

  • Recognize PBL as a direct-to-MX policy signal and choose supported submission or eligible removal rather than assuming abuse.
  • A PBL entry concerns sending policy, not proof of abuse or requester authority.
On this page

A PBL result can alarm a user whose ordinary internet connection is working normally. The important distinction is that the Policy Blocklist is not simply a list of malicious machines. It identifies IP ranges that, under the applicable policy, should not deliver mail directly to third-party MX servers.

Read the policy meaning

Spamhaus states that the PBL can include both dynamic and static IPs. Being static is therefore not enough to establish that an address belongs outside the list. The relevant question is whether the address is authorized and suitable for direct-to-MX sending under the network's policy. Spamhaus PBL.

Do not use this result alone to accuse a user or device of sending spam. Other evidence may justify an abuse investigation, but a policy-range listing is a different observation. Retain any additional named datasets and investigate them independently.

Distinguish submission from direct delivery

A mail client normally submits through its configured mail service rather than acting as an internet-facing mail server. Spamhaus's PBL FAQ describes using the appropriate authenticated SMTP service when a user's address is in PBL. Follow the provider's current submission configuration; do not invent a relay host or credentials. PBL FAQ.

This does not mean tunnelling unauthorized traffic through any available relay. The service must permit the account and workload. Authentication, suppression and the service's sending policies still apply after a route change.

Verify authority independently of the request

The written authority-check scenario contrasts two requesters. The first has an assumed authenticated provider account, admin-1, and a fictional callback through a pre-existing service-owner directory confirms the business purpose and network authorization. The result is eligibility review, not automatic removal. The second supplies only an inbound claim of ownership; a separate directory callback fails to confirm authority, so the proposed rule holds the request and makes no relay or DNS change.

The control boundary is the mail-provider account and the network's sending authorization. A requester-supplied phone number would not be independent verification. These identity and callback details are invented teaching inputs; no actual person, business, account or network authority was verified. No program, callback, DNS lookup, removal request or relay configuration was executed for this written comparison.

Keep the alleged abuse of a support process separate from PBL's policy meaning. A PBL-shaped observation alone proves neither compromise nor the requester's authority. In a real case, verify through approved existing channels before granting access or changing a sending route, and retain the minimum necessary evidence of the decision.

Check eligibility before requesting removal

Read the current official instructions for the exact IP. Confirm who controls the address and what the network permits. Spamhaus’s single-IP guidance calls for a static IP assigned to the requester, running an outbound mail server with appropriate forward and reverse DNS. Its removal criteria also restrict outbound port25 to that server; being static alone is still not sufficient. Follow any provider-managed removal route when applicable. A removal request should accurately describe the legitimate direct-sending need and completed requirements, not merely say that the sender dislikes the result.

An address may also appear in another dataset whose requirements remain unresolved. PBL removal does not clear an SBL, XBL or other listing, and it does not guarantee that a receiver will accept the traffic. Avoid bundling these states into a single “clean” flag.

Verify the approved route using authorized test recipients and retain actual receiving outcomes. The durable repair is an appropriate, supported sending path with correct identity controls, not a screenshot of one successful lookup.

Check the observation point

The PBL is intended for the connecting IP during SMTP, not every historical IP in Received headers and not URL or web-access filtering. A legitimate user can appear on a PBL-listed access address before submitting through an authorized service. If a complaint came from deep header scanning, the proposed filter owner should examine that use before treating the historical address as the active delivery source.

[ Takeaway ]

A PBL entry concerns sending policy, not proof of abuse or requester authority.

[ By role ]

What this means for you

Choose your role for practical next steps.

IT / Mail Admin

Separate client submission and server delivery

The appropriate fix depends on the actual sending role.

Next steps

  1. Read exact PBL guidance.
  2. Verify network policy.
  3. Test the approved route.

CISO / SecOps

Do not confuse policy with compromise

Evidence should support the classification.

Next steps

  1. Investigate additional indicators.
  2. Control relay access.
  3. Keep dataset states separate.

Founder / Non-technical

Choose a supported sending architecture

A policy listing may call for a route correction rather than an incident accusation.

Next steps

  1. Confirm the workload.
  2. Use an authorized service.
  3. Avoid guaranteed-delivery claims.

[ FAQs ]

Frequently asked questions

Does PBL mean the machine sent spam?

Not necessarily. It is a direct-to-MX policy dataset.

Can static IPs be listed?

Yes. Static addressing alone does not establish eligibility for removal.

What should a normal mail client use?

Its provider’s approved authenticated submission service.

Can any open relay be used instead?

No. Use an authorized service that permits the workload.

Does asserted server ownership automatically justify removal?

No. Verify address control, policy and current eligibility.

Does PBL removal clear another list?

No. Other dataset states must be evaluated separately.

Did the fixture send or delist anything?

No. It is a written authority-check scenario with no program, network test, callback or delisting performed.

What is the final success criterion?

An authorized supported route and observed scoped delivery, not a universal guarantee.

[ Sources ]

Sources

  1. Spamhaus Policy Blocklist

    Sections Non-mail Emitting IPs

  2. Spamhaus PBL FAQ

    Sections What is the Policy Blocklist (PBL)? · Enabling SMTP Authentication · What IPs should be removed from the Policy Blocklist (PBL)? · Single IP removal for outbound email server administrators · Avoid common errors: how the Policy Block List (PBL) should not be used

  3. RFC 5321 SMTP

    Sections §3.3 · §4.2.1 · §4.2.5 · §5.1 · §6.1

[ Glossary ]

Glossary

Direct-to-MX
Delivery by a sending host directly to a recipient domain’s mail exchanger.
Authenticated submission
Submitting mail through an authorized service using its supported account authentication.

Enterprise provenance

Why top financial institutions and governments retired their email security dashboards.

Traditional email authentication platforms sell you a dashboard and ask your engineers to do the labour. In high-stakes environments, manual oversight means delayed enforcement, configuration drift and unmonitored shadow domains.

EmailAuth is the agentic email provenance platform. Our agents enforce p=reject, keep third-party senders aligned and move your domains to full RFC 9989 compliance, the new DMARC standard,, with human-in-the-loop auditability.

Governments Large enterprises Tier-1 financial institutions

SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption

Knowledge Base