A Practical Guide From Theory To Concrete Protection Measures.

Spoofing is a social engineering attack technique where an attacker is using a forged sender and/or return email address to trick a victim into interacting with a malicious message. 

The attacker can forge parts or all components of an email headers such as the From, Return-Path, and Reply-To fields so that the email appears to stem from a trusted source. Spoofing aims at stealing sensitive information, manipulate users, spread malware or commit financial fraud.

Noteworthy: Spoofing involves faking an identity to appear as a trusted source to the victim. On the other hand, Phishing manipulate users to steal data or money. Spoofing is a method to enable attacks while phishing is the attack itself, often using spoofing.

The Fundamentals

In a prosaic scenario, spoofing changes the email domain of a legitimate sender. See below example:

From: Amazon Support <[email protected]>
To: [email protected]
Subject: Urgent: Your Account is on Hold!

Hello John,

We’ve detected suspicious activity on your Amazon account. To avoid suspension, you must verify your payment information immediately by clicking here: http://amazon-security-verify.zyx/login

If you do not act within 24 hours, your account will be permanently closed.

Sincerely,
The Amazon Security Team

This is the most classical email spoofing scenario. Here’s what’s actually happening:

1. An email client (Gmail, Outlook, thunderbird etc.) receives an email and displays the sender address following the instructions in the header.

Example of a fake and genuine email address in Outlook. Source.

2. The display name “Amazon Support” is correct but the actual email address in the “From” header is not from a real Amazon domain. 

3. The email body will usually contain a link leading to a suspicious and actually fake Amazon website.

4. The tone of the message will generate a sense of urgency to incite the victim into a rabbit hole cascade of prompt and imprudent actions. 

5. The cybercriminal is using an email-sending tool (e.g., Gophish, an open-source phishing toolkit designed for security awareness testing or Swaks, the “Swiss Army Knife for SMTP”) or a Python script/CLI (e.g., by using the smtplib library) to stage the attack. The attacker is also hiding the IP address from where the forged email was sent.

This manipulation is possible due to the weakness (lack of built-in sender verification or authentication) of common emails protocols like SMTP (Simple Mail Transfer Protocol). This protocol was designed decades ago and long before the current and complex threat landscape. This is the reason why the “From:” header can be falsify so easily (the SMTP Mail FROM command can virtually contain any address).

Historically, many mail servers also permitted open relays through them. Third party servers could be used to transit spam and spoofed messages and to mask the true origin of the emails. The communication used to be plain-text and unless TLS was enforced, the message could be intercepted and/or altered. Eventually man-in-the-middle attackers were able to modify headers or inject additional recipients and get along with it unpunished.

Defence against Spoofing

The best defence for senders and workers is to implement SPF, DKIM and DMARC records for a given domain. For recipients, the best defence is a combination of common sense (staying vigilant, verifying suspicious messages with colleagues, friends, relatives, upper management,..) and applying efficient technical controls (enabling spam filtering, analysing unusual request contents for grammar typos and inconsistencies, hovering over links and using tools like Virustotal to scan URLs, detecting suspicious attachments, implementing MFA, running Security Awareness Training for your workforce..).

Below is a list of the core technologies used in tandem to prove that an email is legitimate, that the sender is authentic and protecting against spoofing and phishing:

1. SPF (Sender Policy Framework): It is a DNS record that exhibits the list of servers authorized to send messages on behalf of your domain. It validates the sending IP. As such, it is similar to a guest list to a party. Not on the list, no email authorized by the bouncer (the receiving mail server) and the email is rejected or marked as suspicious.

2. DKIM (DomainKeys Identified Mail): It is a encrypted hashed signature inserted in the header of the outgoing email. It acts as a tamper-proof seal on a brand new shipping-box by a website vendor. 

The recipient is capable of verifying the cardboard was in no possible way manipulated during transit (achieving integrity) and that the shipment genuinely originates from the selected vendor (achieving authenticity). DKIM is based on asymmetric cryptography. The signature is verified against a public key also listed in DNS records.

3. DMARC (Domain-based Message Authentication, Reporting & Conformance): It is a policy build on top of SPF and DKIM to guide receiving servers on what to do if an email was not authenticated (should the email be rejected, quarantined,..). 

