DMARC for MSPs: Managing Email Security Across Client Domains

Why is DMARC a managed service opportunity for MSPs right now?

Two things changed at once. First, the NCSC retired Mail Check and Web Check on 31 March 2026. The blog post is explicit that the external attack surface management market has matured and that the NCSC will only build where the market cannot, so it now strongly recommends organisations adopt a commercial product before the services are switched off. There is no free UK government drop-in that aggregates and processes DMARC aggregate reports the way Mail Check did. The NCSC does point readers at its “Check your cyber security” tool, but that is a point-in-time checker, not an ongoing report-processing service, so it does not replace the monitoring loop. Our Mail Check retirement guide covers the migration mechanics in detail.

Second, the posture data shows how much work is unfinished. Our UK MSP DMARC Audit (Q1 2026) looked at 192 UK MSPs, all with a valid MX record. 95% (183) had a DMARC record on their primary domain, but only 36% (69 of 192) had reached p=reject, 35% (67) sat at p=quarantine and 24% (47 of 192) were still on monitoring-only p=none. The bigger gap is brand coverage: 80% of those MSPs had an unprotected or absent alternate brand domain, and only 20% protected both their primary and alternate domains. When a 20-point penalty was applied for an unprotected alternate domain, the share rated Excellent fell from 29% to 9%, and the adjusted industry average dropped from 72 to 57 out of 100. If the MSPs running other people's email look like that, their clients look worse.

That combination, a withdrawn free tool plus a large enforcement and brand-coverage gap, is why DMARC monitoring sells as a recurring service rather than a one-off project. The reports renew the value every month: authentication pass rates, a live inventory of who sends as each client, and evidence of progress towards enforcement are all natural artefacts to put in a monthly client review.

How do I audit a new client's email security posture?

Discovery comes before onboarding. For each client you want a short, repeatable audit that you can run the same way every time, because consistency is what lets you compare tenants and quote accurately. Start with the public-facing posture, then map the sending estate.

• Run every client domain through the free Security Grade tool. It reports the DMARC policy and sp= subdomain policy, SPF state and lookup count, DKIM publication, and any DNSSEC or CAA gaps in one scan, so you get a single comparable score per domain without an account.
• Record the policy level (none, quarantine or reject), whether a rua= aggregate address is configured, and where it points. A record that still reports to a retired NCSC endpoint is a flag.
• Enumerate the brand estate. The client's primary domain is rarely the only one. Capture the .co.uk, .com and other TLD variants, parked marketing domains, and any acquisition leftovers. These alternate domains are exactly the ones the audit found 80% of MSPs leave exposed.
• List the legitimate senders: the mailbox provider (Microsoft 365 or Google Workspace), the marketing platform, the helpdesk or ticketing system, invoicing and payroll tools, and any transactional mail service. This sender inventory is what you will reconcile the DMARC reports against later.

The output of this stage is a per-client row in a spreadsheet: domain, current policy, RUA target, SPF lookup count, DKIM state, alternate domains, known senders, and a Security Grade score. That row is the baseline you will show the client at the first review, and the gap between it and p=reject is the scope of work you are quoting.

How do I onboard many client domains at once?

Onboarding a fleet is mostly about not redoing the same DNS dance sixty times by hand. The mechanical step that matters most is getting aggregate reports flowing for every domain, because nothing downstream works until the data arrives. For each domain you add or update one TXT record at _dmarc.clientdomain.example so that the rua= tag points at your monitoring address. A typical onboarding record for a client still at the start of the journey looks like this:

_dmarc.clientdomain.example.  IN  TXT  "v=DMARC1; p=none; rua=mailto:rua-clientref@your-monitor.example; fo=1;"

A few practical rules keep a multi-tenant rollout sane:

• Start clients who are already sending at p=none so you collect data without risking a single piece of legitimate mail. Start non-sending and parked client domains directly at p=reject with strict alignment, because there is no legitimate flow to break. The reasoning is the same as in our parked domains guide.
• Use a distinct, identifiable RUA mailbox or sub-address per tenant. RFC 7489 lets you list several reporting URIs, but giving each client its own routing label keeps the multi-tenant dashboard clean and makes per-client retention and access straightforward.
• Do not touch the client's existing SPF or DKIM during the first pass unless it is broken. The reports will tell you what is misaligned; changing records before you have data is how you cause an outage on day one.
• Verify propagation, then confirm the first reports land within 24 to 48 hours. If a domain goes quiet, the RUA tag is usually wrong or the change never propagated.

Where you can ask, request DNS delegation or a scoped API credential for the client's DNS so you publish the record yourself rather than emailing instructions and waiting. Where you cannot, a short copy-and-paste runbook per DNS host (the major registrars and managed DNS providers all accept the record as written above) keeps the friction low. For a complete protocol primer to hand to a client who asks what any of this means, point them at the plain-English DMARC guide.

