Why I built DMARCER

Life inside an MSP

If you have worked in an MSP, you will know the feeling. You are not looking after one company, one Microsoft 365 tenant or one set of tools. You are looking after dozens of different environments, each with its own systems, suppliers, quirks and risks.

And it compounds with every customer you take on. Onboard a new client and you often inherit a whole new set of tools with them. Either your engineers have to learn yet another platform, or you carry the cost and effort of migrating that client onto your own stack. Neither is free, and neither is much fun.

What wore me down over the years was how hard so many security platforms are to actually live with at scale. Every tool has its own portal, its own language, its own alerts and reports. Engineers are expected to hop between all of them all day and somehow know each one like a specialist. That is not realistic, and it is not fair on good engineers who just want to spot a problem, understand the risk and fix it.

Why domain security in particular

There is a kind of attack called business email compromise, where someone sends an email that looks like it came from a company or a person you trust, and a real person pays an invoice, hands over data or moves money that never comes back. Almost every one of those attacks works the same way, by impersonating a domain someone trusts.

Here is the part that still surprises me. When we scanned tens of millions of domains for our benchmark, fewer than 15 percent had email authentication set up to actually stop it. Getting domain security right, SPF, DKIM and DMARC set up and genuinely enforced, is what closes that gap. It is quietly one of the most important controls a business has, and one of the most overlooked.

So I built the thing I wished I’d had

Something that makes domain security clear instead of cryptic, quick to manage instead of a chore, and genuinely shaped around the way MSPs actually work. Multi-tenant from the ground up, honest reporting, guidance that tells you what to do next, and integrations with the tools you already use. To me those were never optional extras. They were the whole point.

I also believe this kind of security information should not sit off on its own island. It should live alongside the tools an engineer already trusts, so the things that matter are easy to see without yet another login to remember.