Email spoofing is the creation of emails with a forged sender address. Because core email protocols lack authentication, phishing attacks and spam emails can spoof the email header to mislead the recipient about the sender of the email.
The goal of email spoofing is to get recipients to open, respond and engage with the email message. Email spoofing can greatly increase the effectiveness of phishing and other email-based cyber attacks by tricking the recipient into trusting the email and its sender. While spoofed emails require little action beyond removal, they are a cybersecurity risk that needs to be addressed.
For example, phishing attacks used in business email compromises (BEC) may purport to be from the CEO or CFO of your organization and request a wire transfer be sent to a supplier in a foreign country. Spoofing emails or impersonation attacks can also be used by cybercriminals to gather sensitive information such as credit card numbers and personal information for identity theft.
Why is Email Spoofing Possible?
Email spoofing is possible because Simple Mail Transfer Protocol (SMTP) does not provide an authentication method. Today email address authentication protocols exist to combat email spoofing. However, their adoption has been slow.
What are the Reasons for Email Spoofing?
There are several reasons cybercriminals may spoof a sender address including:
- To hide the email sender's true identity: This can also be achieved by registering an anonymous email address, but it is generally used as part of another cyber attack or scam.
- Avoid spam blacklists: Spammers will use spoof email addresses to avoid spam filters. This risk is mitigated by the fact you can blacklist specific IP address or ISPs.
- Pretend to be a trusted person: Scammers use email spoofing to pretend to be a friend or colleague asking you to lend them money.
- Pretend to be a trusted organization: Spoofed emails from financial institutions can lead to phishing pages designed to gain access to bank accounts and credit card numbers.
- To tarnish the reputation of the sender: Email spoofing can be used to tarnish the reputation of an organization or person.
- To commit identity theft: The attacker can request access to personally identifiable information (PII) by pretending to be using the victim's email account.
- To spread malware: By spoofing the email address, the recipient is more likely to open the email and any attachment that could contain a type of malware like ransomware such as WannaCry. This is why anti-malware software and network security are an important part of any cyber security strategy.
- As part of a man-in-the-middle attack: Cyber criminals may use email spoofing as part of a sophisticated man-in-the-middle attack designed to capture sensitive information or trade secrets from your organization as part of corporate espionage.
- To gain access to your sensitive information from third-party vendors: Email security must be part of your vendor risk management and third-party risk management framework. If your vendors have access to customer data, it's as important for them to prevent email spoofing as it is for you. Email spoofing is a third-party risk and fourth-party risk.
How to Stop Email Spoofing
While Simple Mail Transfer Protocol (SMTP) lacks authentication, there are now several frameworks designed to authenticate incoming emails:
- Sender Policy Framework (SPF): SPF checks whether a certain IP address is authorized to send email from a given domain name. SPF can lead to false positives and requires the receiving server to check an SPF record and validate the sender. Implementing SPF requires publishing new DNS records.
- Domain Key Identified Mail (DKIM): DKIM uses a pair of cryptographic keys that sign outgoing messages and validate incoming messages. However, DKIM is only used to sign specific pieces of a message, allowing messages to be forwarded without breaking the validity of the signature. This is known as a replay attack. Like SPF, DKIM requires publishing new DNS records.
- Domain-Based Message Authentication, Reporting, and Conformance (DMARC): DMARC gives the sender the option to let the receiver know it is protected by SPF or DKIM and what to do when mail fails authentication. As with SPF and DKIM, DMARC relies on DNS records.
- Sender ID: Sender ID is an anti-spoofing proposal from the MARID IETF working group that tried to join SPF and Caller ID. It is heavily based on SPF with a few improvements namely verifying message headers that indicate the claimed sender, rather than just the MAIL FROM: address.
- SSL/TLS: In practice, the SSL/TLS system can be used to encrypt server-to-server email traffic and enforce authentication but in practice is seldom used.
Further, email providers and email clients like Google's Gmail and Microsoft's Outlook have in-built email security that detects and alerts users of potential spam and email spoofing. If your email service flags something as spam or a phishing attempt, there is a good chance it is correct.
That said, be aware that legitimate emails can fail one or more of these checks. This could be because someone failed to configure something correctly or their email was incorrectly manipulated.
The key risk to these frameworks is their reliance on DNS. An attacker could gain access to a sender's DNS and send spoofed emails that look legitimate even to SPF, DKIM and DMARC checks. This is why DNSSEC, preventing domain hijacking and cybersecurity awareness training are important.
How to Use Sender Policy Framework (SPF)
Senders enable SPF for their domain by creating at least one DNS TXT record. When creating the SPF record, you need to have which email servers you want to use and their public IP addresses.
An SPF record may look like this:
com. IN TXT "v=spf1 -all"
com. IN TXT "v=spf1 a ip4:192.168.1.1. -all"
How to Use Domain Key Identified Mail (DKIM)
DKIM is harder to set up than SPF. It requires a modification to the sender's email server. The sender creates a cryptographic public/private key pair, installs it on their email server and then creates a DNS TXT record that contains their public key.
Each outgoing email is signed by the private key allowing receivers to verify the authenticity of the email by using the public key.
A DKIM DNS TXT record may look like this:
How to Use Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
DMARC can show whether the sender uses SPF and DKIM and how the sender recommends the receiver treats failed/spoofed emails that claim to be from the sender's domain. Like SPF and DKIM, DMARC is set up in DNS as a TXT record by the sender.
A DMARC DNS TXT record may look like this:
TXT IN "v=DMARC1;p=reject;pct=100;rua=mailto:dmarccheck@example.com;"
The p field indicates how the sender wants receivers to treat spoofed emails. P can be one of three values:
- None: No special treatment for failed emails
- Quarantine: Treat as suspicious, e.g. send to spam
- Reject: Reject emails at the server before it gets to the email client.
While reject may seem the most logical, it is recommended to use quarantine as legitimate emails can fail DMARC checks for a variety of reasons.
How Does Email Spoofing Work?
When a Simple Mail Transfer Protocol (SMTP) email is sent, the initial connection provides two pieces of address information:
- MAIL FROM: Presented to the recipient as the Return-path: header but not normally visible to the end user. By default, no checks are performed to authorized the authenticity of the address.
- RCPT TO: Specifies which email address the email is delivered to and is not normally visible to the end user but may be present in the headers as part of the Received: header.
Together, these are referred to as the envelope addressing, an analogy to traditional paper envelopes. It is up to the receiving email server (rather than the sender) to signal there is a problem with the envelope addressing.
Unless the receiving email server signals there is a problem, the sending system will send the DATA command with several header items including:
- FROM: Jane Doe <janedoe@example.com>, email programs show this to the recipient, but no default checks are done that the sending system is authorized to send from the address.
- REPLY-TO: Jane Doe <janedoe@example.net>, also has no default checks.
The result is the email recipient sees the email coming from the address in the FROM: header and if they reply to the email it will either go to the address in the FROM or REPLY-TO: header. The problem is none of these addresses are authenticated and can be spoofed.
The IP address of the sender is one way to identify an email as a cyber threat if the IP address is known to be malicious as it is accessible in the RECEIVED: header. However, third-parties infected by malware can often send the email without the owner's knowledge.
