What are the various kinds of email spoofing? What are the security controls on your email platform to sprevent email fraud and impersonation due to email spoofing? Read on.
Business v/s Consumer Email Accounts (M) 2013-2017
Source : radicati.com
Worldwide daily email traffic (B) 2013-2017
While the % of growth in the consumer and business email accounts is about the same year on year, it is observed that the the business email traffic will exhibit growth year on year (more business transacted on email), while consumer email traffic will reduce (possibly due to social media).
Source : radicati.com
Global Spam Statistics
Source : Statista
What is ’email spoofing’?
Spoofing, in a nutshell, is email fraud and deception. Spoofing is the most common form of the modern con game called ‘phishing’. The email spoofer is a spammer attempting to hide his true identity, impersonating someone else, and trying to “phish” or lure you to reveal your passwords, login names and other personal and financial information.
Why Would Someone Fraudulently “Spoof” an Email?
Email spoofing may occur in different forms, but all have a similar result: a user receives an email that appears to have originated from one source when it actually was sent from another source.
Email spoofing is often an attempt to trick the user into making a damaging statement, releasing sensitive information (such as passwords) and/or performing a financial transaction.
Examples of email spoofing
- An Email claiming to be from a system administrator (and also appearing so) requesting users to change their passwords to a specified string and threatening to suspend their account if they do not do this.
- A mail claiming to be from a person in authority requesting users to send them a copy of a password file or other sensitive information.
- Receiving an Email from a partner, requesting for funds transfer pertaining to a sale or transaction.
Email spoofing can be done by one of the valid users on a domain or users on external domains. Lets look at some common scenarios of how spoofing is done and how it can be prevented.
To explain the scenarios, lets take an example: Ravi and Smita are colleagues in the same organisation and Ravi sends a mail on behalf of Smita (Ravi has spoofed Smita’s email id)
Email spoofing type 1: Ravi hacks into Smita’s email box:
Ravi could do this since she has a weak password and the email system doesn’t have any password security in place e.g. password history, account lockout, password age, etc and was able to send a mail on Smita’s behalf. In this scenario the mail has gone from Smita’s account, but she is unaware of it.
This situation can be easily prevented if the following security policies are in place for each account:
- Strict Password Policies to ensure complex password, regular password rotation, automatic account lockout on several unsuccessful attempts and always fresh passwords by referring to the password history.
- Access control to define which services the user can access and the trusted network ranges from which the user can access the server.
- Mail Policies to control whereall each user can send mail and under what condition.
- Every mail send request requires authentication by the a valid sender in the network
Email spoofing type 2: Ravi impersonates Smita:
Ravi connects to the organisation mail server, authenticates using his own account but sends a mail containing Smita’s email id in the “From ID” header. When the recipient gets this mail, it appears to have been sent from Smita’s email id. This is possible with mail servers which have a weak authorisation system.
This can be prevented by applying the following security policies for each account
Email Spoof Check: This means that if Ravi is authenticating then the mail should also contain ONLY Ravi’s email id in the “From ID” field. If the authentication ID and the From ID don’t match, the mail will be rejected.
Domain Spoof check: This means that, this server will only allow mail FROM domains authorised to relay mail from here. In other words, for the server to acccept any request to send mail, the envelop Sender ID and the From ID field in the mail should have email ids only from one the authorised listed domains. This check prevents clients and other servers from sending mail FROM foreign domains (open relay) in case of any compromise.
Email spoofing type 3: Ravi impersonates Smita from an external mail system:
Using an Open relay
Ravi sends a mail to the recipient on Smita’s behalf but by using an external mail server or mail sending tool. In this method, Ravi sends a mail using a tool and using the services of an open relay server on the Internet or by creating his own server. He composes the mail and sets Smita’s email address in the mail header (MIME structure).
Modern mail servers and mail landing services, now easily detect this by
IP reputation of sender: The IP of the server from which the mail originates should belong to the sender’s domain as designated by the Sending organisation in the SPF record in the DNS. Hence, while Ravi will succeed in sending the mail, the recipient server will reject the mail in all likelihood due to bad IP reputation.
In case the recipient mail server doesn’t have strong policies, it may accept the mail and deliver it to the recipient and the mail may appear that it came from Smita. On closer inspection of the mail, it is possible for the recipient to determine that it is a spoof however, but this needs technical expertise of understanding mail headers.
Changing the display name on a public email platform
Another way Ravi can do this is to simply change the display name of his email id on whatever email solution he is using and send a mail to Smita. In this case, the email is a legitimate email from a valid email service, with a display name matching Ravi. So actually this is not a spoof mail at all. It’s simply a mail from a person whose name matches the name of one of the people Smita knows. This is perfectly legit and cannot be blocked at any level.
Email spoofing type 4: In transit modification of mail:
Normally mail can sniffed in transit (i.e. the contents can be read) and modified at hop points by mail administrators if they have the privilege. Under normal working conditions these are rare situations.
Ensure that the following practices are followed to bring the chance of this happening to near zero
SSL/TLS: All access to services happens over secure encrypted layer. This means that all the data flow from client to server and server to server is encrypted over SSL/TLS.
Use SPF, DKIM, and DMARC for mail SENT from your domain to prevent outbound email spoofing
Besides the mail security controls described above, there are 3 more powerful and effective ways to control impersonation, email spoofing and email fraud for your email domain as described below:
1. Sender Policy Framework (SPF)
The Sender Policy Framework (SPF) record enables a domain to publicly state which servers may send emails on its behalf.
You’ll need to add/modify DNS records of type ‘TXT’ via your domain registrar, or DNS provider, for your organisation’s domain to mention that the emails of your domain are being sent via Mithi SkyConnect servers.
Please refer to this topic to know what changes to make in your DNS records to enable SPF for your domain
This record will help protect your domain from attackers/spammers who send emails (on your behalf without your knowledge) with spoofed headers and will add more legitimacy to your sent emails.
2. Domain Keys Identified Mail (DKIM)
Domain Keys Identified Mail (DKIM) is a method of email authentication that cryptographically verifies if an email is sent by authorized servers and has not been modified during transit.
During onboarding, our team will request your approval to enable DKIM for your domain and provide you with the content of the TXT record to be added to your domain’s DNS zone.
Even if you don’t enable this during onboarding, you can do it any later point in time by simply reaching out to our support desk.
This record will help the recipient verify the integrity of the email and also confirm the source.
3. Domain-based Message Authentication, Reporting, and Conformance (DMARC)
Now after verifying the email’s source using SPF and DKIM, the question is what should a receiving server do if it gets an email which failed these checks.
This is where Domain-based Message Authentication, Reporting, and Conformance (DMARC) comes in by allowing the domain owner to specify what should happen with failed checks as well as get feedback/reports.
When you opt to enable DKIM for your domain, our team will give you the content for DMARC TXT record as well, which you will have to add to your domain’s DNS Zone.
Use SPF, DKIM and, DMARC for mail RECEIVED by your domain to check inbound email spoofing
The above section described how you can help your recipients identify mail of your domain accurately by setting up SPF, DKIM and, DMARC in your domain’s DNS zone.
This section describes how you as a recipient can enable tighter sender verification by enabling these checks on our inbound email gateways. Our gateway security engine at the periphery has options to check SPF, DKIM and DMARC records of all senders to your domain.
During onboarding, we only enable the SPF check and will ask your approval to enable DKIM and DMARC.
By default, if an inbound mail fails these checks, the action taken will be determined by the owner of the sender’s domain via their DMARC record. Typically, most owners configure this for quarantine, meaning mail failing these checks will be marked as spam and quarantined for your user’s review.
Data leak prevention with SkyConnect – Critical to your security strategy