DMARC for Agencies, MSPs and IT Teams: What Changes at Scale
One domain is a project. Forty client domains, each with its own senders, DNS host and approver, is an operation. Here is what breaks at scale and how to run DMARC for clients without carrying the risk alone.
If you run a web agency, a managed service provider or an IT consultancy, your clients’ domains are already in your care. You host their websites, manage their DNS, look after their Microsoft 365 or Google Workspace tenants, and get the call when email stops working. DMARC should be a natural extension of that work. At scale, though, it changes character completely, and the reasons most agencies leave their clients at monitoring are structural rather than technical.
What changes when there are many domains
Setting up DMARC for a single domain is a contained project: publish monitoring, read the reports, align a handful of senders, step up the policy. Multiply that by forty client domains and new problems appear that no single-domain guide mentions.
| Challenge | One domain | Forty client domains |
|---|---|---|
| Sender discovery | A handful of known services | Hundreds of services across clients, most of which you did not set up |
| Report volume | A few files a day | Thousands of XML reports that nobody will read by hand |
| Approvals | You decide | A different decision-maker at every client, each needing an explanation |
| DNS access | Your own zone | Your servers, client registrars, third-party IT providers |
| Change over time | Occasional | Constant. Some client adds a new platform every week. |
Sender discovery is the real work
Your clients do not know every service sending email as their domain. They will remember Microsoft 365 and the newsletter. They will forget the accounting package that emails invoices, the payroll system, the booking engine, the website contact form, and the CRM a sales manager signed up for two years ago.
At scale you cannot rely on asking. The sender inventory has to be built from DMARC aggregate report data over a monitoring period long enough to catch monthly and quarterly patterns. Client input supplements the data; it cannot replace it. Any process that moves a client to enforcement based on a questionnaire alone will eventually block a legitimate service and generate an angry phone call.
Approvals and where responsibility sits
The single most important operational decision is who approves each policy change. When a client domain moves to p=reject and a legitimate sender nobody mentioned starts being blocked, the question becomes: who decided?
A defensible model has three parts. The evidence for each step is documented: which sources pass, which fail and why. The recommendation is made in writing. And a named person at the client approves it in writing before it is applied. That protects the client, who stays in control of their own email, and it protects you, because the decision is recorded and informed.
It also avoids a bottleneck that quietly limits many agencies: the founder or senior engineer being the only person who can make the call. Approval should sit with a nominated role at each client, not with whoever at your agency happens to understand DMARC best.
DNS access without widening your risk
Where you host the DNS, applying records is simple. Where a client’s registrar or another IT provider controls it, you need a clean way to get changes made. Two approaches work well at scale.
- Supplied records. The exact records are prepared and sent to whoever manages the zone, and publication is verified afterwards.
- Delegated records. The DMARC record is published as a CNAME pointing at a record hosted by the DMARC platform, so policy changes can be made without touching the client’s DNS again.
What you should avoid is granting broad zone-editing access on your own hosting infrastructure to outside parties. Keep access proportionate to the job.
Taking over existing DMARC set-ups
Some of your clients will already have DMARC through another provider. Migrations are where protection most often lapses, because DMARC reports are sent to whatever address is in the record’s rua tag. Switch too late and reports keep flowing to a provider nobody pays. Switch too early and data is lost while the new platform is not ready.
The safe order is: prepare the new platform to receive, update the reporting address and any delegated records, confirm reports are arriving, and only then end the old service. A domain already at p=reject should stay there throughout. A migration is not a reason to drop back to monitoring.
Client data and POPIA
Aggregate reports contain sending IP addresses and infrastructure details for your clients’ email. Under POPIA, whoever processes that data on your clients’ behalf takes on obligations around security, retention and deletion. Make sure any platform or partner in the chain has those obligations written into its agreement, and that your client agreements reflect them.
Build it or partner for it
You can build DMARC capability in-house: licence a reporting platform, train your team to interpret reports and troubleshoot alignment across dozens of platforms, and carry the escalations. For a large MSP with a dedicated security function, that can make sense.
For most agencies and IT consultancies, the numbers point the other way. Partnering lets you offer enforced DMARC as a recurring service, keep the client relationship and the margin, and hand the specialist work to people who do nothing else. That is the model MailMarq partners use.
The short version
- At scale, DMARC becomes an operational problem: discovery, report volume, approvals and constant change.
- Build sender inventories from report data, not client questionnaires.
- Recommend with evidence, have a named client contact approve in writing, and keep the record.
- Keep DNS access proportionate, and migrate existing set-ups without dropping enforcement.
Frequently asked questions
Should an agency resell DMARC or refer clients elsewhere?
If you already manage a client’s website, hosting or DNS, DMARC fits naturally into that relationship, and a partner arrangement lets you offer it without building the specialist capability yourself. Referring clients away hands their domain relationship to someone else.
Who should approve policy changes on a client domain?
A named person at the client, in writing. Your agency can recommend and apply changes, but the decision to enforce should sit with the business whose email is affected.
How do we price DMARC to clients?
Price it as an annual package per client, sold alongside hosting or care plans and paid upfront. The important thing is that the price covers a full year of monitoring, not just the initial set-up.
Sources and standards
- RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC). The IETF specification that defines DMARC policies, alignment and reporting.
- RFC 7489, section 7.2: Aggregate Reports. What receivers include in the daily aggregate reports.
- Microsoft Learn: Set up DMARC to validate email in Microsoft 365. Microsoft guidance on publishing and enforcing DMARC.
Keep reading
Why Monitoring-Only DMARC Is a False Sense of Security
A DMARC record at p=none ticks the box on a checklist and blocks nothing. If your domain has been at monitoring for more than a few months, it is not protected.
DKIM Explained: The Signature Behind Trusted Email
DKIM is the part of email authentication that survives forwarding and does most of the work for DMARC. It is also the part most often left signing with someone else's domain.
Rolling Out DMARC Safely: From p=none to p=reject
Enforcement is where DMARC protects you and where it can hurt you. This is the sequence that gets a domain to p=reject without blocking the invoices, statements and bookings your business depends on.
Find out where your domain stands
Send us your domain. We will review your DMARC, SPF and DKIM set-up, map the services sending as you, and tell you plainly what it would take to reach enforcement. No charge and no obligation.