DMARC also sends a report to the domain owner to warn about who is sending the email using their domain. It is like the alarm system in a house. While SPF and DKIM acts as the door locks (protecting access, authentication and integrity), DMARC is the watchtower in case someone breaks a lock. It will call the police (reject the email) and send an intrusion notification (report to the legitimate domain owner).

4. ARC (Authenticated Received Chain): In case an email is forwarded, SPF and DKIM authentication checks are often broken. Because the email can be relayed via a mailing list, a corporate gateway etc.. the original sending IP eventually changes which in turn may altered the signed DKIM headers. To preserve these results, the ARC protocol will back up the original authentication. 

A simple analogy is a sealed chain-of-custody document conserved for evidence. When an email goes through the web, it passes along multiple mail servers. Each forwarding server adds its own signature to the mail headers. This allows the final recipient to verify who handled the email during forwarding. ARC also make sure the email was legitimated when it entered the forwarding chain.

While SPF/DKIM/DMARC/ARC are great to verify authentication, it is nevertheless also essential to implement recipient protection measures. Below are a list of the technologies used to further protect against spoofing:

1. Spam filters: These filters combine key techniques to flag an email as unsolicited. Spam filters are foundational component of any email system .They rely on a scoring system where each suspicious mail characteristic increments an email spam index. If that score exceeded a defined threshold, the email is flagged as a spam. 

These key techniques encompassed the previous ones and associated them with others such as content analysis (heuristics), header analysis, reputation-based filtering, adaptative learning or Bayesian, probability-based filtering, greylisting, Machine learning & AI etc.

2. BIMI (Brand Indicators for Message Identification): This technology provides a trusted indicator of legitimacy to the recipient. It allows a company to have strong DMARC enforcement (p=quarantine or p=reject) to display their verified logo in the recipient’s inbox.

3. Email Security Gateways (ESGs) / Secure Email Gateways (SEGs): These are DMARC configured filters strictly enforcing the policies on all incoming and outgoing emails. Even if the receiving domain policy is set to a weaker DMARC enforcement (p=none), ESGs will quarantine or reject emails that failed SPF/DKIM checks.

4. DNSBLs (DNS-based Blockhole Lists) and RBLs (Real-time Blockhole Lists): These contain lists of harmful or spam used IP addresses. ESGs will screen a sender IP address against these lists. This way, an email on a list is blocked even before authentication is performed. Blacklisted bad actors are stopped from the start at the connection stage and processing resources are saved for legitimate emails.

5. DNSSEC (Domain Name System Security Extensions): This mechanism guarantees the authenticity and integrity of the DNS records and is a powerful pillar in a multi‑layered defence against email spoofing. It cryptographically signs every DNS response (e.g., A, MX, TXT, etc.) with a private key held by the zone owner. 

This allows the recipient to verify the authenticity and integrity of the DNS data. Since SPF, DKIM public keys and DMARC policies are stored in DNS, the attacker cannot silently replace or delete these records without causing a resolver validation failure.

6. MFA (Multi-Factor Authentication): It is a second authentication method to proof a user identity and protects against account takeover. In case a spoofed email tricks a user to giving up their password, MFA will prevent the attacker from logging in because even with a user credentials, the attacker will still need a second factor authentication mean to pass a service challenge (e.g., enter the code from your authenticator app). 

As the attacker does not have the user’s device or his security key, it is impossible to provide the second factor and access is denied. The attack is thwarted.

7. URL Scanners / Link Protection: These are safety net tools scanning links in emails and in real-time. It can be when the email arrived or at the time of clicking and they check the links against databases of known malicious sites. It is also possible to include sandboxing to analyse linked sites.

8. SAT (Security Awareness Training): This is the human shield element. Training a workforce to stay vigilant and suspicious about unexpected emails even for those that passed authentication checks and to report them via appropriate channels (mailbox phishing button, security mailbox, security ticket, Teams/Slack channels etc.). 

Solutions like Knowbe4 set a security baseline and target improvements for a company staff to complement technical controls. Phishing simulations, e-learning, live sessions, gamification are generally used to strengthen the overall “human firewall” posture.

It is important to note that it is the combination of all these technologies that effectively build a sophisticated, multi-layered protection against spoofing and phishing. With the rise of AI, the prevention of new threats has reached a new digital battlefield.

Advanced Spoofing

In a more elaborate scenario or in a near perfect spoof playbook, the attacker can combine all the components of an email header (and more) to make the message trustworthy and originating from a legitimate sender. In this case, here are the components that are manipulated along with the From field:

