Introduction​

One of the most common misconceptions in IT is:


The truth is that email was designed long before modern security expectations existed. SMTP (Simple Mail Transfer Protocol) was created in the early 1980s when the Internet was largely based on trust. Because of this, email addresses are surprisingly easy to fake.

Modern protections such as SPF, DKIM, and DMARC were added later to help verify the legitimacy of messages.

This article explains:

• How email spoofing works
• How to read email headers
• What SPF, DKIM, and DMARC actually do
• How to identify the real sender
• What indicators should be trusted during investigations

---

How Email Spoofing Works​

Consider a physical letter.

Anyone can write this on the envelope:


The postal service does not verify whether the sender actually lives there.

SMTP originally worked in a similar manner.

A sending server can literally say:


And inside the email:


Originally, receiving mail systems simply accepted this information without verifying ownership of the domain.

As a result:

The visible From address is not proof that the message actually came from that sender.

---

SPF (Sender Policy Framework)​

SPF answers one question:


Example DNS record:


This tells the world:


When a message arrives claiming to be from:


The receiving system checks:

• What server actually sent the message?
• Is that server authorized by the SPF record?

Possible results:


Easy way to remember SPF:

---

DKIM (DomainKeys Identified Mail)​

DKIM works differently.

Instead of validating the sending server, DKIM validates the message itself.

The sending system cryptographically signs the email.

Headers may contain:


The receiving server retrieves the public key from DNS and verifies the signature.

This confirms:

• The message was authorized by the domain.
• The message was not altered after being sent.

Possible results:


Easy way to remember DKIM:

---

DMARC (Domain-based Message Authentication, Reporting and Conformance)​

DMARC is the policy layer.

It answers the question:


Example:


Possible policies:

• p=none = Monitor only
• p=quarantine = Send suspicious mail to Junk/Spam
• p=reject = Reject the message outright

Easy way to remember DMARC:

---

The SPF / DKIM / DMARC Cheat Sheet​

Or even simpler:

---

How to Read Email Headers​

When investigating email, most people immediately look at:


Unfortunately, these are often the least trustworthy fields.

Instead, focus on:

• Received
• Authentication-Results
• Return-Path
• Sender
• Message-ID

---

Received Headers​

Received headers document every hop the email took.

Example:


The actual path was:


NOT:


Important:

Read Received headers from the bottom up.

The lowest Received header is generally closest to the true origin of the message.

---

Authentication-Results​

This is often the fastest way to understand whether Microsoft trusted the message.

Typical examples:


Good sign.

Or:


Very suspicious.

When available, Authentication-Results should be one of the first headers reviewed.

---

Sender vs From vs Return-Path​

This is one of the most useful concepts to understand.


Example:


That mismatch should immediately raise suspicion.

In many phishing investigations, the Sender and Return-Path fields reveal far more than the visible From address.

---

Case Study: Your-Company-Name Phishing Email​

Interesting header:


This tells us:

• The email travelled through SendGrid infrastructure.
• The email did not originate from Microsoft Teams.
• The email was delivered to Microsoft 365 through SendGrid.

Another important finding:


Visible sender:


Actual sending entity:


That discrepancy is a major red flag and should immediately prompt further investigation.

---

What Headers Should You Trust?​

Generally Trust:

• Received
• Authentication-Results
• SPF Results
• DKIM Results
• DMARC Results
• Return-Path
• Sender
• Message-ID

Do Not Trust By Themselves:

• Display Name
• Visible From Address
• Subject Line
• Company Branding
• Email Signatures
• Logos
• Microsoft Teams Branding

Anyone can create an email that says:


None of these prove legitimacy.

---

Common Investigation Process​

When reviewing a suspicious email:

1. Confirm the recipient.
2. Review the From field.
3. Review the Sender field.
4. Review the Return-Path.
5. Read Received headers from bottom to top.
6. Review Authentication-Results.
7. Check SPF results.
8. Check DKIM results.
9. Check DMARC results.
10. Review embedded URLs.
11. Review Message-ID.

If the visible sender claims to be:


but you find:


or


the email is likely spoofing or impersonating another sender.

---

Quick Reference / Memory Aid​

When you inevitably forget all of this while reviewing an email for legitimacy, just remember:


And remember:

The From address is what the sender wants you to believe. The headers tell you what actually happened.

Likely with enough troubleshooting and experience, you'll eventually stops trusting the From field. And that's usually when email investigations finally start making sense.[/I]