1/ Basic email term

MUA (Mail user agent): Client application running on the computer used to send and receive email. (Example: Microsoft Outlook)
MTA (Mail Transfer Agent): Accepts messages from a sender and routes them along to their destinations. (Example: Microsoft Exchange)
MDA (Mail Delivery Agent): Responsible for final delivery of the email to the recipient's inbox.
SMTP (Single Message Transfer Protocol) / IMAP (Interactive Message Access Protocol) / POP3 (Post Office Protocol) are protocols for the MUA to be able to communicate with the MTA. SMTP is used to send the email.
POP3 or IMAP is used to received the email, the main difference between those two protocols is that the POP protocol download the email in the client, without having a backup of the file in the mail server. IMAP, since there is a continue connexion between the client and the server, when you retrieve a file from the server, you get a copy of the email.

SPF (Sender Policy Framework): Defines a mechanism by which a company can specify a server or a list of servers that are allowed to send email on behalf of their domain. If an email fails an SPF check, it can be an easy mechanism we can use to detect spam.
The SPF record is published by the DNS information as a TXT record type. In this example, it shows us the TXT record for google.com. The SPF-record for google.com is "v=spf1 include:_spf.google.com ~all" ~all: Reject all email if the sender does not belong to the ip address present in the SPF record. Let's dig a little bit deeper. By doing this, we find out there are more spf included, all those spf can send email on behalf of google.com. Let's dig a bit deeper again dig _netblocks.google.com txt +short (and all the variants as well) give us the list of ip addresses that are allowed to send an email on behalf of google.com.

DKIM (Domain Keys Identified Mail): Provides a cryptographic method of verifying a received email actually originated from the sending domain. We can use this to detect forged senders and spam.
We can find the DKIM information in the DNS information. The domain will generate a public/private key and publish the public key in the TXT record of DNS information. Mail server which send the email on behalf of a domain will encrypt the mail with the private key. This can be considered as the signature of the email. When the recipient will receive the email, he will decrypt the email to read the mail DMARC (Domain-based Message Authentication, Reporting & Conformance) is a extension of SPF and DKIM. Actions taken if it doesn't match SPF and DKIM such as reject all the email which doesn't have a valid SPF and a valid DKIM.

2/ Email analysis

A. Legitimate email

This is the email that we are going to analyze: Received header: There are several received headers, the top one is closer to the destination and the bottom one is closer to the source. In this screenshot, we have some interesting information, we know where it comes from, who received it, and the ip address of the sender. We would like to know who own this ip address. 17.179.250.121. Since the ip address belongs to Apple, it shows more confidence than an email not coming from a Apple ip address. DKIM-Signature V = version of the DKIM
A = encryption method
D = domain sender
S = selecter
T = timestamp (epoch time)
Bh = bodyhash (encoded in b64)
B = DKIM signature, calculated based upon the header fileds specified in the h= tag, as well as the bh field
On the screeshot above, the domain sender is insideapple.apple.com, an apple email sent by apple.com is better than an apple email sent by X.com.

Message-ID: It is a unique identifier, therefore if this message-id has been found before, it might lead to a forgery email. According to RFC 5322, the message-id has to be globally unique. But the structure is not unique, different hosts can generate different message-id. Also if the message-id is sent by a mail server but the message-id format is not the format used by the mail server, it can be a forgery. Return-path, Also known as the evelope sender address or bounce address but not the same as the "from" address. Therefore if the return-path is similar as a recipient address, it might be a forged message. X-header Mail providers can create a X - header and provide some good information. Sometimes show the name of the organization, the ip address of the system sending the email (X - originated - IP).

B. Phishing email

Here is another email, more suspicious than the previous one, the format is quite different and less professional, but let's analyze it and compare it to the legitimate one. Starting by the bottom (which means that we are closer to the source), by looking at the received header, we found no apple information. I'm confident that apple will not use rosepointeapartments.com to send their email. Received-spf does not present any information. However, we've seen that apple.com does have spf, which is very suspicious. Let's check Apple SPF to see if there is the ip address of rosepointeapartment.com. If not, it is probably a phishing email. Since there isn't 50.200.243.68 in the list of ip addresses allowed to send email on behalf of apple.com, we can conclude that this is not a legitimate sender from apple.com. Let's check the DNS record of the suspicious email: dig 1.1.1.1 rosepointeapartments.com mx As we can see in the screenshot of the DNS record, there is nothing related to apple, the mail servers are smx1.web-hosting.com, smx2.web-hosting.com, smx3.web-hosting.com. By looking at the DKIM information, we see that the message has not been signed. The message-id format also looks different from the apple message-id format and also reflect a non apple domain. Regarding the Return-Path, we can clearly see that does not belong to apple bounce address.

3/ Conclusion

In this article, you have seen the difference between a legitimate email and a fake one. Obviously, some adversaries might craft fake one which does exactly look like an original one, and sometimes it is really difficult to distinguish between a legitimate and a fake one. I wanted to show you, how you can investigate on a not legitimate email by using the email header when you have received a suspicious email. The email header give crucial information to determine the origin of the email and can prove that the email you have received is not a legitimate one.