Two mailbox-provider specifics save the most onboarding time because between them they cover the bulk of UK SME clients. Microsoft 365 tenants need DKIM explicitly enabled and rotated to 2048-bit in the admin centre before the signing CNAMEs become live, otherwise the reports will show DKIM failing for legitimate Microsoft mail and you will chase a false alarm; our DMARC for Office 365 guide has the exact sequence. Google Workspace tenants almost always authenticate cleanly once the published DKIM selector is live, so those clients tend to be the quickest to move off p=none; the DMARC for Google Workspace guide covers the setup. A common third source on many client domains is an SPF record that has quietly grown past the RFC 7208 limit of ten DNS lookups through stacked include: mechanisms, which causes a PermError and breaks SPF authentication entirely. It is worth running every client's SPF through the DNS lookup tool during onboarding so you catch it before it shows up as unexplained failures in the reports.

How does per-client RUA aggregation and white-label reporting work?

DMARC aggregate reports arrive as compressed XML attachments, sent at least daily by each receiving provider that processes your clients' mail. The format is defined in RFC 7489 Appendix C. A single MSP can receive thousands of these a month across a fleet, from dozens of distinct reporters, so the value is not in the parser, it is in the aggregation: deduplicating across reporters, enriching each source IP, joining the result against the sender inventory you built during the audit, and presenting one view per tenant.

A multi-tenant DMARC platform handles this by separating data per organisation. Each client gets its own dashboard scope, its own retention, and its own access control, while you keep a fleet-wide overview that ranks clients by risk. White-label reporting means the monthly report a client sees carries your branding, not the platform vendor's, so DMARC reads as part of your managed service rather than a third-party tool you resell. The artefacts that go into that report are consistent every month:

• The authentication pass rate for the period, split by SPF alignment and DKIM alignment, with the trend against prior months.
• The sender inventory: every source that sent as the client, flagged as a known authorised sender or a new unknown one.
• The current policy level and a clear statement of what stands between the domain and the next enforcement step.
• Any change events since the last report: a record that moved, a new sender that appeared, a spike in failing volume.

If you want to see the raw report structure before you commit a client to a platform, the free DMARC Report Viewer renders an individual aggregate XML file in a readable layout without uploading it to a server, and our guide to understanding DMARC reports explains every field you will be summarising for clients.

What does identifier alignment mean across client tenants?

Most failing-but-legitimate mail in a client's reports comes down to alignment, so it is worth being precise. DMARC passes when either SPF or DKIM passes and is aligned with the visible From: header domain. Per RFC 7489, identifier alignment means the RFC5322.From domain matches a domain authenticated by SPF or DKIM. There are two modes, and both default to relaxed.

Across a fleet the practical rule is to leave alignment at the relaxed default while a client is still on p=none and you are still discovering senders. Relaxed is forgiving of the subdomain patterns most providers use (a sending host like em.clientdomain.example still aligns with the parent), which keeps false failures down while you build the picture. Tighten to strict only on non-sending domains, where there is no legitimate sender to inconvenience. If you are explaining the underlying mechanisms to a client, the SPF vs DKIM vs DMARC guide walks through how the three records combine.

The failure pattern you will see most often in a client's reports is a third-party platform that sends on the client's behalf but signs with its own domain. A marketing or invoicing tool that sends from billing@clientdomain.example but DKIM-signs with d=mailer.thirdparty.example will pass DKIM as a signature yet fail DKIM alignment, because the signing domain and the header From domain do not share an Organizational Domain. The fix is not to weaken alignment; it is to have the client publish the platform's DKIM selector under their own domain (most platforms support a custom signing domain or branded sending) so the signature aligns. The reports tell you which sender this is by source IP and signing domain, which is why you reconcile against the sender inventory rather than guessing. A domain that fails DMARC purely on SPF but still passes through an aligned DKIM signature is fine to advance, because DMARC passes if either mechanism passes and aligns; that is a frequent and safe state for Microsoft 365 mail forwarded through a gateway.

How do I move client domains from p=none to p=reject safely?

The staged progression of none to quarantine to reject is the shared recommendation of every authority. In RFC 7489, p=none requests no action (monitoring), while quarantine asks receivers to treat failing mail as suspicious and reject asks them to reject it outright. The NCSC collection structures it as exactly that progression: publish p=none to monitor, move to quarantine once SPF and DKIM are correct and all legitimate senders are accounted for, then move to reject. The NCSC step pages give indicative timing of around six to eight weeks before leaving p=none and around three months from quarantine to reject, while noting the real duration depends on the size and complexity of the estate. M3AAWG is blunter: its best-practice checklist states that policy statements should be p=reject where possible and p=quarantine otherwise, and that p=none, sp=none and pct<100 should only be viewed as transitional states to remove as quickly as possible.

