You receive an email from your bank asking you to confirm a transaction. The sender address says [email protected]. The logo is right. The language is professional. You click the link, enter your credentials, and the page thanks you for confirming. Except the email never came from your bank. Somebody typed your bank's address into a text field, and the email system delivered it without asking a single question.
This is not a bug. It is how email was designed.
SMTP (Simple Mail Transfer Protocol) is the system that delivers almost every email on the planet. It was created in 1982, when the internet was a small network of universities and research labs where everyone knew each other. Verifying identity was not a priority. It would be like building a postal system where anyone can write any return address on an envelope and the post office delivers it, no questions asked. That postal system is still the one we use today.
What you will learn
Act 1: how email delivery actually works
When you hit "Send" in Gmail or Outlook, your email client hands the message to an SMTP server. That server looks up the recipient's domain, finds the receiving mail server (via MX records in DNS), connects to it, and delivers the message. The two servers have a short text conversation that looks like this:
Notice the two lines highlighted in red. The MAIL FROM (the envelope sender) and the From: header (what the recipient sees) are completely independent, and neither one is verified. You can type anything you want in both fields.
The envelope vs. header disconnect
This is the core flaw that makes email spoofing possible. Think of it like a physical letter:
The envelope
The MAIL FROM address. Mail servers use this for routing and bounce handling. The recipient never sees it.
In our postal analogy: the return address written on the outside of the envelope.
The header
The From: field inside the message. This is what Gmail, Outlook, and every email client show to the recipient.
In our postal analogy: the letterhead printed at the top of the letter inside.
An attacker can use their own domain on the envelope (so it passes basic checks) while putting your company's name and address in the header (so the victim trusts it). The recipient sees the header. They have no idea the envelope said something different.
For a detailed breakdown of how these two addresses interact, see our article on what the Return-Path is and why it matters for DMARC.
Act 2: how attackers exploited these flaws
SMTP's lack of identity verification created two major problems that fed off each other: open relays and spoofing.
Open relays: the spam superhighway
In the 1990s, most mail servers were configured as "open relays." They would accept email from anyone and forward it to anyone, even if neither the sender nor the recipient was associated with that server. It was the default setting because, in the early internet, that is how mail was supposed to work. Servers cooperated to deliver messages, like post offices passing letters between cities.
Spammers realized they could connect to any open relay and send millions of emails through it, hiding their real identity behind someone else's server. Open relays became the primary infrastructure for spam through the late 1990s.
Today, open relays are rare. The Internet Mail Consortium reported that 55% of servers were open relays in 1998, but less than 1% by 2002. Blocklists, ISP policies, and better defaults solved most of the problem. But spoofing did not go away. It just moved to a different attack surface.
Spoofing: the attack that still works
Even after open relays were shut down, the envelope-header disconnect remained. Attackers do not need an open relay to forge the From: header. They just need their own mail server (or any email sending service) and a willingness to lie.
Identity spoofing
The attacker sets MAIL FROM to their own domain (which passes SPF) but forges the From: header to show your CEO's name and address. The recipient sees the CEO's name and trusts it.
Display name spoofing
The attacker uses their own email address but sets the display name to something like "Amazon Security" <phishing@evil.com>. Many mobile email clients only show the display name, hiding the actual address.
Cousin domain spoofing
The attacker registers a look-alike domain (bigc0rp.com instead of bigcorp.com) and sends email from it. Everything about the email is technically legitimate. It passes SPF, DKIM, even DMARC on the cousin domain. The attack relies on the recipient not noticing the difference.
Unicode homograph attacks
The attacker uses characters from other alphabets that look identical to Latin letters. For example, the Cyrillic "a" (а) is visually indistinguishable from the Latin "a" (a), so аmazon.com and amazon.com look the same but are different domains.
A real-world attack: business email compromise
This is what a business email compromise (BEC) attack looks like at the SMTP level. The attacker wants to trick an employee at BigCorp into wiring money.
Here is why this works:
-
SPF passes because it checks the envelope domain (
bigc0rp.com), which the attacker controls. -
The recipient sees
[email protected]in their inbox, because email clients display theFrom:header, not the envelope. - Without DMARC, nobody checks whether the envelope domain and the header domain match. The mismatch goes undetected.
The FBI's Internet Crime Complaint Center reported $2.9 billion in BEC losses in 2023 alone. These attacks work because SMTP was never designed to answer the question: "Is this person who they say they are?"
SMTP smuggling: a modern twist
Even with open relays mostly gone and DMARC gaining adoption, SMTP still has surprises. In late 2023, researchers discovered "SMTP smuggling," an attack that exploits differences in how mail servers parse commands.
The attack works because some servers treat a line break differently than others. An attacker can embed a hidden second email inside the first one, and one of the two servers processes it as a separate message. The smuggled email can have completely different headers, including a forged From: address.
Major mail server software (Postfix, Sendmail, Exchange) released patches, but the vulnerability also affected hosted providers including Microsoft Exchange Online and Ionos. It is a reminder that SMTP's text-based protocol continues to produce new attack surfaces.
Act 3: how SPF, DKIM, and DMARC were built to fix this
SMTP could not be redesigned. Too many servers, too much existing infrastructure. The security community had to bolt on protections around it, like adding locks and cameras to a building that was built without them.
SPF (2003): check the sending server
SPF lets domain owners publish a list of IP addresses authorized to send email for their domain. The receiving server checks whether the sending server's IP is on that list.
The gap: SPF only checks the envelope sender (MAIL FROM), not the From: header the recipient sees. An attacker can pass SPF with their own domain on the envelope while forging the header.
DKIM (2007): sign the message
DKIM adds a cryptographic signature to the email headers. The receiving server can verify the signature using a public key published in DNS. If the message was modified in transit, the signature breaks.
The gap: DKIM proves the message was signed by a particular domain, but it does not require that domain to match the From: address. An attacker can sign email with their own DKIM key while forging the From: header to show your domain.
DMARC (2012): connect the dots
DMARC solves the gap that SPF and DKIM left open. It adds two things: alignment (the domain that passed SPF or DKIM must match the From: header) and enforcement (the domain owner tells receivers what to do with failures: nothing, quarantine, or reject).
The result: An email that passes SPF but uses a different domain in the From: header fails DMARC alignment and gets rejected.
Before and after: what DMARC changes
Without DMARC
Envelope: [email protected]
Header: [email protected]
SPF check: passes (for attacker.com)
Alignment check: none
Result: Delivered. Recipient sees CEO's name.
With DMARC (p=reject)
Envelope: [email protected]
Header: [email protected]
SPF check: passes (for attacker.com)
Alignment check: fails (attacker.com ≠ yourcompany.com)
Result: Rejected. Never reaches recipient.
Common questions
"I closed my open relay. Am I safe?"
From relay abuse, yes. But if your domain lacks SPF, DKIM, or DMARC, attackers can still forge your address from their own servers. Closing the relay protects your server from being used as a spam tool. DMARC protects your domain from being impersonated.
"Why didn't SPF and DKIM solve this on their own?"
SPF checks the IP address of the sending server, but only for the envelope sender, not the From: header the user sees. DKIM signs headers but does not require the signing domain to match the From: address. Both lack alignment and enforcement. DMARC adds both.
"Is SMTP still dangerous?"
SMTP's core design has not changed. The same flaws that existed in 1982 still exist. What changed is the security layer on top. With DMARC enforced at p=reject, SPF, and DKIM properly configured, the most common spoofing attacks are blocked. But newer attacks like SMTP smuggling show that the protocol continues to produce surprises. Keep your mail server software updated.
"What about encryption? SMTP sends email in plain text."
SMTP connections can be encrypted using STARTTLS, and most modern servers support it. But STARTTLS is optional, and an attacker can strip it from the connection (a "downgrade attack"). MTA-STS was created to fix this, by requiring TLS and pinning the receiving mail servers.
What to read next
Now that you understand why email is so easy to forge, the next guides explain how each layer of protection works: