What is Email Spoofing and How Does It Work?

Here's something most people don't realise: anyone can send you an email that looks like it came from your bank, your boss, or the Prime Minister. No hacking required. No special tools. The protocol that powers every email you've ever sent was designed in 1982, and it has zero built-in sender verification.

Let me show you exactly how this works.

SMTP: The Post Office That Never Checks ID

When you send an email, your mail client talks to a server using a protocol called SMTP (Simple Mail Transfer Protocol). SMTP was defined in RFC 821 back when the internet was a few hundred academics who all trusted each other. Authentication wasn't a concern.

Here's what an SMTP conversation actually looks like when sending an email:

HELO mail.example.com
MAIL FROM: 
RCPT TO: 
DATA
From: John Smith 
To: [email protected]
Subject: Urgent - Wire Transfer Needed

Please process this payment immediately...
.
QUIT

See the MAIL FROM line? The sender just declares who they are. The receiving server doesn't verify it. It's like writing any return address you want on a paper envelope — the post office doesn't check whether you actually live there.

What makes this worse: there are actually two "from" fields. The MAIL FROM in the SMTP envelope (which most people never see) and the From: header in the message body (which your email client displays). They don't have to match. An attacker can set them independently.

What a Spoofed Email Header Actually Looks Like

Here's a simplified version of the headers from a spoofed email. Pay attention to the mismatches:

Return-Path: 
Received: from mail.throwaway-domain.com (185.234.xx.xx)
    by mx.yourcompany.com; Wed, 5 Feb 2025 09:14:22 +0000
From: "IT Support" 
Reply-To: [email protected]
Subject: Password Reset Required - Action Needed
Message-ID: 

Three red flags if you know where to look:

1. Return-Path shows throwaway-domain.com — the actual sending domain

2. Received header shows the email came from 185.234.xx.xx, an IP that has nothing to do with your company

3. Reply-To points to a Gmail address, not your company's domain

But your email client? It just shows: **From: IT Support **. That's all most people ever see.

SPF, DKIM, and DMARC — The Fixes (and Why They're Not Enough)

The internet community has bolted on three authentication mechanisms over the years. Here's what each one does in plain English:

SPF (Sender Policy Framework) is a DNS record that says "only these IP addresses are allowed to send email on behalf of my domain." When a receiving server gets an email claiming to be from yourcompany.com, it checks the DNS record to see if the sending server's IP is on the list.

The problem: SPF checks the envelope sender (MAIL FROM), not the From: header that humans see. An attacker can use their own domain in the envelope and spoof the visible From: header. SPF passes, the email looks spoofed.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to email headers. The sending server signs the message with a private key, and the receiving server verifies it using a public key published in DNS.

The problem: DKIM proves a message wasn't tampered with in transit and that a specific domain's server handled it. But the domain that signed it doesn't have to match the From: address. A perfectly valid DKIM signature from throwaway-domain.com doesn't stop the From: header saying yourcompany.com.

DMARC (Domain-based Message Authentication, Reporting & Conformance) ties SPF and DKIM together and adds a critical piece: alignment. It requires that the domain in the From: header matches either the SPF-authenticated domain or the DKIM-signing domain. If they don't align, DMARC fails, and the domain owner can specify what should happen: nothing (p=none), quarantine it, or reject it.

Here's the kicker: as of late 2023, over 80% of domains with DMARC records still use p=none — which means they're monitoring spoofing attempts but not actually blocking them. It's like having a security camera but leaving the door wide open.

And even with p=reject, DMARC doesn't protect against lookalike domains. yourcompany.com might have perfect DMARC, but nothing stops someone from registering yourcompanny.com or your-company.com and setting up valid SPF, DKIM, and DMARC on that fake domain.

What You Can Actually Do Right Now

If you own a domain (business owners, IT admins):

1. Check your DMARC policy. Run this in a terminal or use MXToolbox:

   dig txt _dmarc.yourdomain.com
   

   If it says p=none, you're not protected. Work toward p=quarantine and then p=reject. Yes, it takes some effort to make sure your legitimate emails still get through — but it's worth it.

2. Publish an SPF record that explicitly lists your mail providers and ends with -all (hard fail), not ~all (soft fail). The difference matters.

3. Enable DKIM signing on every service that sends email on your behalf — your email provider, marketing platform, CRM, invoicing system. Each one needs its own DKIM key in your DNS.

If you're a regular email user:

1. Learn to view email headers. In Gmail: open the email → three dots → "Show original". In Outlook: open the email → File → Properties → Internet Headers. Look for mismatches between the From: address and the Return-Path or Received headers.

2. Watch the Reply-To. If an email claims to be from your bank but the reply-to is a Gmail or Outlook address, that's a spoofed email.

3. Be suspicious of any email that creates urgency around money or credentials. Spoofed emails are only useful if they convince you to do something. The spoofing is the delivery mechanism; social engineering is the payload.

The Uncomfortable Truth

Email spoofing isn't going away. SMTP is too fundamental to replace, and the authentication mechanisms are opt-in, partially deployed, and have known gaps. The tools to send spoofed emails are freely available — you can do it with a basic Python script and the smtplib library in about 15 lines of code.

What's changing is detection. Modern email security doesn't just check SPF/DKIM/DMARC pass/fail — it analyses sending patterns, header anomalies, content signals, and behavioural indicators. A spoofed email that passes basic authentication checks can still be caught by looking at the full picture.