The Spamhaus 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.

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 generally expire three (3) days after the last detection. In some cases of chronic abuse, the listings can last longer, but should not be a surprise to the administrator anymore.
• 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.

• This IP and Domain Reputation Checker has the ability to check 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.

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 helocheck@abuseat.org. 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.

Misconfigured Plesk hosts can have unexpected outcomes – the behavior of such a host closely mimics the behavior of a certain type of spambot.

Plesk’s online guide describes the “Outgoing mail mode” option and its three settings:

• Send from domain IP addresses:

By default, mail from each domain is sent from the domain’s IP address. The host name used in the SMTP greeting is the Plesk server host name specified in Tools & Settings > Server Settings. Selecting this option may result in mail sent from some or all domains being marked as spam if the Plesk server host name fails to resolve properly, or if the domain’s IP is different from the one to which the Plesk server host name resolves.

This option works best if it is required to have a single IP address on the Plesk server.

• Send from domain IP addresses and use domain names in SMTP greeting

If selected, Plesk changes the mail server configuration so that the SMTP greeting contains the name of the domain from which the email message is sent.

Warning: Selecting this option may result in mail sent from some or all domains being marked as spam if the destination mail server uses Spamhaus XBL and more than one domain on the Plesk server uses the same IP address.

In addition, selecting this option on Plesk servers hosting a large (more than 100) number of domains will likely result in significantly increased server load.

This option works best if there is allocated a dedicated IP address to every domain hosted on the Plesk server, and the number of domains hosted on the server is not very large.

• Send from the specified IP adresses:

If it is required to use certain IPv4 and IPv6 addresses for all outgoing mail.

If None is selected, outgoing mail will not be sent.

The first setting is shown enabled in the circled in red section in the screen shot below:

We recommend you use the first or third option in virtually all cases.

The second option, “send from domain IP addresses and use domain names in SMTP greeting” can lead to reputational and XBL issues, and should be used with extreme care:

• Many Plesk installations are unable to bind to different IP addresses to send email on behalf of each hosted domain. This is especially true if the web server uses a single IP address to host multiple domains by “virtual host” – there are no other addresses to bind to, so, it’s using the same IP address all the time.
• The “send from domain IP addresses and use domain names in SMTP greeting” option should only be used if you’re certain your installation can successfully bind to specific outbound IP addresses, and that each IP address will only be used for at most 2-3 different domains.

If you are using cPanel, and need to set or change a HELO/EHLO value, this cPanel support article will show how it is done.

If you are using Direct Admin, and need to set or change a HELO/EHLO value, this Direct Admin web control panel support article will show how it is done.

CSS listings expire quickly: normally, three days after last spam detection. In some cases of chronic abuse, the listings can last longer.

• 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 IP and Domain Reputation Checker. 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 IP and Domain Reputation Checker: 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.

In most cases, if you have to ask this question, the answer is no.

Wildcard DNS is a catch all DNS record. In the absence of anything more specific, the server will give the same answer to any question for that record type. Be it MX or CNAME or A record. This is denoted by an asterisk (*) and used for subdomains which do not have an explicit DNS record. (e.g., blog.example.com, shop.example.com, randomname.example.com) and there's no specific DNS record for that exact subdomain, the wildcard DNS record for *.example.com will be used to resolve the request.

Common issue with wildcard * DNS

The most common issue of using wildcard DNS is sub-domain take over. With wildcard DNS, random domains will resolve to the root domain causing it to be an easy vector for abusive and phish actors. When combined with SPF records that are excessively permissive that can mean that anyone can spam as your domain.

Who may benefit from wildcard * DNS?

Some Email Service Providers (ESPs) may benefit from carefully implemented wildcarding, but they are special cases.

Security best practices strongly recommend avoiding wildcard DNS records whenever possible. While they offer convenience, the security risks often outweigh the benefits.

Do I have wildcard * DNS?

Often we see tickets from domains that are listed for malware or phish where the actual owner has no idea what is going on. In many of those cases, someone has hacked their DNS and added a wildcard record pointing at their own server.

Nothing changes for the actual owner and they will not notice until it is too late, but all of a sudden "down.with.the.mekon.example.org" is serving phish and the domain ends up listed for hosting phish.

This happens far too often, so please check your DNS for records pointing at things you do not recognise.

Should providers use the CSS to block their own users?

• If the same hosts are used for both incoming email and outgoing (smarthosted) email, connections using SMTP authentication should be exempted from CSS checks.
• End users are often on dynamic IP addresses: a user may be assigned an IP address from their provider that is listed in the CSS because of the situation of a previous user of that IP address.
• The CSS can be used to alert an ISP's security department when a user's IP is in the CSS, but should only be used as an "informational" alert.

The Spamhaus CSS is used in the same way as the SBL or Zen zones.

• One zone 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 “sbl.spamhaus.org” or “zen.spamhaus.org” zone is 127.0.0.3.

For more about Spamhaus DNSBL usage, and all our return codes, see the DNSBL Usage FAQ.

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 Slash64.net, 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

  • 4.5.3.1 – 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 (https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-07).”

• 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.

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.

• SpamAssassin-DQS
• Rspamd-DQS