From the chaos of open relays in 2007 to today’s SPF/DKIM/DMARC protections, and how this story mirrors the history of SSL certificates.
The other day I received one of those emails that instantly caught my attention: a Delivery Status Notification (Failure). According to the message, an email I “sent” couldn’t be delivered to an address like user@google.com (a mailbox that doesn’t even exist).
The problem? I never sent that email.
Looking into the headers, I quickly realized what was happening: someone had spoofed my address. They forced the message to bounce so I would get it back, wrapped nicely inside a “failure notice.” And what was inside? A giant “Netflix renewal” spam link. Classic bounce-spam.
In short, the attackers weren’t interested in talking to me — they were trying to sneak spam past filters by hiding it inside bounce messages. Think of it as trying to smuggle something through customs by slipping it into the official paperwork. Clever… but not clever enough.
Back to 2007: The Wild West of Email
This reminded me of my early days in 2007, when I worked in a company constantly targeted by spammers. Back then, the battlefield was different: the main problem was open SMTP relays left unsecured.
I still remember finding that our own server was configured with no authentication at all. Spammers loved this kind of setup because it allowed them to send unlimited junk mail through someone else’s machine. Once I closed that door, the problem disappeared — but back then, tools like SPF, DKIM, or DMARC weren’t in widespread use.
Email was essentially running on the honor system… and the bad guys knew it.
SPF, DKIM, DMARC: The Trio That Changed the Game
Fast forward to today, and we live in a much safer email ecosystem thanks to three key technologies:
- SPF (Sender Policy Framework): the guest list — it tells the world which servers are allowed to send email for your domain.
- DKIM (DomainKeys Identified Mail): the wax seal — your server signs messages so others can verify they weren’t tampered with.
- DMARC (Domain-based Message Authentication, Reporting & Conformance): the policy boss — it checks whether SPF or DKIM align with the visible “From” and tells receiving servers what to do if they don’t (ignore, quarantine, or reject).
Together, they’ve made email so much cleaner that today we can almost say we live in a spam-free world. (Okay, not totally free… but at least we’re not drowning in a can of SPAM ham 🥫).
Déjà Vu: Just Like SSL Certificates
What’s fascinating is how this journey mirrors another story: the rise of SSL/TLS certificates.
At first, SSL was rare — only banks or online stores used it. Then came the big push: browsers started flagging non-HTTPS sites as “Not Secure.” Later, Let’s Encrypt made SSL free and easy. And today? HTTPS is the default. A site without it looks broken.
Email followed the same curve: invention → slow adoption → big players enforcing → normalization. Today, missing SPF/DKIM/DMARC is like running a website without HTTPS — you’ll look suspicious, and your content probably won’t reach anyone.
Lots of things have changed
That weird bounce-spam message was more than just junk in my inbox — it was a reminder of how far we’ve come. From the open-relay chaos of 2007 to the global enforcement of SPF, DKIM, and DMARC, the internet has grown up. And just like with SSL, it wasn’t only about technology — it was about collaboration, pressure from the giants, and making adoption convenient enough for everyone.
Security, after all, is not a one-time fix. It’s a collective journey… sometimes kickstarted by something as annoying as a fake Netflix renewal in your spam folder.
Thank you for reading this post! If you want to make sure your emails actually land in the inbox — not in the spam folder — I can help. From configuring SPF/DKIM/DMARC to improving overall deliverability, I work with teams to strengthen their email infrastructure and protect their brand reputation.
Comments
Post a Comment