Why Email Spoofing happen and how can it be avoided?
Email spoofing happens because the SMTP protocol, that is used for sending emails, was originally designed in a way that it had no mechanism for authentication. It did not check whether the sender was authorized to send emails from the domain that it was using for sending the emails. To have a better understanding, we need to understand that how emails are usually sent over Internet.
Sending emails begin by email client submitting the email to email server, i.e. mail submission agent (MSA), using email transmission protocol – SMTP. MSA forwards the email to intermediate relay server, also known as Mail Transfer Agent (MTA). There are usually more than one MTAs between the email sender and the final receiver. The message transmission between multiple MTAs happen over SMTP, itself. The final hop, which receives the incoming message and is responsible for local delivery is the message delivery agent (MDA). Email is then retrieved by end user using Internet Message Access Protocol (IMAP) or Post Office Protocol (POP).
When message is transmitted from email client to MSA using SMTP, it happens over port 587. Port 587 is the default mail submission port. It ensures that MSA accepts the email only after authentication. But MTA servers are usually open mail relay servers that communicate over SMTP port 25. It allows anyone on the Internet to send email through it, not verifying if sender is authorized to send that email, leading to email spoofing.
To help in detecting and protecting against email spoofing, there are three key email authentication protocols that can be implemented.
1. Sender Policy Framework: SPF is an email authentication protocol that allows the sender domain to define who is authorized to send email on its behalf. It also lets the email receiver to verify if the email is received through an authorized party. The mail sender lists the IP addresses, in TXT RR in the zone file of their DNS, that are authorized to send email on behalf of their domain.
Note: SPF record look up the domain included in the “envelope from” address within the hidden technical header of the email and not “from” address, the one we see in the visible header.
Evaluation of SPF can result in any of these values:
Pass – The SPF record designates the host to be allowed to send
Fail – The SPF record has designated the host as NOT being allowed to send.
SoftFail – The SPF record has designated the host as NOT being allowed to send but is in transition.
Neutral – The SPF record specifies explicitly that nothing can be said about validity.
None – The domain does not have an SPF record, or the SPF record does not evaluate to a result.
PermError – A permanent error has occurred (e.g. badly formatted SPF record).
TempError – A transient error has occurred.
Despite undeniable benefits of implementing SPF, there are certain limitations as well, of which we should be aware of:
SPF does not protect from spoofing of the “header from” address, which is visible to users, and more likely to be spoofed by cybercriminals.
SPF records may not always be updated.
SPF only informs about the delivery decision and not block the message itself.
SPF breaks, if email is forwarded.
2. DomainKeys Identified Mail: DKIM provides a method for email sender to take the responsibility of the transmitted message by digitally signing it. The sender first chooses the header fields like “from” address, subject, body and other fields that it wants to sign. The sender will then create a hash of those chosen fields, and then encrypt them with the private key that only it has access to. The signer’s public key will be published in DNS, which will be used by the recipient for verification.
This way, DKIM helps to validate the integrity of the message sent. Like SPF, DKIM also has its own limitations. Since DKIM requires cryptographic checksums for each message, it results in additional overhead. Moreover, DKIM helps to identify forged email addresses but it still does not prevent cybercriminals from spoofing the email headers.
3. Domain-based Message Authentication, Reporting and Conformance: DMARC is an email authentication and reporting protocol. It builds on SPF & DKIM, defines policy on what action to be taken for the emails that fail authentication and how senders can be reported about them.
To pass DMARC, an email should pass SPF and DKIM checks. Email will pass SPF check when visible “from” address domain matches “envelope from” address domain and DKIM check when “from” address domain matches “d=domain name” in signature.
If an email fails DMARC, receivers can be instructed to follow any of the below actions as per defined DMARC policy.
None (take no action but only monitor)
Quarantine (move to spam folder)
Reject (don’t deliver the email at all)