Blocklist Removal Center
About Spamhaus  |  FAQs  |  News Blog   
Frequently Asked Questions (FAQ)
General Questions
Hacked... Here's help
ISP Spam Issues
Legal Questions
Marketing FAQs
Online Scams
Spamhaus BCL
Spamhaus CSS
Spamhaus DBL
Spamhaus HBL
Spamhaus PBL
Spamhaus SBL
Spamhaus XBL
Spamhaus DROP
 » BGPf FAQs
 » Datafeed FAQs

Spamhaus CSS


What is CSS?


Misconfigured SMTP servers
Why is my IP address listed in CSS?
Removing an IP listed in CSS


How do I use CSS and what is its return code? (
How does CSS handle IPv6 addresses?
Using SpamAssassin and Rspamd with Spamhaus data


What is CSS?
The Spamhaus CSS is a component of the SBL.

The CSS list is an automatically produced dataset of IP addresses that are involved in sending low-reputation email. CSS mostly targets static spam emitters but may also include other senders that display a risk to our users, such as compromised hosts. CSS lists both IPv4 addresses (/32) and IPv6 addresses (/64 or larger). CSS listings are influenced by:
  • Email showing indications of unsolicited nature;
  • Having poor list-hygiene;
  • Sending out bad email due to a compromise, insecure installation or misconfigured server;
  • Other indicators of low reputation or abuse.
CSS listings are based on a wide range of inputs and are always the result of multiple events and heuristics.
  • CSS is also included in Zen, so if the SBL or Zen are already in use, CSS is also.
  • It allows fast, no-questions-asked removals - within limits - but it also re-lists IPs quickly if there is re-detection.


Misconfigured SMTP servers
To ensure uninterrupted email delivery, it is critical that all technical settings be correct. In case of difficulty, they should be double checked.
  • Misconfigured SMTP servers may have problems delivering email to many networks, including ones that do not use Spamhaus data.
SMTP servers should be configured with correct forward and reverse DNS and HELO/EHLO values.
  • DNS is used to resolve a domain name to an IP address. This act is known as a forward DNS and is performed every time you visit a site on the internet. Reverse DNS (rDNS) is a method of resolving an IP address back to a hostname. Your hosting company or email service provider can help set this up or correct it.
    • If you need to correct your rDNS and are using OVH cloud or Amazon cloud (Lightsail) they have information on their websites that can help.
    • The forward DNS lookup (domain name to IP address) of your IP should match the HELO value set in your server.
  • HELO is an SMTP command sent by an email server to identify itself when connecting to another email server, to start the process of sending an email. It is followed with the sending email server's hostname.
    • One way of testing whether an SMTP server is misconfigured is to send an email from it to A bounce will immediately be returned that contains the required information.
    • Common misconfigurations of HELO are: "localhost.localdomain", "WIN-XYZPDQ01" or "mail".
    • A HELO/EHLO value should be a fully qualified domain name (FQDN)
  • About loadbalancers:
    • Some sites place their mail servers behind load balancers. While this may have some advantages, this practice has the side-effect of giving the public-facing IP the appearance of being infected by malware. If this is the issue, then the solution may require an engineering design change.
NOTE: If the IP is not a mail server, or the HELO settings are in fact correct, check for malware or a misconfigured process. You may need to contact your IT department, network engineer, MTA vendor or hosting company for help.

Why is my IP address listed in CSS?
Spamhaus is a reputation data producer. The actions taken by email/internet service providers that are based on our data will vary by ISP.
  • It is up to the provider to decide how to treat IP addresses listed in CSS.
IP addresses listed in CSS have been detected sending mail which matches CSS heuristics.
  • CSS listings expire three (3) days after the last detection.
  • If an IP is listed, the problem is recent!
CSS rules look for several problems, including snowshoe spam, mail from known bad actors, infected or compromised websites or CMS, bots, and other insecure or misconfigured applications or devices.
  • If an IP is listed in CSS, the first thing to do is check all technical settings for correctness. For more information please see our FAQ on this topic.
  • If an IP is listed because it is compromised, we have an FAQ that is a good place to start.
NOTE: We do not provide spam samples related to CSS listings, though in some cases of compromise we may be able to provide some additional information if we have it.
  • We recommend that all domain and mail server administrators monitor the appropriate role accounts and feedback loops for their domains and network space.
  • Server logs might also have useful information.
If an IP address is listed, please check to see if any related domains are in the DBL.
  • The Spamhaus Blocklist Removal Center has forms for both IP addresses and domains.
  • If you are authoritative for an IP address, and you believe the issues that caused the listing have been solved, you can request a delisting.

Removing an IP listed in CSS
CSS listings expire quickly: normally, three days after last spam detection.
  • It allows fast, no-questions-asked removals - within limits - but it also re-lists IPs quickly if there is re-detection.
  • De-listing should begin at the Blocklist Removal Center. Follow the links from there.
Whatever caused the problem must be identified and corrected before removing an IP from CSS.
  • CSS will allow the removal of an IP, but it will also re-list it immediately if a problem continues to be detected.
  • Self-removals are limited.
IMPORTANT: The reputation of any associated domains should also be checked using the Blocklist Removal Center: Domain and IP reputations are related.

The Hacked? Here's Help FAQ offers a great deal of information on how to deal with various reasons for CSS listings.


How do I use CSS and what is its return code? (
The Spamhaus CSS is used in the same way as the SBL or Zen.
  • One or the other must be used (but not both!) in order to use CSS; CSS is not a separate zone.
  • CSS is included in Zen, so if the SBL or Zen are already in use, CSS is also.
  • The return code for CSS in either "" or "" zone is
For more about Spamhaus DNSBL usage, and all our return codes, see the DNSBL Usage FAQ.

How does CSS handle IPv6 addresses?

CSS lists /64 subnets of IPv6 addresses.

  • IPv6: CSS lists "/64" or larger CIDR blocks.
    • A very large number of spam-emitting IPv6 addresses in different /64 blocks within the same network could cause listings to extend to larger blocks.
    • Without such extensions/aggregations, the IPv6 zone size could become unworkably large.
    • Various strategies used by spammers to game the system are made much more difficult by the use of aggregated blocks rather than single "/128" IPs.
A "/64" is the industry standard for the smallest IPv6 allocation to individual customers, even for home-uses like cable, DSL or wireless.
  • For ISPs which follow standard industry practices, CSS IPv6 listings will only affect a single customer.
  • The "/64" choice has RFC4291 as its origin and it is further discussed in RFC6177
  • More technical reasons for choosing /64 customer assignments, at minimum, are discussed in a post on, on, and in M3AAWG document "Policy Issues for Receiving Email in a World with IPv6 Hosts."
IPV6 allocation information quoted from the Regional Internet Registries (RIRs) documentation:
  • AFRINIC, IPv6 Address Allocation and Assignment Policy | AFPUB-2013-v6-001
    6.4.1. Assignment address space size:
    • "Assignments are to be made using the following guidelines:
      • /48 in the general case, except for very large subscribers.
      • /64 when it is known that one and only one subnet is needed by design
      • /128 when it is absolutely known that one and only one device is connecting."
  • APNIC, APNIC guidelines for IPv6 allocation and assignment requests
    10.1. LIR assignments to end sites:
    • "An LIR can assign a /64 to /48 to an end site customer network based on their requirements. The following guidelines may be useful:
      • /64 where it is known that only one subnet is required.
      • /56 for small sites where it is expected only a few subnets will be required within the next two years. Subscribers can receive a /56 when connecting through on-demand or always-on connections such as small office and home office enterprises.
      • /48 for larger sites, or if an end site is expected to grow into a large network."
  • ARIN, Your First IPv6 Request
    • Step 2: Determine Your Block Size:
      "IPv6 block size is based on the number and size of subnets to be assigned to customers, not on the number of IP addresses required by customers. ISPs will typically assign one subnet (/48 or smaller) to each customer. The default /32 minimum allocation is sufficient for many ISPs since it contains 65,536 /48 subnets to assign to customers. ISPs may also opt to request a smaller /36 allocation."
  • LACNIC, IPv6 Address Allocation and Assignment Policies
    • - Assignment address space size:
      "End sites or users must be assigned a prefix that is a multiple of "n" /64’s which must be enough to meet their current and planned needs, considering existing protocols and future possibilities and thus avoiding possible renumbering scenarios."
      • The size of the prefix to be assigned is an operational decision of the LIR/ISP, although the selection of /48s is recommended for simpler and more functional infrastructure for all the endpoints of the network.
      • Persistent prefix assignments are recommended to avoid undesired failures.
      • Using a /64 prefix for point-to-point with GUAs is recommended."
  • RIPE, Best Current Operational Practice for Operators: IPv6 prefix assignment for end-users - persistent vs non-persistent, and what size to choose
    • 4.2. Prefix assignment options:
      "A single network at a customer site will be a /64. At present, RIR policies permit assignment of a /48 per site, so the possible options when choosing a prefix size to delegate are /48, /52, /56, /60 and /64. However, /64 is not sustainable, it doesn't allow customer subnetting, and it doesn't follow IETF recommendations of “at least” multiple /64s per customer. Moreover, future work within the IETF and recommendations from RFC 7934 (section 6) allow the assignment of a /64 to a single interface ("
  • RIPE, IPv6 Address Allocation and Assignment Policy
    • 5.4.1 Assignment address space size:
      "End Users are assigned an End Site assignment from their LIR or ISP. The size of the assignment is a local decision for the LIR or ISP to make, using a value of "n" x /64. Section 4.2 of ripe-690 provides guidelines about this."
Customers of providers that assign different customers within the same /64 block should contact their provider's support, ask for a dedicated /64 assignment, and move mail service to a non-shared /64 range.

NOTE: Linode customers should read this document, then open a ticket to get their own /64.

Using SpamAssassin and Rspamd with Spamhaus data
We have developed our datasets with the final goal of being the most compatible with existing software. The two biggest open source antispam projects are SpamAssassin and Rspamd.

To show the best way to use our data with these products, we have created two dedicated Github projects. The projects contain instructions, rulesets, and code to make the best out of our DQS product.

© 1998-2021 The Spamhaus Project SLU. All rights reserved.
Legal  |  Privacy