1. Reply-To: The attacker can change this header to a different and controlled email address (e.g., [email protected]). When the victim replies to the message thinking he is answering the legitimate sender, the response will actually move to the attacker without them noticing.
2. Return-Path: It is a special header (sometimes called the bounce address) used among other for sending bounced-back messages, delivery failures, spam complaints.. when an email failed to be delivered. It tells receiving mail servers where they should forward any Delivery Status Notifications (DSNs; a term that covers all the automated messages a mail system can tell about the outcome of an email after it left the sender’s server) including delivery failures. This header is usually hidden from end-users and only become visible when a DSN needs to be generated (and it is always visible in the raw source of any email).
3. Source IP Address: The attacker can pick any IP address that they control or that they have compromised. It can be a newly provisioned cloud VM instance, a fresh compromised host, a botnet of infected computers..
4. Received: This header is part of the email’s header section. It appears before the blank line that separates headers from the message body. There is a chain of SMTP servers (hops) that a message has to pass through. Each SMTP hop adds a line to the email; the topmost line is the most recent hop (the target’s MX). An attacker can omit this chain or fabricate a plausible hop list to make the trace look legitimate. In a raw RFC‑822 / MIME message (a multipart email format standard) it shows up like this:

Return-Path: <[email protected]>
From: Alice <[email protected]>
To: Bob <[email protected]>
Subject: Quarterly report
Date: Mon, 04 Aug 2025 10:15:00 +0200
Message-ID: <[email protected]>
Received: from mail.example.com (mail.example.com [192.0.2.45])
 by mx.receiver.org (Postfix) with ESMTPS id 7A2C3D4E5F
 for <[email protected]>; Sat, 09 Aug 2025 08:15:02 +0000 (UTC)

[blank line here]

Hello Bob,

