Surprisingly, despite the tough anti-spam protection measures we’ve taken on our platform, it is still common for users to get spam messages that appear to have originated from their own email domains.

For example, when the mailbox john@domain-name.com gets a spam email, which appears to have been sent from whatever@domain-name.com 

So how is this ever possible given the spam filters and the SPF protection enabled on our web hosting platform?

How do spammers manage to use your email address domain to send spam?

Normally, there is very little validation performed on the identity of the email’s sender.

Technically speaking, there is no way to prevent someone from sending you a message that appears to have been sent from your email address, even if you’ve taken all measures to protect your identity.

This is just how email exchange works, in general.

How does SPF protection work?

To cope with this imperfection of email sending, hosts often take extra measures to double secure their clients’ mailboxes, among them spam filters and the more advanced SPF and DKIM technologies.

With SPF protection and DKIM (DomainKeys Identified Mail) enabled on our platform, users can verify their incoming messages at the server level, determine if the messages are authorized and discard them as fraudulent if they are not:

This way, the very source of the spam message is being targeted – the mail server that has sent the given email.

This would not be possible with a normal spam filter that targets only the message itself.

We’ve been offering SPF protection and DKIM (DomainKeys Identified Mail) for a few years already to help users fight spam at a more advanced level.

Despite that, recent practice has shown that users under persistent spam attacks keep facing problems even after they’ve enabled SPF validation for inbound emails.

This is why, we’ve taken measures to give those users the option to exert tighter control over what enters their mailboxes.

How to use SPF protection efficiently during persistent spam attacks?

From today, users will be able to select the level of SPF validation enabled for their inbound email flow – from the Email area of the Web Hosting Control Panel.

Those who are concerned about missing out on valid messages should opt for the non-strict SPF checking mode.

To enable that mode, select ‘Non-strict mode’ from the Mode drop-down menu when creating an SPF instance:

The newly added strict mode is selectable from the Mode drop-down menu as well:

It allows users who are frequent targets of email forgery to enforce super-tight SPF protection of their mailboxes.

Technically speaking, the main difference between the strict and the non-strict mode is one symbol.

Here is how an SPF record in non-strict mode, also known as ‘loose’ or ‘softfail’ mode, would look like:

v=spf1 ip4:10.0.0.1/32 ~all"

In strict mode, the same record would look like this:

v=spf1 ip4:10.0.0.1/32 -all"

As you can see, the difference between the two records lies in the ‘~/-’ symbol in front of the ‘all’ parameter.

However, this small syntax difference actually makes a big difference.

In the non-strict mode example above, the ‘~’ symbol means that inbound emails sent from a domain that does not match the SPF record will not be rejected, but rather marked as potential spam.

In this case, the given message’s spam score will determine whether or not the email is actually making it to the recipient’s inbox.

In the strict mode example, all inbound messages that fail to pass the mail server validation test will be rejected immediately.

SPF protection in strict mode – an example from practice

Here is an example of how strict SPF verification works in practice:

Not long ago, we got a report that a client of ours received an email originating from facebookmail.com.

The email was blocked immediately, since Facebookmail.com has strict SPF settings in place so that no one could use the popular domain for spoofing scenarios.

Here’s what our system recorded:

2016-03-30 09:57:13 H=mail1485.netcetera.co.uk [81.27.104.205] F=<notification+p1cc6h=e@facebookmail.com> rejected RCPT 
<mail@XXXXXXXX.co.uk>: [SPF] Sender host (81.27.104.205) is not authorized to send mail from facebookmail.com. Please see

http://www.openspf.org/Why?id=notification+p1cc6h=e@facebookmail.com&

ip=81.27.104.205

If Facebookmail.com had a loose SPF record enabled, then that spam email might have sneaked through.

The newly enhanced SPF protection service will allow you and your customers to exert tighter control over your inbound emails and will help strengthen the overall security on our platform.

So, feel free to spread the word to your own customers about this email safety-friendly feature.