Email Spoofing: What It Is and How to Spot It
Spoofing is the reason "is this email real?" became a question in the first place. Here is how to answer it.
Email spoofing is the practice of sending mail that appears to come from someone other than the actual sender — a message claiming to be from your bank, your employer, or a colleague, when it is in fact from neither. It is alarmingly easy to attempt at the raw protocol level, which is exactly why every major email client now does substantial, mostly invisible work behind the scenes to detect and flag it before it ever reaches your inbox.
Why spoofing is possible at all
SMTP, the protocol that delivers nearly all email and is standardized in RFC 5321, was designed in an era of assumed mutual trust between a small number of institutional mail servers. The "From" header on a message is set entirely by the sending software, not verified by the network it travels across — there was originally no mechanism to confirm that the server sending a message on behalf of "yourbank.com" was actually authorized to do so. Without additional checks layered on top of the base protocol, literally anyone can construct a message claiming to be from anyone.
The three defences: SPF, DKIM, DMARC
Three complementary DNS-based mechanisms have been layered on top of SMTP over the past two decades to close this gap. Sender Policy Framework (SPF) lets a domain publish a DNS record listing exactly which mail servers are authorized to send on its behalf — a receiving server can check the connecting IP against that list. DomainKeys Identified Mail (DKIM) has the sending domain cryptographically sign each outgoing message with a private key, and publish the matching public key in DNS, so a receiver can verify the message was not altered in transit and genuinely originated from a server holding that private key. Domain-based Message Authentication, Reporting and Conformance (DMARC), defined in RFC 7489, ties the two together and tells receivers what to do when a message fails either check — quarantine it, reject it outright, or merely report the failure back to the domain owner.
Spotting spoofing as an ordinary user
- The sender domain looks subtly off on close inspection — paypa1.com instead of paypal.com, or a long, unrelated subdomain in front of a familiar-looking domain
- Your email client shows an SPF or DKIM failure warning in the message details view, if you expand it
- The body uses artificial urgency — "act within 24 hours" — specifically to discourage you from pausing to inspect the sender carefully
- A generic greeting ("Dear Customer") on a message that claims to be from a service that normally addresses you by name
- Requests to click a link and "verify" or "confirm" account details you were not expecting to need to confirm
What good sender hygiene looks like from the receiving side
You cannot control whether a domain publishes SPF, DKIM, and DMARC records — that is entirely the sending domain’s responsibility — but you can rely on your email provider having already checked those records before the message reached you, and treat a visible authentication-failure warning as a serious signal rather than something to dismiss. This is also directly relevant to disposable-email operators: a well-run catch-all mail receiver should itself validate SPF/DKIM/DMARC on inbound mail wherever practical, the same as any other mail server, to avoid becoming an easy destination for spoofed test traffic.
Display-name spoofing: the low-tech variant
Not every spoofing attempt requires defeating SPF, DKIM, or DMARC at all — a simpler, extremely common technique exploits the fact that most email clients prominently display the sender’s "friendly name" while hiding the actual underlying address unless you tap or hover to reveal it. An attacker can set their display name to "PayPal Support" or "Your Bank" while sending from a completely unrelated address that would fail every authentication check if the client bothered to surface that check by default. This works because most email clients optimize their default view for readability rather than security transparency, so the friendly name is what most users actually register when they glance at their inbox.
Why this matters more for accounts tied to your primary identity
A spoofing attempt aimed at your real, permanent email address is inherently more dangerous than one aimed at a disposable address, since the former is connected to your actual financial accounts, your actual employer, and your actual recovery flows, while the latter has no such connections to exploit even if the spoofed message is convincing. This is one more reason the broader habit of routing low-stakes signups through disposable addresses pays off indirectly: fewer services ever learn your real address, which means fewer opportunities for that real address to end up on a list a spoofing campaign later targets.
When in doubt about any message asking you to act — click, verify, confirm, pay — do not click through from the email at all. Open the service directly in a fresh browser tab, using a bookmark or a typed URL rather than the link in the message, and log in there instead. That single habit defeats the overwhelming majority of spoofing and phishing attempts regardless of how convincing the message itself looks, because it sidesteps the fake link entirely rather than trying to evaluate whether it is real.