How Email Works

Email runs on a 1980s protocol that trusts senders to declare their own identity. Anyone can put any address in the From field, and most receiving servers will deliver the message anyway. This article covers why that design persists, what hidden information every email carries, and how to read the difference between what an email shows and what it actually is.

The Fake Invoice

Maya opened the email headers and started tracing the path.

Construction company controller had wired $127,000 to what she thought was their law firm. Closing costs on a property deal. The email looked right. Law firm domain in the From field. Signature matched. No typos, no suspicious links.

But the Received headers told a different story. First hop was a server in the Philippines. The From field said Patterson & Associates, their actual law firm in Chicago. Someone had just typed it in.

That's how email works. Anyone can put anything in the From field. It's like the return address on a postcard. Nobody checks if you actually live there. SMTP was first standardized in RFC 821 in 1982 and updated in RFC 5321 in 2008, but the core trust model never changed: it still accepts whatever From address the sender claims.

She pulled up the authentication results. SPF failed. DKIM failed. DMARC failed. Every check that could have caught this had caught it.

But the law firm's domain wasn't set up to enforce DMARC. Their policy was set to "none" - meaning even when emails fail authentication, deliver them anyway. The controller's mail server saw the failures and delivered the message anyway.

The controller had done nothing obviously wrong. The From address looked right. The content looked right. The only way to catch it was to check headers that most people don't even know exist.

Two days later, the real law firm called asking where their payment was. By then the money was gone.

This story is fictional, but the patterns are real.

Why can email be faked?

Email works like a postcard. You can write any return address you want. The postal service will still deliver it. They don't check if you actually live at that address.

The technology behind email, called SMTP, was first standardized in RFC 821 in 1982 for a network of a few hundred university computers. Everyone on the network knew each other. There was no reason to verify identity.

RFC 5321 (2008) refreshed the protocol and added features like SMTP AUTH and STARTTLS,^[1] but the core trust model never changed. SMTP still accepts whatever address the sender claims. Authentication systems were bolted on later, and they're optional. NIST SP 800-177 Revision 1 (February 2019) lays out how SPF, DKIM, DMARC, TLS, and S/MIME are supposed to fit together,^[2] but adoption is uneven and many organizations still don't enforce the policies they publish.

This is the core problem: email trusts the sender to tell the truth about who they are.

What You See vs. What's Real

When you look at an email, you see:

• From: who supposedly sent it
• To: who received it
• Subject: what it's about
• Body: the message itself

What you don't see is the email's headers. This hidden information shows where the email actually came from and how it traveled to reach you.

Think of headers like shipping labels on a package. The gift card inside might say "From: Grandma," but the shipping label shows it came from a warehouse in Nevada. Headers reveal the real origin.

Every email program can show you headers, but they're hidden by default. In Gmail, click the three dots and select "Show original." In Outlook, open message properties.

Which headers matter?

When you view headers, you'll see a wall of text. Here's what matters:

From: What the sender wants you to see. Can be anything.

Reply-To: Where your reply actually goes. Attackers set this to their own address while making "From" look legitimate. You think you're replying to your CEO, but your message goes to a criminal.

Return-Path: Where bounced messages go. Like Reply-To, this can differ from the From address. When all three point to different places, something suspicious is happening.

Received: Each server that handled the email adds one of these. Reading them bottom-to-top shows the email's journey. If an email claims to be from New York but the first Received header shows a server in Romania, something is wrong.

Authentication-Results: Shows whether the email passed security checks (SPF, DKIM, DMARC). We cover these in the next article.

Spam and Legitimate Email

Most email never reaches your inbox. Email servers filter billions of messages daily, blocking spam, phishing, and malware.

How filtering works:

Servers check the sender's reputation. Has this server sent spam before? Is the domain new? They analyze the content for suspicious patterns: urgency phrases, financial requests, known malicious links. They check whether the sender passes authentication.

Messages that fail these checks go to spam or get blocked entirely.

The filtering problem:

Filters aren't perfect. Legitimate emails sometimes land in spam. And sophisticated attacks can pass all checks.

Attackers with lookalike domains (arnazon.com instead of amazon.com) can set up proper authentication. Their emails pass technical checks because they really did come from the domain they claim. The filter can't know that domain is malicious.

Abuse reporting:

When fraudulent emails get through, reporting them helps. Most email providers have "Report phishing" or "Report spam" buttons. This trains filters and can get malicious domains blocked.

Organizations can also report email abuse to hosting providers. Most legitimate hosts will take down infrastructure used for fraud once notified.

Why does this matter for fraud?

Most fraud starts with email. Wire fraud, account takeover, credential theft, invoice scams. Business email compromise alone accounted for 21,442 complaints and $2.77 billion in adjusted losses reported to the FBI in 2024, second only to investment fraud by total dollars stolen.^[3] Understanding that email can be faked, and knowing where to look for the truth, is the foundation of investigating these attacks.

When someone forwards you a suspicious email asking "is this real?", you now know:

• The From address proves nothing
• Check Reply-To for mismatches
• Headers show the real origin
• Authentication results reveal whether it passed security checks

The next article covers those authentication checks in detail.

Key Takeaways

• Email was designed without security. SMTP dates to RFC 821 in 1982 and was refreshed by RFC 5321 in 2008, but its trust model still relies on senders to identify themselves honestly.
• Anyone can fake the From address. No technical skill required. Just type whatever address you want.
• Headers reveal the truth. Hidden metadata shows where an email really came from. Every email program can display them.
• Reply-To redirects your response. An email appearing to be from your CEO can route your reply to an attacker.
• Filters help but aren't perfect. Spam filtering blocks most junk, but sophisticated attacks with proper authentication can get through.

What's next: Email Authentication explains SPF, DKIM, and DMARC, the security checks that try to verify senders, and why they don't catch everything.

Key Terms

SMTP: Simple Mail Transfer Protocol. The system that sends email between servers, first standardized in RFC 821 (1982) and updated in RFC 5321 (2008).

Headers: Hidden metadata in every email showing its origin, path, and authentication status.

From: The displayed sender address. Can be set to anything by the sender.

Reply-To: Where replies go. Can differ from the From address.

Return-Path: Where bounced messages go. Can differ from the From address.

Received: Headers added by each server that handled the email. Read bottom-to-top to trace the path.

Spam filtering: Automated systems that block unwanted or malicious email based on reputation, content, and authentication.

References

1. RFC 5321 — Simple Mail Transfer Protocol↗ — J. Klensin, October 2008. Current SMTP specification; obsoletes RFC 821, 974, 1869, and 2821 and updates RFC 1123. SMTP defines mail transport but not sender authentication.

2. NIST SP 800-177 Revision 1: Trustworthy Email↗ — Rose, Nightingale, Garfinkel, Chandramouli, February 2019. Federal guidance on SPF, DKIM, DMARC, TLS, and S/MIME for trustworthy email.

3. FBI IC3 2024 Internet Crime Report↗ (pp. 9–10: Business Email Compromise reported 21,442 complaints and $2,770,151,146 in adjusted losses in 2024, the second-highest crime type by losses after Investment Fraud).