Email Spoofing Explained: How Attackers Fake the From Address

The original sin of email: SMTP has no identity verification

When email was invented in the early 1970s, it was a tool for researchers on a trusted academic network. No one imagined it would become the primary communication channel for banking, healthcare, and business. As a result, the underlying protocol — SMTP — was designed with zero sender authentication.

In SMTP, the From: field is just a text string. Any mail server can put any address in it. This is not a bug — it was a deliberate design choice for flexibility. But it means that without additional controls, anyone can send an email claiming to be from ceo@yourcompany.com, noreply@paypal.com, or security@yourbank.com.

How email spoofing actually works

There are two layers of "From" in every email, and understanding the difference is critical:

• Envelope From (Return-Path) — Used by the mail server for bounce handling. This is the technical sender address and is set during the SMTP conversation. It is not shown to the user.
• Header From — The address displayed in your email client. This is what users see and trust. It can be completely different from the Envelope From.

Most phishing attacks exploit the Header From. An attacker can configure their mail server with a legitimate-looking Return-Path while showing From: security@yourbank.com in the visible header. Many email clients display only the Header From, making the email appear completely legitimate.

SPF: authorizing legitimate senders

SPF (Sender Policy Framework) is a DNS TXT record that lists every mail server authorized to send email on behalf of your domain. When an email arrives, the receiving server checks the sending IP against this list.

The ~all at the end means unlisted senders are marked as SoftFail. The strict version is -all, which instructs receivers to reject unauthorized senders outright.

SPF limitation: SPF only checks the Envelope From (Return-Path), not the Header From that users see. A clever attacker can pass SPF on the envelope while forging the visible From header. This is why DKIM and DMARC are also needed.

DKIM: cryptographic proof of origin

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to the email's headers. The sending server signs the message with a private key. The receiving server fetches the corresponding public key from DNS and verifies the signature.

If the signature verifies correctly, the email demonstrably came from a server that holds the private key. Any modification to the message in transit will break the signature.

DKIM limitation: DKIM signs messages but does not tell receivers what to do if the signature is missing or invalid. That enforcement is DMARC's job.

DMARC: the enforcement layer that ties it together

DMARC (Domain-based Message Authentication, Reporting & Conformance) is the policy that connects SPF and DKIM and tells receivers what to do with messages that fail both:

With p=reject, any email that fails both SPF alignment and DKIM alignment is dropped at the receiving server — it never reaches the inbox. This is the only configuration that truly prevents domain spoofing from being delivered.

Check your domain's current exposure

Use our free tools to inspect your domain's SPF, DKIM, and DMARC records right now. Each tool gives you a plain-English explanation of what your current records do — and what risks remain.