Skip to the end if you’re here only to see the (maybe hot) new email technology that our clients use to protect their brands and improve email open rates. The stuff in between gets personal.
Startups are tough
Really, really tough. Startups are also fun. Really, really fun. I’ll run you through our journey from mostly tough to tough & fun.
On our way through Techstars ATL (back in 2017), we decided to not raise VC funding. And by “we decided” I mean that around Demo Day, our managing director assured us that we were a terrible team and he’d tell investors to skip over us. That was a death blow because when you graduate from a top accelerator, investors are quick to trust MDs who judge your progress throughout the program.
Those words from our MD stung because a couple of my teammates and I were pouring everything into this company. Those words would still sting today if I’d let them.
Did we suck at some stuff back then? Yes. Were we improving? Yes. Have we continued to improve? Yes. Are we hungry and working hard to improve across the board? Absolutely. Is there always something else we can do to continue this trend? Again, yep. The key for me is remembering that there’s a lot of space between these two:
- You suck. (what we heard in 2017)
- You suck at some stuff but you can improve by sustaining strict discipline and hard work over time. (more accurate, less crushing)
I recognized our own MD as a major headwind against the traditional startup VC funding path but was not convinced we needed a ton of cash to continue growing. Therefore, I chose to hunker down and build. Our war chest was the meager remainder of the standard $120K Techstars investment and my own savings. Taking no salary, marked for failure by our MD, and burning through my savings, we marched on. My former mentors cringed at the choice and my co-founder left.
Why continue?
- Pressure. Open-sourcing some of our core dmarc software helped commoditize the industry. As expected, tons of new market entrants emerged. This forced us to bring something even better to market.
- Heat. We were burning through my savings. I remember biking between my personal bank and our corporate bank to move cash. I had no car, couldn’t spare $20 in wire fees, and was in danger of missing payroll for our remaining employees.
- Time. Given an impossible tech problem, a computer, and $0, I’ll be happy forever. I don’t build to make a dollar; I build because I am a builder. A few times, Fraudmarc was whittled down to a company of one (plus the reliable handful of service providers that kept the business running).
To most, those are not reasons to continue. To me, they’re the recipe for forming diamonds.
In addition to time, it also takes incredible heat, massive pressure, and carbon to produce diamonds. The rare conditions necessary to produce diamonds are part of what makes them so precious.
Taken from a top search result about how diamonds are formed
Reread #3 above. Given an impossible tech problem…. We’re about to dive into one such challenge together. Fraudmarc exists because our clients entrust us with their difficult problems, so I am personally grateful to each of you clients. But is that enough to thrive as a company?
Spoiler: We're still here, 4 yrs later
There’s something deeply satisfying about your clients also being your investors. Unlike many of the glamorous startup unicorns, we reached profitability within the first few years and plan to continue operating sustainably.
I might go further to suggest that being client-financed facilitates a level of company-to-client alignment that’s difficult to attain when the financial returns schedule of external investors rules the day.
Problems we solve
We are an email authentication company, which means that we help our clients navigate the complex technical protocols (mostly spf, dkim, & dmarc) that distinguish good from bad email and help determine which ones reach the inbox. If you've setup any modern email marketing, newsletter, or ecommerce solutions, you've probably encountered confusing technical instructions pertaining these protocols.
What makes these little buggers so hard is that they’re all highly technical and require mastery of hundreds of pages of esoteric language in the form of internet rfcs (request for comments). Add to that the fact that their adoption predates the very concept of cloud by more than a decade, and it starts looking a lot like the square-peg round-hole problem.
The soft launch below pertains to a step forward in dmarc technology, so let’s unpack dmarc next.
DMARC should be simple
Using dmarc reporting, one can identify IP addresses and authentication results of mail sent on behalf of their domain. For example, my dmarc reports show the IP addresses and the spf & dkim details of mail from any @fraudmarc.com addresses. It’s pretty cool because this even gives me visibility into mail sent from a faraway cybercriminal who spoofs my domain. That mail never enters my company’s system as it transits from the criminal to a victim. Dmarc shows that! Very cool.
Scale up to organizations as large as our clients, and you can imagine that it becomes a chore to collect, parse, and analyze thousands of these reports every day. Thus, the need for dmarc vendors like us (or our open source Fraudmarc CE). We helped commoditize the ability to study mountains of dmarc data to make the internet better.
Using dmarc reports, here’s the simple little process to protect a domain:
- Identify each email vendor sending mail with this domain in the from address.
- Sign into each vendor to configure spf & dkim.
- Publish a strict dmarc policy to block all unconfigured email.
Not so simple. Sometimes impossible
The above steps are deceptively simple. What about when you’re a company the size of Cisco? The person looking at dmarc reports sees an IP address sending mail. Is it good mail or bad mail? Who knows? Dmarc vendors can help the analyst link the IP address to a known email vendor. Now the analyst determines that someone (no idea which of their ~75,900 colleagues) might be using a company such as Mailgun to send email. Maybe it’s a cybercriminal using the service to spoof @cisco.com email.
I have no affiliation with Cisco or any knowledge of their situation beyond what we’ll publicly examine, so this is a partially hypothetical case that resembles challenges we’ve experienced with clients.
Their analyst may be able to access an inbound mail gateway and find the mail sent by Mailgun ONLY if it were sent to a @cisco.com address. It’s more likely that the analyst only finds messages sent by other companies into Cisco using Mailgun. They’re still no closer to identifying who uses Mailgun to send from @cisco.com, which means no closer to configuring the necessary spf & dkim.
Scenarios such as this have been the subject of many unanswered pleas by large organizations to email industry groups. Will you please tell me which of my users is using your service, kind email service provider? That way I can configure their spf & dkim then enforce a strict dmarc policy.
Cisco is a neat company full of brilliant engineers, so it’s worth mentioning that they’ve published their own detailed how-to for dmarc enforcement (linking pdfs is sorta rude, so copy and paste if you want a big ol’ pdf download) https://www.cisco.com/c/dam/en/us/products/collateral/security/esa-spf-dkim-dmarc.pdf.
Clearly, Cisco knows a lot about the theory of dmarc enforcement. But here’s where it gets interesting: Let’s examine their dmarc policy since the whole point of these policies is their public availability. We'll use a dmarc record checker that can tell you about any domain's policy.
p=quarantine almost directs spoofed mail to the spam folder... except pct=0?!
In plain English, this policy says, “Please quarantine 0% of unauthenticated mail.” Lol, how much good is that going to do? Let’s give them credit for a clever approach that allows them to truthfully say “we have a quarantine policy” while effectively having no enforcement, like a p=none policy. This unusual policy caught my eye and is why I’ve chosen their domain in this example.
Cisco’s detailed dmarc how-to document (still a pdf so here’s the url: https://www.cisco.com/c/dam/en/us/products/collateral/security/esa-spf-dkim-dmarc.pdf). This demonstrates that they fully understand dmarc. It looks like they’re even investing in a third party dmarc vendor. Yet they’re not interested in blocking any spoofed mail?! 0% enforcement. IMO, there’s no way that’s their goal.
My hypothesis is they’ve hit the same blocker that Fraudmarc faced for years as we helped our own clients. It’s the same blocker responsible for around 80% of dmarc efforts failing to reach enforcement. They’re probably trying to figure out which of their thousands of employees own the mail flows that are not yet configured for spf & dkim so would be blocked by dmarc enforcement. Once they find those users and configure their email vendors, they’ll be on their merry way to preventing email spoofing on their domain. Otherwise, they’re stuck between a rock and a hard place.
The dark secret of implementing dmarc
Pick one:
- Allow potentially bad mail to be delivered.
- Block email that may impact the critical business units because you don’t have enough info to configure them.
Until now, that’s been the blocker of dmarc. Marketing vs security. Let good & bad mail fly vs block bad & good mail.
I’ve talked to numerous other vendors in the dmarc space who have a running “joke” among them called the scream method. It goes like this: dmarc vendor tells the client to block a bunch of mail flows (to see what happens). This could disrupt an important email sender and someone will come scream at the client. Here’s the “joke”: lol, now you know who owns that account.
Are you effing serious?! That’s state of the art in the dmarc world and it’s gross. Literally, our publicly traded competitors do this to their customers and laugh about it.
The Fraudmarc difference
At Fraudmarc, our clients are our investors. They’re our patrons who introduced us to this challenge in the first place…and they’re also our friends! Friends don’t let friends block good email. That’s how people lose jobs! Rather than become calloused to this industry BCP (best common practice), we dug deep into the tech and into our connections with ESPs (email service providers) and ISPs (internet service providers). You could say we became obsessed with creating better technology that would truly delight our clients.
By 2019, we had started to hit a little stride in our growth. We’re thankful for the mentors who stuck with us through the trough of sorrow.
Delight clients
Between the hype and heartbreak of startups, there’s a temptation to lose sight of this simple principle. Here’s the tech breakthrough that happened to us because our clients have been so awesome that we had no choice but persevere.
I am humbled and honored to show you the latest tech our clients helped us build.
This is the result of ~4 years of studying over 8.3 million dmarc reports for thousands of domains. It’s a way for clients to see who is using each of their vendors, something that’s painfully absent from traditional dmarc.
We call it “high-definition dmarc” because it gives our clients a quick, easy, safe, and privacy-friendly way to see who is using each vendor…. All right inside their usual dmarc reporting panel. Our clients think it’s pretty cool and maybe you will, too.
Head over to dmarc-hd.org to learn about it
P.S. zoom & enhance, as seen in every spy movie, sums up what we’ve done to dmarc. Hope you find the linked video as funny as we did.
High def dmarc is a Layer 2 Protocol enhancement that rides on top of the original dmarc rfc. It’s currently a proprietary specification, and I’m well aware that both layer 2 and proprietary attract the ire of many the old-school, it’s-supposed-to-be-hard curmudgeons of the internet. We might make the underlying data-sharing network more public and eventually go the rfc route. We might not. While contributing to the development of an unrelated email rfc, I watched it strain the resources and patience of internet giants (the huge, public companies you all know). We don’t have those kinds of resources to burn, nor do we see an immediate advantage to doing so. After all, APIs are almost always proprietary and enjoy massive worldwide adoption. Not everything good about the internet is an rfc.
If you’re here only to throw shade because this wasn’t built this way or that way, please move along and have a nice day. Our clients employ us to solve their tricky problems, so this protocol was built client-first. That’s how we’re building the next few, too.
It’s been satisfying to watch clients blaze through the process of tracking down and configuring each and every sender on their domain using this newly available data.
Conclusion
When in doubt, build for your clients. The journey can feel cold and lonely at times but I encourage you to persist. If you’re struggling with your own journey to make something cool, reach out via the contact form and tell me how I can help. I’d love to see you build something great.
We survived a few early incidents that could almost be described as friendly fire. Followed by a 1-2 punch of our MD promising to block us and the comically dry Atlanta VC environment, we skipped VC fundraising. We doubled down on taking care of clients and building the best tech we could build. We had a modest but growing revenue stream dating back to our pre-Techstars days but that didn’t keep us from spending time in the red zone.
Techstars cohorts tend to be packed with amazingly capable founders. The coolest part of apparently being the weakest link in our cohort was that we had the opportunity to learn a lot from every single other founder & team. Most of the group is still in touch and encourages each other, which is absolutely the most valuable part of startup accelerators.
Despite all that we didn’t know back in 2017—and despite all I still don’t know as our CEO—we’re still here, learning, growing, and enjoying every minute of building cool stuff for our clients. By focusing on delighting our clients, we’ve grown into a sustainable company and created some pretty innovative new tech. While it’s not the most glamorous approach to running a startup, it does build a solid business. Have we made as much money as possible in the short term? Maybe not. But this path feels right for us builders who are motivated to create value and delight clients. I think it’s pretty cool that it’s growing into quite a business.
To answer the title, I’d say 4 yrs + 8.3 million DMARC reports + amazing clients = a company bootstrapped to profitability and several neat email protocol hacks. It’s especially fun when experts roll by to remind us what we’ve already done is impossible. We expect plenty more of that as those experts discover dmarc hd :)
If you know someone at Cisco, I’d love to better understand their unusual dmarc policy. Maybe high def dmarc could help. If we can help you or someone you know, we’re grateful for introductions and challenges.
Thanks for reading and, most of all, thank you to our clients! You’re the people who inspired us to build high def dmarc.
Also, thanks @jasondluna, for discussing and editing this post with me. Jason is a co-founder at Rapid, another Techstars ATL ‘17 company and 38 Degree Draught.
Keith
PS You've made it this far, why not join our company update list?
Subscribe
* indicates required
Email Address *
First Name
Last Name
