Skip to content
Partners

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.

ChallengeOne domainForty client domains
Sender discoveryA handful of known servicesHundreds of services across clients, most of which you did not set up
Report volumeA few files a dayThousands of XML reports that nobody will read by hand
ApprovalsYou decideA different decision-maker at every client, each needing an explanation
DNS accessYour own zoneYour servers, client registrars, third-party IT providers
Change over timeOccasionalConstant. 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.

Never let enforcement be a decision your agency makes on the client’s behalf by default. Recommend with evidence, let them approve, and keep the record.

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

  1. RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC). The IETF specification that defines DMARC policies, alignment and reporting.
  2. RFC 7489, section 7.2: Aggregate Reports. What receivers include in the daily aggregate reports.
  3. Microsoft Learn: Set up DMARC to validate email in Microsoft 365. Microsoft guidance on publishing and enforcing DMARC.

MailMarq
MailMarq is a managed DMARC service run from Johannesburg. Our team has built and managed business websites, hosting and email infrastructure for South African companies since 2016, and writes these guides from work on real domains.

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.

Scroll to Top