5. Message-ID, Date, Subject, MIME, DKIM-Signature… and more! The attacker will not stop at tampering with headers and will also modify any metadata involved. The attacker will generate a syntactically correct globally unique identifier (ID) that matches the claimed email domain (e.g.: Message-ID: <[email protected]>).The date of the message is the timestamp of when the message was supposedly created. It can also be set in a realistic date/time period and injected at a different time in the delivery chain. The subject or the human-readable title in the inbox can be changed in something that the target expects (e.g., “Invoice #12345 — Action Required”). This is pure social engineering and not a technical weakness. MIME (Content‑Type, multipart structure, boundaries) describes the message body encoding (plain‑text, HTML, attachments..) and how the email parts are separated. Here the attacker can embed malicious payloads in attachments (PDF, Office docs) and hide them behind a proper Content‑Disposition: attachment; filename=”invoice.pdf” header. He can also builds a message containing both a harmless plain‑text part and a malicious HTML part (e.g., a hidden iframe or a link to a credential‑phishing page). DKIM-Signature is a cryptographic signature generated by the legitimate domain’s private key. It covers selected header fields (usually From, Subject, Date, Message-ID, and the body hash). Here the attacker would need to obtain the private DKIM key to produce a perfectly valid signature. This is less common but still possible through a breach, an insider leak or even a weak key storage.

What is important is that the fields From:, Return-Path: and Reply‑To: must all be pointing to the attacker‑controlled addresses. In a classic example of BEC (Business Email Compromise) or impersonation attack, these headers are all manipulated to ensure manual responses or automatic replies go directly to the attacker. 

In below example of an advanced attack scenario, the criminal tries to trick a company’s accounting department into paying a fake invoice by impersonating a legitimate vendor:

Received: from mail.attacker-website.com (attacker-website.com [45.45.45.45])
by mx.google.com with ESMTPS id abc123def456
for <[email protected]>;
Tue, 24 Oct 2023 10:15:30 -0400 (EDT)
From: “VendorCorp Invoicing” <[email protected]>
Return-Path: <[email protected]>
Reply-To: <[email protected]>
Message-ID: <[email protected]>
X-Mailer: Attacker’s Custom Mailer
To: “Accounting Department” <[email protected]>
Subject: URGENT: Payment Required for Invoice #INV-7842 — Overdue

The technical deception is carried out in the email’s raw header section, where the attacker inserts his own header fields. 

• From: “VendorCorp Invoicing” <[email protected]>. The malevolent mail server declares this identity to the victim email server. Remember that by default, the SMTP email protocol do not require authentication of the From: address.
• Return-Path: <[email protected]>. This address will receive all the bounces, OOO (Out-of-Office), NDR (Non-Delivery Reports) etc. It is important to effectively control this header and to conceal the discovery of a spoofing attempt by the legitimate company. The finance department should not suddenly receives a bounce message or an out-of-office reply for an invoice they never sent. In fact, the attacker must capture all automated messages to its own controlled Return-Path address. This way, it is possible to silently monitor the replies to confirm which recipient addresses are active or monitored. 
• Reply-To: <[email protected]>. This address will receive the manual responses. When the victim clicks “Reply”, their response will not go to the address in the From: field. Instead, it will automatically go to this attacker-controlled address. Even if the victim analysed the From: address, there is less chance the victim will also check the Reply-To header before responding.

The social engineering part occurs in the email body. Even if the headers can appear convincing, the mail content must also look credible.

Subject: URGENT: Payment Required for Invoice #INV-7842 - Overdue

Body: Hello Accounting Team,

Please find our invoice #INV-7842 attached, totalling $4,750.00 USD.

Our records indicate that this invoice is now 5 days overdue. This is a final reminder before late fees are applied, as per our agreement.

Note: We have recently updated our payment processing system. Please disregard any previous banking details you have on file. All payments must be made via wire transfer using the instructions below.

Bank Name: GlobalCorp Bank
Account Name: WorldCorp Payments Inc.
SWIFT/BIC: ATKRUS33
Account Number: 9876543210

To avoid service interruption, please process this payment immediately and reply to this email with the wire transfer confirmation.

Thank you,

Sarah Mitchell
Senior Billing Manager
WorldCorp Inc.
Phone: (Any legitimate phone number harvested from the real vendor’s website to pass checks)

This email and any attachments are confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient, please notify us immediately.

The email body can also contain the same logos, fonts, and branding of the impersonated company with the difference that these images are not attached to the email. Instead, they are being hosted on a malicious website and linked using tags (e.g;<img loading="lazy" decoding="async" src="https://attacker-website.com/logo.png">).

The invoice PDF attachment will use stolen company logos, formatting and mimic the company communication style as well.

The Attack Path

The victim, an employee or an intern from the Finance department, concerned with the overdue status, replies in their email client. The client automatically fills in the To: field with the attacker address from the Reply-To: header ([email protected]).

The attacker receives the reply. Speed will be paramount for a successful attack so they respond promptly and provide additional “proof” and context or pressure to make the victim act quickly.

The victim still believe to be dealing with a real supplier and transfers the funds into the attacker bank account. 

The attacker moves the collected funds through multiple accounts or withdraw the money to make the recovery nearly impossible.

This attack is effective if the spoofed sender address vendor-corp-legit.com has a weak or non-existent DMARC policy. In that case, the spoofed From: address might have a chance to pass authentication checks on a poorly configured receiving server.

Moreover people tend to trust the reply function implicitly because they still believe that responding to an email will return a message to the original sender.

As mentioned, by controlling all response paths (especially the Reply-To and Return-Path), the attacker maintains a complete control over the communication for the time of the exploit.

Bottom line — TLDR

Email spoofing remains a dangerous social engineering technique to incite end-users into careless actions with their mailbox. It is the telltale sign that security always stay in the hand of the recipient. Indeed it is up to the employee to remain vigilant about the legitimacy of the sender and not just rely on potent protection mechanisms only. 

The defence protocols and email protection techniques have improved exponentially since the early days of SMTP. Still with the onset of AI-driven techniques and the relative easiness to launch a malicious spoofing campaign, the level of complexity on both defence and attack sides has increased as never before.

The good news is that this kind of attack has nonetheless little to no chance to beat the like of Gmail, Outlook for Business thanks to their defence in depth approaches and combined defence techniques. 

A very elaborate spoofing will still be flagged and discarded by strong protocols/policy/filters etc. It takes only one alert from any of these mechanisms to quarantine the message. 

Today a spoof domain must own a strict DMARC policy with an authorized IP, DKIM key, ARC-seal etc. to hope reaching the recipient inbox. This is why an attacker should target suppliers and third party tools without strict DMARC policy or using workflows based solely on the Reply-To field.

 Henceforth it is critical for a company to demand that all concerned suppliers, third parties implement robust security controls and can demonstrate their spoofing resilience (e.g., during auditing).