The core email protocols do not have any mechanism for authentication, making it common for spam and phishing emails to use such spoofing to mislead or even prank the recipient about the origin of the message.
When a Simple Mail Transfer Protocol (SMTP) email is sent, the initial connection provides two pieces of address information:
- MAIL FROM: - generally presented to the recipient as the Return-path: header but not normally visible to the end user, and by default no checks are done that the sending system is authorized to send on behalf of that address.
- RCPT TO: - specifies which email address the email is delivered to, is not normally visible to the end user but may be present in the headers as part of the "Received:" header.
Together these are sometimes referred to as the "envelope" addressing – an analogy to a traditional paper envelope. Unless the receiving mail server signals that it has problems with either of these items, the sending system sends the "DATA" command, and typically sends several header items, including:
- From: Joe Q Doe <firstname.lastname@example.org> - the address visible to the recipient; but again, by default no checks are done that the sending system is authorized to send on behalf of that address.
- Reply-to: Jane Roe <Jane.Roe@example.mil> - similarly not checked
- Sender: Jin Jo <email@example.com> - also not checked
The result is that the email recipient sees the email as having come from the address in the From: header. They may sometimes be able to find the MAIL FROM address, and if they reply to the email it will go to either the address presented in the From: or Reply-to: header, but none of these addresses are typically reliable, so automated bounce messages may generate backscatter.
Although email spoofing is effective in forging the email address, the IP address of the computer sending the mail can generally be identified from the "Received:" lines in the email header. In malicious cases however, this is likely to be the computer of an innocent third party infected by malware that is sending the email without the owner's knowledge.
Malicious use of spoofing
Email spoofing has been responsible for public incidents with serious business and financial consequences. This was the case in an October 2013 email to a news agency which was spoofed to look like it was from the Swedish company Fingerprint Cards. The email stated that Samsung offered to purchase the company. The news spread and the stock exchange rate surged by 50%.
Malware such as Klez and Sober among many more modern examples often search for email addresses within the computer they have infected, and they use those addresses both as targets for email, but also to create credible forged From fields in the emails that they send. This is to ensure that the emails are more likely to be opened. For example:
- Alice is sent an infected email which she opens, running the worm code.
- The worm code searches Alice's email address book and finds the addresses of Bob and Charlie.
- From Alice's computer, the worm sends an infected email to Bob, but is forged to appear as if it was sent by Charlie.
In this case, even if Bob's system detects the incoming mail as containing malware, he sees the source as being Charlie, even though it really came from Alice's computer. Meanwhile, Alice may remain unaware that her computer has been infected.
In the early Internet, "legitimately spoofed" email was common. For example, a visiting user might use the local organization's SMTP server to send email from the user's foreign address. Since most servers were configured as "open relays", this was a common practice. As spam email became an annoying problem, these sorts of "legitimate" uses fell out of favor. An example of legitimate spoofing would be a scenario where a Customer relationship management system receives an email from a website, and in order to log the incoming email and create a profile for the email that is associated with a new contact, the system would be configured to use the 'sender' of the email to create the profile of the prospect with a name and email address of the sender. A dispatching website would be configured to spoof the outgoing email from the website, and dispatch the email in a way which makes it appear to arrive from the submitter with the submitter's information as sender name and email address. The system would then log it as configured.
When multiple software systems communicate with each other via email, spoofing may be required in order to facilitate such communication. In any scenario where an email address is set up to automatically forward incoming emails to a system which only accepts emails from the email forwarder, spoofing is required in order to facilitate this behavior. This is common between ticketing systems which communicate with other ticketing systems.
The effect on mail servers
Traditionally, mail servers could accept a mail item, then later send a Non-Delivery Report or "bounce" message if it couldn't be delivered or had been quarantined for any reason. These would be sent to the "MAIL FROM:" aka "Return Path" address. With the massive rise in forged addresses, best practice is now to not generate NDRs for detected spam, viruses etc. but to reject the email during the SMTP transaction. When mail administrators fail to take this approach, their systems are guilty of sending "backscatter" emails to innocent parties - in itself a form of spam - or being used to perform "Joe job" attacks.
The SSL/TLS system used to encrypt server-to-server email traffic can also be used to enforce authentication, but in practice it is seldom used, and a range of other potential solutions have also failed to gain traction.
However a number of effective systems are now widely used, including:
To effectively stop forged email being delivered, the sending domains, their mail servers, and the receiving system all need to be configured correctly for these higher standards of authentication. Although their use is increasing, estimates vary widely as to what percentage of emails have no form of domain authentication: from 8.6% to "almost half". For this reason, receiving mail systems typically have a range of settings to configure how they treat poorly-configured domains or email.
- Email authentication – Techniques aimed at providing verifiable information about the origin of email messages
- Sender Policy Framework – Simple email-validation system designed to detect email spoofing (SPF)
- Computer virus – Computer program that modifies other programs to replicate itself and spread
- Computer worm – Malware
- Hoax – Deliberately fabricated falsehood made to masquerade as the truth
- Chain letter – Letter written in succession by a group of people
- Joe job – A spamming technique that sends out unsolicited e-mails using spoofed sender data
- Website spoofing – Creating a website, as a hoax, with the intention of misleading readers
- Prank call
- Siebenmann, Chris. "A quick overview of SMTP". University of Toronto. Retrieved 2019-04-08.
- Barnes, Bill (2002-03-12). "E-Mail Impersonators". Retrieved 2019-04-08.
- "e-mail impersonators: identifying "spoofed" e-mail". Archived from the original on 2017-06-21. Retrieved 2019-04-08.
- "Fraudsters' fingerprints on fake Samsung deal". Retrieved 2019-04-08.
- See RFC3834
- "Transport Layer Security for Inbound Mail". Google Postini Services. Archived from the original on 2016-11-11. Retrieved 2019-04-08.
- Bursztein, Elie; Eranti, Vijay (2013-12-06). "Internet-wide efforts to fight email phishing are working". Google Security Blog. Retrieved 2019-04-08.
- Eggert, Lars. "SPF Deployment Trends". Archived from the original on 2016-04-02. Retrieved 2019-04-08.
- Eggert, Lars. "DKIM Deployment Trends". Archived from the original on 2018-08-22. Retrieved 2019-04-08.
- "In First Year, DMARC Protects 60 Percent of Global Consumer Mailboxes". dmarc.org. 2013-02-06. Retrieved 2019-04-08.
- "Prevent spoofed messages with spoofed senders detection". Retrieved 2019-04-08.
- "Anti-spoofing protection in Office 365". Retrieved 2019-04-08.
- "2002 Tech Tip: Spoofed/Forged Email". SEI Digital Library. Carnegie Mellon University. 2002-01-01. Retrieved 2019-12-19.