Fighting spam: find out how your hosting provider protects you

It is estimated that up to 95% of the e-mails exchanged on the internet are spam. Of these, 85% are thought to be sent by “botnets”, in other words infected computers or servers.

Is it still possible to tell a legitimate e-mail from spam? How do hosting providers protect their keen e-mail users?

Here are the answers.

The e-mail system is inherently insecure

E-mail was born in the 1960s and, by the 1970s, had taken a form quite close to the one we still know today. The e-mail standard defined at the time leaves senders free to choose the address they display as the sender of a message. This means that, without any verification, anyone can send an e-mail as anyone else to anyone at all.

Using an address that does not belong to you as the sender of an e-mail is called “mail spoofing”: it is a kind of e-mail forgery.

The problem? This is still how it works! Nothing in the basic e-mail standard prevents mail spoofing. In other words, the e-mail system is inherently insecure.

So is all lost for e-mail? For now, the world is not ready to give it up. Fortunately, there are now many ways of recognising a large share of spam and rejecting it before it even reaches the recipients' inboxes. Let us walk you through them.

E-mail authentication standards for hosting providers

Today, at least 6 “standards” (imposed by necessity, since there is no real consensus) are used to check whether an e-mail is genuine. If they are not met, the e-mail is likely to be rejected, and a rejection notice called a “bounce” is sent to the sender, explaining the technical reason for the rejection.
If you are interested in the technical details, you will find a detailed explanation on our wiki (in French).

The 4 basic standards an e-mail must meet to be accepted

HaiSoft checks that incoming mail complies with these rules.
Of course, all our customers whose domain is registered with us are configured to comply with them by default.

• MX: this is a matter of common sense: you do not accept an e-mail from a domain that does not exist or that cannot be replied to. The server therefore checks that the sender's domain (the part after the @) really exists and has an “MX” record, meaning that it can receive e-mail on the SMTP server defined as the domain's MX.
• HELO / Reverse IP: the aim here is to check that the sending server is reasonably serious and is not just a botnet, which, as mentioned in the introduction, accounts for the vast majority of spam. The check itself is simple, but the explanation is a little technical. E-mails are exchanged between SMTP servers. The “HELO” is the greeting an SMTP server sends when it delivers an e-mail. The HELO must be a valid domain name (or subdomain). That domain must point to the SMTP server's IP address, and the rDNS (reverse DNS) of that IP must be the same domain name as the HELO. In addition, the rDNS must not be the default one (for example an ISP's, containing the IP address backwards) but a name related to the service or the service provider. For example, at HaiSoft, if your e-mail is handled on srv01: the server's IP is 154.41.66.1, its reverse is srv01.haisoft.net and the mail server's HELO is srv01.haisoft.net. Everything is consistent and the loop is closed.
• Blacklists: public lists of spam senders exist. In the jargon they are called “RBLs” (realtime blackhole lists). If the sending IP is listed on one of these RBLs, the receiving SMTP server will probably reject the e-mail. You then need to stop sending spam and request delisting from the organisations that listed you. With some of them, you simply have to wait. You can check whether an IP is blacklisted with MXToolbox.
• The SPF record: SPF is probably the most basic and central rule today. The “Sender Policy Framework” defines which servers are allowed to relay e-mail for a domain. It takes the form of a TXT record in the domain's DNS zone and helps prevent “mail spoofing”, i.e. a third party sending e-mails in your name. For example, an @gmail.com e-mail will only be accepted if it comes from a server that belongs to Gmail and is listed in the SPF record of the “gmail.com” domain. An SPF record can be strict or non-strict (total rejection of non-compliant e-mails, or left to the recipient's discretion) depending on whether it ends with “-all” or “~all”. Note that it is the recipient who checks whether the incoming e-mail complies with the sender domain's SPF record. HaiSoft embraced the standard several years ago by providing a non-strict SPF record by default, and this record has recently become strict by default for new customers.

More advanced checks

• DKIM signatures: DKIM signs part of your outgoing e-mails with a code that can only be verified with the public key published in your DNS zone. This strengthens the authentication of e-mails sent from your domain, because only an e-mail sent from your server can carry a valid signature. The public DKIM key is added as a TXT record in your DNS zone. You can enable DKIM in a few clicks in Plesk (in French).
• The DMARC record: DMARC lets you choose what happens when DKIM or SPF checks fail: reject the e-mails, accept a given percentage of them, send reports (daily by default) to a specified address, and so on. This ensures that fake e-mails will be rejected by all recipients that check DMARC. New customers get a DMARC record by default. Existing customers can add it to their DNS zone or ask their favourite support team to do it for them!

Spam filters

Beyond the standards that outgoing e-mail must meet, spam filters check the content of messages. This aims to guard against the worst kind of spam: the kind that is perfectly authenticated and technically looks legitimate, but is in fact unwanted.

Spam filters therefore sort e-mails based on their content, looking for keywords and formatting errors, or even based on the e-mail client used, which appears in the message headers.

The most widely used spam filter is SpamAssassin, which gives each e-mail a score: the higher the score, the more likely the e-mail is to be spam. At HaiSoft, this threshold can be set independently for each address in the Plesk control panel, and the action to apply (do nothing, mark as spam, move to the spam folder) is configurable.

Does it work?

These systems eliminate the vast majority of spam.

Sometimes they even work a little too well! It regularly happens that users have misconfigured their domain or e-mail client. You may then come across false positives: legitimate e-mails that are rejected. The sender, on receiving a rejection notice, usually realises that their configuration is wrong and that they need to contact their hosting provider to fix it. In some cases, the sending server or the sender can be whitelisted so that these incorrect e-mails are accepted anyway. HaiSoft will help you in this situation, and also if it is your own e-mails that are being rejected.

Conversely, these protections are sometimes not enough. When an e-mail address is known to too many spammers, you may keep receiving too much spam and more drastic solutions are needed. But that is another topic, which we will cover in more detail in a dedicated article. Remember to subscribe to our newsletter to be notified of future articles.

We hope this helps you better understand what makes e-mail deliverable, both when receiving and when sending. If you are a HaiSoft customer and receive too much spam, or if your e-mails end up in spam folders, our support team will be happy to help you perfect your configuration.