How can an MSP manage DMARC across all its clients?

What changes across a whole book of clients

Your clients need DMARC whether or not they have asked for it. Google, Yahoo and Microsoft require a DMARC record from anyone sending email in bulk, so a client's newsletter or invoice run can start bouncing without one.

Sources: Google, email sender guidelines; Yahoo, sender best practices; Microsoft, error 550 5.7.515.

For one domain, the work is the same as in our other guides: publish a record, read the reports, fix the senders, then tighten the policy. Across every client you look after, each step multiplies, and some new problems arrive with it:

• Every client has its own mix of senders, so no two domains are ready for enforcement at the same time
• DNS sits with different hosts, some you manage and some the client or their web agency does
• Reports arrive for every domain, from every provider, every day
• A client adds a new sending service without telling you, and its mail starts failing
• Each client wants to see where their own domains stand, and nobody else's

What you need to run it

One view of every client

A single list of every client and domain, showing each domain's policy and how much of its mail passes. Without it, a simple question such as "which clients are still at p=none?" means opening a separate tool for each one.

Onboarding in bulk

Adding clients one at a time is where the hours go. In the partner console you import a CSV of customers and domains, up to 500 rows at a time, and tick up to 100 domains in one request. For clients on Cloudflare DNS, a script publishes every record in one run, with a dry-run mode so you can look first. Clients on other DNS hosts get the same list of records to publish by hand. We read the DNS every four hours and switch each product on as its records answer.

A safe pace for each domain

A book of clients cannot move to reject in one step, because each domain is ready at a different time. With Managed DMARC, each domain moves on its own evidence, with a person approving every step. Quarantine starts after about a month. Reject takes about three months, on purpose, so real email keeps arriving. Is it safe to switch DMARC to reject? explains why that pace matters.

Senders confirmed by the people who know

Your client knows their booking system. You may not. When a sender cannot be placed, the question goes to you and to your client, and whoever answers first places it. Who is sending email as my domain? covers the kinds of sender you will meet.

Alerts where your team already works

A change on a client's domain should land in the queue your engineers already watch. We open a ticket in your HaloPSA or ConnectWise PSA when something changes for a client, and add follow-ups as notes on the same ticket. For anything else, 13 kinds of signed webhook event and an API that reads your book let you wire it into the tools you run. The integrations page lists them.

A portal your clients can see

Each client signs in to see their own domains, and nobody else's. The client portal and its sign-in page wear your name, logo, colours and typeface, and sign-in emails carry your name while being sent from our address. You get one invoice for the whole book, and we never bill your clients.

Doing it with the tools you have

You can run DMARC for clients with a spreadsheet, a reports mailbox for each domain and the DNS logins you already hold. For a handful of clients with simple mail, that works. Every client you add brings its own reports to read, its own senders to chase and its own DNS host, so the time it takes grows with the book. That is the point where one console earns its place.

The short version

See how the partner console works, or talk to us about partnering. To see where any client's domain stands today, run the free check on it.

Sources

• Google, email sender guidelines
• Yahoo, sender best practices
• Microsoft, error 550 5.7.515