Move to p=reject without touching a DNS panel again

grimDMARC Hosted DMARC puts policy changes behind a dashboard instead of a DNS provider login — publish once, then enforce, roll back, and expand coverage from a single click.

Get started

The problem: DMARC policy changes shouldn't require DNS access

Getting from p=none to p=reject takes months of careful, staged rollout — and every single step means logging into a DNS provider and editing a TXT record. For one domain, that's manageable. For an MSP managing DMARC across dozens or hundreds of customer domains, each with a different DNS provider, it turns into a recurring operational drag: one login per customer, one mistake away from breaking their email.

On top of that, the reports DMARC produces arrive as raw XML — genuinely painful to read by hand, and easy to stop looking at once the initial setup excitement wears off.

The solution: grimDMARC Hosted DMARC

You publish a single CNAME record once — _dmarc.customer.com → id-x8f4c2._dmarc.grimdmarc.com — and the actual DMARC policy lives in our hosted DNS zone from then on. Moving from p=none to p=quarantine to p=reject becomes a button in a dashboard. The customer's DNS is never touched again.

Human-readable reports

Raw XML aggregate reports parsed into a dashboard you can actually read — who's sending, what's passing, what isn't.

One-click policy changes

Move between p=none, p=quarantine, and p=reject from the dashboard — no DNS panel, no propagation guesswork.

Multi-tenant for MSPs

Manage DMARC policy across every customer domain from one place, without logging into each customer's DNS provider.

Ready to move off manual DNS edits?

Check your current DMARC record →Read the DMARC guide →