My journey from Deliverability to DMARC: Why I think DMARC matters

I haven’t kept it a secret; if you know me, or even if you follow me on Linkedin, you’ve probably long ago figured out that I’ve been working for DMARC vendor Valimail since March 27th. My slightly unwieldy title is “Industry Research and Community Engagement Lead” and my role is a bit of a hybrid one, encompassing a bit of deliverability consultant, thought leadership on deliverability (and where it intersects with DMARC), content marketer/blogger, and community builder. Other little bits and bobs here and there, too, but those are the main ones.

So does that mean that I’ve left the world of deliverability? Not at all; DMARC is a part of the world of deliverability. For sure, DMARC also lives in the realm of email security and BEC (Business Enterprise Compromise) prevention, but there’s enough overlap there to carve out a space specific to my expertise. My personal goal is to help marketers (and other senders) understand that DMARC is a necessary component of deliverability success. (And maybe, just maybe, to help remind marketers that p=none with no reporting is not exactly the best “future proof” configuration for DMARC and for a secure domain.)

So why did I do this? Because I believe in DMARC. We need security as part of the email ecosystem. Just like with our best efforts to prevent spam from overrunning email, we need similarly to give it our best efforts to prevent phishing and spoofing from overrunning and ruining the usability of email.

And that’s why my goal, and my role, is to help translate and explain DMARC to the deliverability and marketing audience.

Not everybody believes in DMARC – I see complaints that it “breaks” email or that it “breaks” mailing lists or that it “breaks” email forwarding but these arguments don’t sway me. DMARC doesn’t “break” anything; it just requires you to be aware of your configuration and tools, and possibly improve, upgrade or replace a tool if it gets out of date and can’t keep up with modern security needs, or if it can no longer do what you need it to do.

I guess I’ve always been somebody that tries to look toward the future, to what’s coming and how to improve things in that future, instead of just relentlessly trying to protect the old way of doing things. Allow me jump back in time a bit to explain why.

Going back to my history in email and beginnings in anti-spam. In 1997/1998, I was trying to convince people to fix their mail servers to stop relaying spam. I started a blocklist, the Radparker Relay Spam Stopper, which ended up becoming part of the Mail Abuse Prevention System, then later became part of Trend Micro. I take pride in that – this little blocklist I created became some tiny part of an enterprise-level security solution (sadly, I don’t get royalties).

Back then quite a few people gave me a hard time about me supposedly trying to “force people” to upgrade their mail servers. “But I’ve got a user that travels on the road, and he pays me to relay mail for him,” was an actual argument I heard sometimes. Yeah, well, you’re relaying spam, too, and annoying other people. If they say that fences make good neighbors, then I say that insecure mail servers make for bad neighbors, because they send me mail that I didn’t want and I didn’t ask for.

Not everybody understood that spam was a problem. Not everybody understood that open relaying mail servers were a problem. Thankfully, most folks came around. We went from 1997/1998, when few people understood the problem, to 2004, when the FTC published guidance telling email server administrators to stop allowing open email (spam) relay. Watching the messaging go from “you’re crazy” to “the government says this a best practice” feels quite vindicating.

I see a lot of parallels here to the push to implement DMARC email domain security. Not everybody likes it. Some folks want to argue against it and claim that it just absolutely wrecks functionality that can’t be fixed (which I don’t personally believe is true – mailing lists survived DMARC, and email forwarding has been painfully complex since the early days of IP reputation – nothing that new here, IMHO).

But clearly, others think that DMARC matters. While a few folks speak out against it, lots of other folks implement it. My top ten million domains shows that more than 739,000 domains have added a DMARC record to DNS in the past twelve months, bringing the numbers up to a total just under two million domains, or twenty percent, of the top ten million domains, have jumped on the DMARC bandwagon.

That’s nothing to sneeze at. It’s not universal adoption, but it’s very significant. (And it doesn’t count the many other SMB/DIY domains that have DMARC implemented.) And there’s still lots to be done – to help convince more domain owners to move to a secure DMARC policy – the security people get it, the mailbox providers get it, but perhaps other folks are still getting there.

So there you have it. That’s my journey, my thinking on DMARC, and how I came to view it through a deliverability lens, and my opinion on why I think that DMARC is a good thing. It doesn't break email; it makes it safer.

And that’s how I’ll wind up my contributions to Deliverability Week.

Thanks for reading.