Used for phishing and other social engineering attacks, email spoofing is terribly tricky. Well executed, it’s difficult to detect and misleads the recipient.
To counter it, there are technical solutions to put in place when you configure your mail servers. We will see the three essential elements to install to prevent email spoofing: SPF, DKIM and DMARC.
What’s email spoofing?
To understand email spoofing, let’s take a look one at how email works. Emails are routed through the SMTP protocol to arrive on the recipient’s mail servers.
SMTP is a protocol from the beginning of the Internet and has evolved little since. Thus, any server can send an email by displaying any email address. Indeed, the sender field (from) is only a text field among others, not protected. This is why spoofing is possible.
Email spoofing consists in impersonating an email address when sending a message. The aim is to hide the real origin of the sender and to make it look like a trusted address.
Several types of phishing attacks use email address spoofing to make them more credible.
We focus today on email spoofing, but spoofing covers a variety of techniques to take over someone’s identity. For example, some attacks exploit phone spoofing, i.e. spoofing a phone number. Other attacks use ARP spoofing, DNS spoofing, etc.
Email spoofing makes phishing more dangerous
Phishing uses very often email spoofing, as it makes the email look like it comes from a known or reliable sender. In cases of ‘classic’ phishing as well as more sophisticated spear-phishing or BEC attacks, email spoofing makes the pretexts credible or stronger.
Indeed, since the first scam and phishing emails, we have all learned to distrust messages with obvious spelling mistakes, exaggerated requests, not to follow unusual links, etc.
But attackers have adapted and phishing has evolved. Nowadays, phishing emails mostly respect the current codes for content and formatting (signature, logo, button to incite to click…).
Email spoofing is an additional element to make the targets feel confident, by giving them the impression to exchange with a known or official contact. They’re thus more likely to click on a link or to answer a request for sensitive information.
Email spoofing and homograph attacks, two sides of a coin
We can distinguish two ‘forms’ of spoofing:
- Spoofing that spoofs a real email address;
- or the use of another email address, which is very close visually or credible in the phishing scenario. These are called homograph attacks.
Let’s take [email protected] as an example to explain homograph attacks. They rely on various ‘tricks’ to impersonate the desired person or organisation:
- Changing, reversing, adding or deleting characters: grace.hopper@sciemces.com
- Use of non-Latin characters (non-ASCII characters): grace.hopper@scieпces.com
- Use of a close or credible domain in the attack: grace.hopper@sciences.us; grace.hopper@science.com
The only limit in the possibilities of variation is the imagination of the attackers and the constraints of SMTP (unsupported characters, restrictions related to the TLDs…). You can detect homograph attacks by looking carefully at the sender’s address. Sometimes you have to click on ‘Reply to message’ to see the real reply address, if the attacker had also displayed another sender address.
The difficulty, when you know the contact, is to recognise the sender at a glance without reading the address and start processing the email. Busy in a working day, it’s easy to fall into the trap.
Homograph attacks are more frequently used than email spoofing, as it has become harder to execute. Spam filters and other email service indicators rely on the absence of all three protocols to classify emails as spam or phishing.
It’s therefore essential to configure SPF, DKIM and DMARC so that:
- spoofing emails are detected before they arrive in mailboxes,
- that attackers don’t spoof your domain,
- and that your emails arrive correctly at your recipients.
The SPF protocol: securing the sending servers
The first step is to declare the servers. The SPF (Sender Policy Framework) standard is a DNS record that defines the mail servers authorised to send messages for your domain. This protocol allows listing the servers and IP addresses authorised to use the domain name. This is the first step to authenticate your emails.
In fact, when a message from your organisation is sent, the recipient’s mail servers check that the mail comes from one of the authorised domains. If it doesn’t come from an authorised domain, the message will arrive in spam.
Misconfigured SPF records can cause delivery problems. Depending on the email solution provider you use, they usually provide guidelines for configuration. You can also consult these best practices when configuring SPF.
DKIM: signing and authenticating messages
As a second measure, the DKIM (or DomainKeys Identified Mail) protocol must be installed. It defines the authentication of the email sending domain thanks to a pair of private and public keys. The keys allow signing and validate the source of the messages.
It’s in fact a signature put on your DNS record, which includes the identity of the signatory.
Concretely, the signature is added to the header of outgoing emails using the private key. When the recipient’s servers receive the email, they check with the public key the source of the message and whether the message has been modified.
The DKIM protocol is a complement to SPF and helps determine whether the message should be considered spam or not.
DMARC: verifying the application of SPF and DKIM protocols
DMARC (Domain-based Message Authentication, Reporting and Conformance) comes next to SPF and DKIM. The DMARC record verifies the application of the SPF and DKIM protocols, and in particular the correspondence between the header and the sending domain.
You can use this tool to check the SPF, DKIM and DMARC configuration.
It defines the rules to follow if a message fails these checks. There are three options: Reject, Quarantine or Do nothing. You can configure the rules to accept soft or hard alignment.
Finally, the DMARC protocol sends reports showing validated and non-validated messages from your domain. This can be useful to identify possible threats, abuse or configuration flaws.
BIMI: an optional visual indication
Finally, another optional configuration is possible: the BIMI (Brand Indicators for Message Identification). This isn’t a technical element that reinforces security, but a visual addition that gives an indication of the sender’s identity.
It displays the brand logo directly in the inbox. You can only add BIMI if you have SPF, DKIM and DMARC protocols active, and if the DMARC policy is on quarantine or reject.
Deployed since 2019, not all email providers (for example Outlook & Office365) support BIMI yet.
If the idea is interesting to strengthen the trust by knowing which image is usually displayed next to a contact, it doesn’t guarantee protection against phishing.
Indeed, an attacker could very well look for which image uses the organisation they want to spoof, then configure a domain with SPF, DKIM and DMARC and associate it with the same image. The BIMI will then be a disadvantage, as users will be even less suspicious of this email.
How to protect yourself from spoofing and phishing?
These three protocols allow to limit the risks of spoofing an exact email address. They’re also used to protect domains that don’t send or no longer send emails. You can consult this resource which details the configurations to do for these cases.
Thanks to the adoption of these protections, email spoofing is much less common than before.
On the other hand, attackers are increasingly using ‘visual spoofing’, so homograph attacks, in phishing. To counter these attacks, the key is to raise awareness among teams. They need to acquire the means to counter phishing attacks, from clues to identify suspicious emails to the psychological mechanisms used by phishing.
Phishing remains an extremely effective method of attack, as techniques and pretexts invented by the attackers are constantly renewed. It should be noted that phishing is much more than email spoofing.
In addition to training, a social engineering audit provides the means to test the reflexes of the teams by carrying out attacks adapted to the context. Thanks to real-life situations, employees become more aware of the threats they face and will also better remember the risk situations.