For an MSP, the discipline is that the advance is driven by the data, not the calendar. You move a client's domain to the next level when its aggregate reports show that every legitimate sender is authenticating and aligning, and the ShieldMarc readiness indicator confirms there are no unresolved failures left in the picture. A clean month of reports, not a date on a Gantt chart, is the trigger. Different clients will reach that point at different times, which is fine; the fleet view ranks them so you always know who is ready to advance.

One thing ShieldMarc deliberately does not recommend is ramping the pct= tag as a rollout strategy (for example stepping pct=25 then pct=50 up to 100). The tag does exist: RFC 7489 says pct= is the percentage of messages to which the policy is applied, and there is a subtle quirk where pct=50 at p=reject means half of failing mail is rejected and the rest is treated with the next lower policy (quarantine) rather than passed through cleanly, which makes the real-world behaviour hard to reason about. Percentage ramping leaves a window where some forged mail is still delivered and gives you a misleading sense of safety. M3AAWG itself classes pct<100 as a transitional state to remove quickly. The clean approach is report-driven: keep the policy honest at one level, confirm the data is clean, then move the whole domain to the next level. Our none to reject walkthrough and the report-reading guide cover the per-domain decision in full.

How do I prioritise which client domains to protect first?

You cannot push a hundred domains to enforcement in the same week, and you should not try. Rank the fleet by risk and work down the list. A workable order of priority for an MSP:

• Active sending domains with no enforcement. Clients sitting at p=none are sending real mail and blocking nothing. The audit put 24% of MSPs in this state on their own primary domain, so expect a meaningful chunk of any client base to be here. These are the highest impersonation exposure and the fastest wins.
• Exposed alternate and parked brand domains. The audit found 80% of MSPs leave an alternate domain unprotected. These are cheap to fix (publish p=reject with strict alignment, no monitoring period needed) and remove a whole class of lookalike spoofing.
• High-value or high-trust clients. Anyone who sends invoices, payroll, legal or finance mail is a payment fraud target. Prioritise them ahead of low-volume internal-only domains.
• Domains with a subdomain gap. A record at p=reject with sp=none leaves every subdomain unprotected. The Security Grade scoring flags an sp= weaker than p= as a distinct control failure for this reason.

The fleet-wide Security Grade gives you the objective ranking, and the Security Grade tool produces the same score per domain that the dashboard uses, so the number you quote a client matches the number they can verify themselves. Public sector clients are a category of their own: NHS trusts and other public bodies that relied on Mail Check need a like-for-like replacement, and our DMARC for NHS and UK public sector guide covers that persona specifically.

How does ShieldMarc pricing work for managing many client domains?

ShieldMarc is built and priced for UK MSPs and multi-domain IT teams. The honest signal of who it is for is the threshold of the first paid plan: it covers 25 domains, which makes it the wrong tool for a single small business and the right one for anyone managing a portfolio. The free Starter tier is a one-domain evaluator, not a home for a real deployment, so the pricing is structured around scale from the start.

The MSP plan's defining feature for cost control is brand domain grouping. TLD variants of a single brand count as one domain slot, so a client with acme.com, acme.co.uk and a parked acme.org consumes one of your 100 slots, not three. That matters precisely because the right thing to do is protect every alternate and parked domain, and a per-domain pricing model would punish you for doing the responsible thing. With grouping, locking down a client's whole brand estate at p=reject does not inflate the bill. The 100 slots plus 50-slot expansion buckets let you grow the book of business without renegotiating a contract for each new client.

On hosting and data residency: ShieldMarc is UK owned, EU hosted by default, with UK hosting available on request, which is the answer most UK procurement and public sector buyers are looking for. Full pricing across every tier is published in pounds on the pricing page, so you can build a predictable margin into your managed service rate without a sales call. For a feature-by-feature view against other platforms, see the best DMARC monitoring tools comparison.

What is the best free DMARC option for a single client domain?

Sometimes a client is genuinely a single small business with one domain, and an MSP plan is the wrong recommendation to make. Being honest about that builds trust. For a single non-business or small-business domain, the most established free monitoring options are EasyDMARC's free plan and dmarcian's free Personal plan for non-business use. ShieldMarc's own Starter tier also covers one domain free as an evaluator. Where ShieldMarc earns its place is the moment that single domain becomes a portfolio, or the client turns out to have the alternate and parked domains the audit shows most organisations forget. At that point the 25-domain Professional plan and the brand-grouped 100-slot MSP plan are the cost-effective answer, and the migration from a single-domain free tool is straightforward because the DNS records are the same.