Why Most Website Hacks Start With Email, Not Code
Everyone pictures a hacker typing furiously, breaking through a firewall with clever code. In reality, the overwhelming majority of breaches start somewhere much more boring: a convincing email that nobody double-checked.
Security teams spend a lot of time hardening servers, patching CMS plugins, and locking down APIs — and that work matters. But attackers go where the resistance is lowest, and for most businesses that's not the server. It's the inbox.
Spoofing is still trivially easy
Email was never designed with authentication in mind. By default, nothing stops someone from sending a message that claims to be from billing@yourcompany.com even though it never touched your actual mail servers. Unless your domain publishes SPF, DKIM, and DMARC records telling the world's mail servers which senders are legitimate, a spoofed email from your own domain will often sail straight into a customer's inbox looking completely authentic.
Why this matters more than a missing patch
A vulnerability in your CMS needs an attacker who finds it, understands it, and bothers to exploit it on your specific site. A spoofed invoice email needs none of that. It needs your domain name, a template that looks like your usual emails, and one employee or customer having a rushed Tuesday. That's a dramatically lower bar — which is exactly why business email compromise remains one of the most common ways companies lose money to fraud.
The fix takes minutes, not a security budget
Unlike most security work, email authentication isn't expensive or complicated. It's three DNS TXT records:
- SPF — lists which servers are allowed to send mail for your domain.
- DKIM — cryptographically signs outgoing mail so receivers can verify it wasn't altered.
- DMARC — tells receiving servers what to do when a message fails SPF or DKIM (ignore it, quarantine it, or reject it outright), and lets you request reports when that happens.
Most domains have none of these configured properly, or have SPF set up but no DMARC policy enforcing anything — which means the SPF record is really just a suggestion nobody has to follow.
Check your own domain
This isn't theoretical. You can check in about ten seconds whether your own domain is exposed to this exact problem.