/tutorials/why-email-spoofing-still-works
Why Email Spoofing Still Works Without SPF and DMARC
Why the openness of the original email protocol makes forgery possible by default, and exactly what each authentication check does and does not stop.
6 min read
Run SPF CheckerRelated tools
Email was never designed to verify who sent it
The protocol that moves email between servers, SMTP, was designed in an era when the people running mail servers largely trusted each other, and it shows no interest in confirming that a message actually came from where it claims to. Nothing in the base protocol stops any server from sending a message with any from address it likes. Every authentication mechanism in use today, SPF, DKIM and DMARC, is a layer added afterward specifically to compensate for that original design decision, not a built in part of how email fundamentally works.
What SPF alone does not stop
SPF checks the envelope sender, a technical address used between mail servers that is rarely shown to the person reading the message, rather than the visible from address displayed in their inbox. A message can pass SPF perfectly well while showing a completely different, spoofed address as the visible sender, because SPF alone never inspects that field. This gap is exactly why SPF was never enough on its own, and why DMARC exists specifically to tie authentication results back to what a recipient actually sees.
What DMARC closes, and what it still leaves open
DMARC requires that whichever check passes, SPF or DKIM, aligns with the domain shown in the visible from address, which is what finally connects authentication to the thing a person actually looks at. A domain with a properly configured DMARC record at p=reject makes it genuinely difficult to forge mail claiming to be from that exact domain.
Why a record at p=none does not protect anything yet
A DMARC record published with p=none is purely observational. It tells receiving servers to report on failing mail, not to do anything differently with it. A domain sitting at p=none indefinitely, which happens more often than it should, gets none of the actual protection DMARC is capable of providing, even though a check will correctly show a DMARC record exists. Existence of a record and active enforcement are two different things, and it is worth checking which one a domain is actually getting.
The gap that remains even with everything configured correctly
Even a domain with SPF, DKIM and a strict DMARC policy at reject only protects that exact domain from being forged directly. It does nothing to stop a scammer from registering a similar looking domain, exampl-e.com instead of example.com for instance, and sending from that instead, fully authenticated under its own name. This is why email security training still matters even for organizations with excellent technical configuration, since a look alike domain sails through every check described here without triggering a single one of them.
Checking where your domain actually stands
Run your domain through the SPF Checker and DMARC Checker to see not just whether records exist, but what they actually say, since a soft fail SPF record or a DMARC policy still sitting at none provides meaningfully less protection than a hard fail record backed by a policy of reject.
Related tutorials
