Why We Built grimDMARC Around Customers, Not Domains

DMARC is not the problem, workflow is: scattered DMARC, SPF and DKIM records across unlabeled customer domains on the left, transformed into a clear four-step grimDMARC workflow on the right — Customer, Domain, Security finding, Recommended action

Over the last few months we've spent evenings and weekends building grimDMARC — a DMARC and email security platform for Managed Service Providers.

Like most technical people, we started with the technology. DMARC. SPF. DKIM. DNS. XML aggregate reports. We assumed those would be the hard parts.

They weren't.

The real problem wasn't the protocol

Once you sit down with the specifications, DMARC, SPF and DKIM are well-documented, mechanical problems. If you want the technical primer, What is DMARC? and the free DMARC Analyzer walk through exactly how the records and reports work.

The actual surprise came from watching how MSPs use this data.

Almost every email security tool on the market is built around a single domain. That's a reasonable design if you're protecting one company. But an MSP doesn't manage a domain — it manages customers.

A typical customer might have 1–3 domains. A mid-sized MSP might have:

500 customers
1,000+ domains
Thousands of mailboxes
Hundreds of open support tickets

At that scale, understanding a single DMARC record isn't the bottleneck. Knowing what needs attention right now is.

What a technician actually asks

When a technician starts their day, they don't open a tool and ask "show me the XML reports" or "show me today's DMARC records." They ask:

Who is affected?
Which customer?
Which domain?
What do I do next?

That question — not the protocol — is what shaped almost every design decision in grimDMARC.

Customer → Domain → Problem → Action

Instead of building around protocols and reports, we built around that hierarchy: MSP → Customer → Domain → Service. DMARC is the first service in that model, but it's deliberately not baked into the structure as the thing — SPF, BIMI, MTA-STS and DNS monitoring plug into the same shape as we add them, without forcing a redesign.

Domain-centric view versus customer-centric view: five domains scattered with no grouping on the left, versus the same domains organized under Customer A and Customer B beneath the MSP, each showing its DMARC policy, on the right

The dashboard follows the same logic. It's built to be an action list, not a stat wall — three clear items that need attention beat twenty widgets of data every time. The job isn't to say "here's your data." It's to say "here's your problem, and here's what should happen next."

Stat wall versus Action Center: six disconnected number tiles like 128 domains monitored and 99.2 percent pass rate on the left, versus three ranked, specific action items — each naming the customer, the domain, the risk and the fix — on the right

If you want to see the underlying checks for yourself rather than take our word for it, Domain Scanner runs the full authentication and transport-security picture against any domain in seconds, no account required.

The actual lesson

The most useful thing we've learned building this has very little to do with DMARC itself.

A protocol solves a technical problem. A product solves an operational problem. For MSPs, the operational problem — triage, prioritization, "who do I call and what do I tell them" — is usually the harder one.

We'd be curious whether others working with Microsoft 365, Google Workspace, or managed services more broadly have run into the same pattern: was the hard part the technology, or how the work got presented to the people actually responsible for it?

What to do next

Curious what your own domains look like today? Run them through the free Domain Scanner, SPF Analyzer or DMARC Analyzer — no account, no email address required.
Managing this across many customers already? Hosted DMARC is built around the customer-first model described above, not a single-domain dashboard.

About this post

This post was written by the team building grimDMARC, a managed DMARC, SPF and BIMI platform for MSPs and their customers. If you have thoughts on this or want to compare notes, reach us at hello@grimdmarc.com.