UK MSP DMARC Audit: Q1 2026

This report presents the findings of an independent audit of DMARC (Domain-based Message Authentication, Reporting and Conformance) adoption across 192 UK-based Managed Service Providers (MSPs). Every domain included was confirmed to have a valid MX record, ensuring the results reflect genuine email security posture rather than dormant or web-only domains.

While 95% of surveyed MSPs were found to have published a DMARC record on their primary email domain, only 36% have progressed to full enforcement via p=reject. When a 20-point brand domain protection penalty is applied to providers whose alternate domain (typically the .co.uk or .com counterpart) lacks enforcement or remains unregistered, the adjusted industry average falls from 72 to 57 out of 100.

Only 18 of 192 MSPs (9%) achieved an Excellent rating after this adjustment, down from 56 (29%) on primary domain scoring alone. 80% of providers were found to have an unprotected or absent alternate domain, representing a significant and largely overlooked impersonation risk.

Regional disparities were observed, with Global multinationals averaging 76 (adjusted) and Northern Ireland trailing at 41. A strong correlation was identified between the use of third-party DMARC monitoring tools and the likelihood of reaching full enforcement: providers using dedicated monitoring platforms were more than twice as likely to have achieved p=reject compared to those self-reporting or not monitoring at all.

The audit was conducted in Q1 2026 using the ShieldMarc DMARC Health Checker. A total of 192 primary domains belonging to UK-based MSPs were selected from publicly available industry directories and rankings, including CRN UK, Cloudtango MSP Select, Clutch UK Rankings, the Oxygen 250, MSP Channel Awards shortlists, and GOV.UK MSP research publications.

Each domain was validated for the presence of a valid MX record prior to inclusion. Domains without MX records (indicating no active email infrastructure) were excluded to ensure the dataset reflects organisations that are genuinely sending and receiving email. Where an MSP's website domain was found to differ from their primary email-sending domain, the email-sending domain was used for primary scoring.

Selection Bias and Implications

It is important to note that this sample is drawn from curated industry directories, awards shortlists, and rankings. These sources inherently favour established, publicly visible, and often better-resourced MSPs. The dataset therefore represents a best-case cross-section of the UK MSP market, not a random sample. Providers that do not appear in any directory, do not compete for awards, or operate below the visibility threshold of industry publications are not represented here. If the most prominent MSPs in the country are averaging an adjusted score of 57 out of 100, with only 9% rated Excellent, the broader market is very likely performing worse. The findings in this report should be read with that context in mind.

Scoring Criteria

Primary scoring was performed across seven criteria on a 0-100 scale. The full point allocation for each setting is shown below:

A 5-point penalty was applied where forensic reporting (ruf=) was configured, due to GDPR and data privacy concerns associated with full email header and message content exposure in forensic reports.

SPF and Alignment: Active vs Parked Domains

The scoring model treats ~all and -all equally, and relaxed and strict alignment equally, because best practice differs by domain type. The NCSC's email security guidance^[14] recommends a phased approach where active sending domains use relaxed alignment and soft fail SPF to avoid disrupting legitimate mail, while parked or non-sending domains should use strict alignment and -all.

Brand Domain Protection Penalty (-20)

An additional 20-point penalty was applied where the MSP's alternate domain (typically the .co.uk counterpart of a .com, or vice versa) was found to lack DMARC enforcement. This penalty reflects the impersonation risk that arises when a publicly associated brand domain is left unprotected. The penalty was applied in three scenarios:

• Alternate domain exists with no DMARC: The domain resolves (A or MX records present) but has no DMARC record. An attacker can spoof emails from this domain.
• Alternate domain has DMARC at p=none: A record exists but provides no enforcement. Spoofed emails will still be delivered.
• Alternate domain is unregistered: The corresponding .co.uk or .com does not resolve, leaving it open for an attacker to register and use for impersonation.

The penalty was not applied where the alternate domain had DMARC set to p=quarantine or p=reject. It is acknowledged that in some cases, particularly with short or generic brand names, the alternate domain may belong to an entirely separate organisation. In such cases the penalty reflects brand proximity risk rather than a configuration failure by the MSP.

A Note on Scoring Integrity

A reasonable challenge to the findings of this report is whether the scoring model itself is responsible for the low adjusted averages. To address this directly: every MSP that scored 0 in this audit had no DMARC record whatsoever. The minimum possible primary score for a domain with any valid DMARC record, even the weakest possible configuration (p=none, no reporting, no SPF, with a forensic reporting penalty), is 21 out of 100. In practice, the lowest primary score observed for a domain with a DMARC record was 34. There is a clear gap between domains with no protection (0) and domains with even minimal configuration (34+). The penalties in this model (ruf and brand domain) can reduce a score but cannot, in the observed data, produce a zero from a valid configuration. The scoring model rewards genuine protection and penalises real risk; low scores reflect low posture, not a punitive methodology.

All scores presented in this report are adjusted scores unless otherwise noted. Regional mapping was based on Companies House registrations and publicly listed office locations. Only public DNS records (DMARC TXT, SPF TXT, MX) were queried. No emails were sent or intercepted during the audit.

At a headline level, 95% of surveyed MSPs were found to have published a DMARC record on their primary email domain. This figure compares favourably with broader industry benchmarks. PowerDMARC's 2026 UK analysis of 875 domains across multiple sectors found DMARC adoption at 86.4%^[1], while Proofpoint reported 72% adoption among FTSE 100 and FTSE 250 companies^[2]. At a global level, Red Sift's analysis of 73.3 million domains found that only 14.9% had any DMARC policy at all^[3]. However, the presence of a DMARC record alone does not equate to protection.

Of the 192 MSPs surveyed, 183 (95%) had published a DMARC record. Among those with a record, 69 (38%) have adopted the strongest policy, p=reject, which instructs receiving mail servers to discard unauthenticated messages entirely. This is notably higher than Red Sift's global finding of roughly 2.5% at p=reject^[3], and broadly comparable to dmarcian's finding of 46% enforcement among UK higher education institutions^[4]. A further 67 (37%) use p=quarantine, and the remaining 47 (26%) are on p=none, a monitoring-only mode that takes no action on failing messages.

After applying the brand domain protection penalty, the adjusted score distribution shifts significantly. The number of Excellent-rated MSPs falls from 56 to 18, and the number of Critical-rated providers rises from 9 to 11 as the penalty pushes borderline MSPs below the threshold. The adjusted industry average is 57 out of 100.

One of the most significant and least discussed findings of this audit concerns the protection of alternate brand domains. For UK-based MSPs, this typically means the .co.uk and .com pair: an MSP operating from example.com will almost certainly have clients, partners, and suppliers who also associate them with example.co.uk, and vice versa.

If an MSP achieves a perfect DMARC configuration on their primary email domain but leaves the alternate domain unprotected, the security benefit is significantly undermined. An attacker can simply spoof the alternate domain instead. A phishing email sent from [email protected] will be just as convincing to a recipient as one from [email protected], particularly if the MSP is publicly known by both identities.

Each MSP's alternate domain was checked for the presence of a DMARC record with enforcement. Where the MSP's primary domain was a .com, the .co.uk was checked, and vice versa. For other TLDs, the .co.uk equivalent was checked.

The results are stark: only 20% of UK MSPs properly protect both their primary and alternate domains. The remaining 80% have at least one publicly associated domain that can be freely spoofed by an attacker.

Attackers do not care whether the “real” domain is example.co.uk and the unprotected one is example.com, or vice versa. A phishing email sent from the alternate TLD is highly credible to the recipient because the brand name is identical and most people do not scrutinise the domain suffix. This makes unprotected alternate domains a low-effort, high-reward attack vector. The NCSC's own email security guidance states that organisations should “protect all of your organisation's domains”^[17], yet our audit shows the majority of UK MSPs are not doing so.

The most common failure (61%) is the simplest: the alternate domain exists, often with active MX records and a web presence, but has no DMARC record at all. Several providers that scored in the top tier on their primary domain were found to have alternate domains with active mail infrastructure and zero email authentication. In these cases, the provider has invested significant effort in configuring DMARC on one domain while leaving the other completely exposed.

A further 7% of MSPs were found not to have registered their alternate domain at all. In these cases, there is nothing preventing a third party from registering the domain and using it for targeted phishing attacks against the MSP's clients. Beyond exact TLD variants, attackers also register lookalike domains using character substitution, homoglyphs, and keyword squatting. Our free Lookalike Domain Scanner can identify these typosquatting threats for any domain.

It is acknowledged that for MSPs with short or generic brand names, the alternate .com or .co.uk may be owned by an entirely separate organisation. In such cases the penalty reflects brand proximity risk: a recipient receiving email from the alternate domain may reasonably associate it with the MSP, regardless of actual ownership.

Domains that do not actively send email should still publish a restrictive DMARC record. The recommended configuration for a non-sending domain is:

This instructs all receiving servers to reject any email claiming to originate from the domain. Combined with the absence of MX records, this effectively locks the domain down against spoofing with no risk of disrupting legitimate mail.

Organisations that already use a DMARC monitoring tool should also add a rua=tag to the non-sending domain's record, pointing to the same reporting destination as their primary domain. This provides visibility into spoofing attempts targeting the alternate domain. For organisations without a parsing tool, the rua tag is unnecessary: since the domain has no MX record and no legitimate senders, there is no need to distinguish between authentic and fraudulent mail. The reject policy handles everything.

DMARC defines three policy levels. The NCSC's email security guidance^[14] recommends a phased progression from p=none through to p=reject. In the US, CISA's Binding Operational Directive 18-01^[15] mandated all federal agencies reach p=reject within one year. Since February 2024, Google and Yahoo require all bulk senders to have DMARC in place, with non-compliant mail subject to rejection^[16].

Percentages shown are of the 183 MSPs with a DMARC record.

Only 38% of MSPs with a DMARC record have reached the NCSC's recommended end state of p=reject. A further 26% remain on p=none, a monitoring-only mode that provides zero protection against spoofing. The data suggests the primary barrier to enforcement is not technical complexity but insufficient visibility into the sending ecosystem, a finding corroborated by the monitoring tool correlation discussed later in this report.

A common finding across underperforming MSPs was the presence of a dedicated email security gateway alongside weak or absent DMARC configuration. This pattern reveals a fundamental misunderstanding of the threat model that DMARC addresses.

Email security gateways operate primarily on inbound mail. They filter spam, scan attachments for malware, and block known phishing URLs. However, they do not address outbound impersonation. DMARC operates in the opposite direction, protecting the domain's reputation by instructing receiving mail servers how to handle messages that claim to be from the domain but fail authentication.

MX Record Distribution

Among the 24 MSPs that scored Poor or Critical on their primary domain, several were found to be routing mail through a dedicated email security gateway. Two providers in the Critical tier (scoring 0/100) were paying for dedicated gateway services while having no DMARC record whatsoever. These organisations had invested in filtering inbound threats but had done nothing to prevent outbound impersonation.

Gateway investment and DMARC enforcement address different threat vectors and are not substitutes for one another. An MSP with a best-in-class inbound filter but no DMARC enforcement remains vulnerable to having its domain used in phishing attacks against its own client base.

The Inbound Consequence of Outbound Spoofing

There is, however, a less obvious relationship between outbound domain spoofing and inbound threat volume that may partly explain the observed pattern. When a domain lacks DMARC enforcement, it can be freely spoofed in phishing and spam campaigns. That spoofing creates a measurable inbound problem for the spoofed organisation itself, through several well-documented mechanisms.

The most established of these is backscatter. When spoofed emails are sent to invalid recipients, the receiving mail servers generate Non-Delivery Reports (NDRs) and bounce them back to the forged sender address. For a domain with no DMARC enforcement, a single spam campaign can trigger thousands or millions of bounce-back messages flooding the organisation's own mail infrastructure. Microsoft has built dedicated backscatter filtering into Exchange Online Protection^[8], and Backscatterer.org maintains a dedicated DNS blocklist specifically for servers generating backscatter^[9], which itself speaks to the scale of the problem.

Beyond backscatter, spoofed organisations face reputational blowback. Recipients of phishing emails frequently report the apparent sender to abuse desks, ISPs, and blocklist operators such as Spamhaus, SURBL, and Barracuda. This can result in the spoofed domain being added to DNS-based blocklists (DNSBLs), which then causes the organisation's own legitimate outbound email to be rejected by other mail servers. The phenomenon has a name dating back to 1997: a Joe Job, after a documented case where forged spam headers caused an innocent domain owner to receive a flood of angry replies, abuse complaints, and eventual blocklisting^[10].

These effects are well-documented in industry research from Proofpoint^[11], APWG^[12], and Agari (now Fortra)^[13]. The result is a self-reinforcing cycle: an MSP without DMARC enforcement has its domain spoofed, generating backscatter, abuse reports, and blocklist entries that arrive as inbound threats. The organisation invests in a gateway to filter this inbound noise, while never addressing the outbound spoofing that caused it. The gateway treats the symptoms; DMARC enforcement would address the cause.

It should be noted that this is an observed correlation, not a proven causal relationship within this dataset. The audit did not measure inbound threat volumes or backscatter rates for the surveyed MSPs. However, the mechanisms are well-established in email security literature, and the pattern of gateway-without-DMARC observed among the 58 MSPs rated Poor or Critical (adjusted) is consistent with organisations responding to symptoms of domain abuse without understanding, or addressing, the root cause.

Each MSP in the audit was mapped to its UK headquarters region. The results below show adjusted average scores (including the brand domain protection penalty), sorted from highest to lowest.

Global Multinationals (Adj. Avg: 76)

MSPs with headquarters outside the UK performed strongest on average, benefiting from dedicated security teams and compliance programmes that mandate DMARC enforcement. Several global providers also demonstrated best practice by protecting both their .com and .co.uk domains with enforcement-level DMARC. However, the group is not without outliers: one of the largest IT services companies globally scored just 51 on its primary domain before the brand penalty was applied.

Wales (Adj. Avg: 67)

With only two MSPs in the sample, Wales represents a small dataset. Both providers have DMARC enforcement in place on their primary domain but were penalised for unprotected alternate domains, pulling the adjusted average to 67.

Northern Regions (Adj. Avg: 58-61)

The North West (61), South West (60), North East (60), and Scotland (58) each demonstrated similar adjusted averages. All four regions benefit from a mix of providers with strong primary domain configurations, but the brand domain penalty significantly reduced scores across the board. In several cases, regional leaders with primary domain scores above 90 were penalised for unprotected alternate domains.

London (Adj. Avg: 60)

Despite containing the largest concentration of MSPs in the dataset (40 providers), London recorded an adjusted average of 60. The region contains both top-scoring providers and some of the weakest. Five of the eighteen MSPs that achieved an Excellent adjusted rating are London-based, demonstrating that strong practice exists in the capital. However, London also accounts for a disproportionate share of Critical-rated providers.

South East (Adj. Avg: 53)

The South East (40 MSPs) fell from a primary average of 68 to an adjusted average of 53. As the equal-largest region in the dataset alongside London, the South East has a high concentration of Poor-rated MSPs, and the brand domain penalty compounded existing weaknesses. Proximity to a well-connected technology hub does not appear to correlate with good email security practice.

Midlands and East of England (Adj. Avg: 47-54)

The West Midlands (54), East Midlands (52), and East of England (47) all cluster in the lower half of the table. The East of England recorded the largest percentage drop of any region, reflecting widespread failure to protect alternate domains. The East Midlands had the highest ratio of Poor-rated MSPs relative to its sample size.

Yorkshire and Humber (Adj. Avg: 42)

Yorkshire underperformed at an adjusted average of 42. The region is characterised by a wide spread between its strongest and weakest providers. The brand domain penalty further depressed scores across the region.

Northern Ireland (Adj. Avg: 41)

Northern Ireland recorded the weakest adjusted regional average. Three of its eight MSPs scored Critical on their primary domain (zero DMARC protection), accounting for a disproportionate share of all Critical-rated domains in the audit despite the region representing just 4% of the sample. This finding is of particular concern given Northern Ireland's growing technology sector and its reliance on MSPs for cybersecurity support.

One of the most significant findings of this audit concerns the relationship between DMARC monitoring practices and enforcement outcomes. Each MSP's aggregate reporting (rua) destination was categorised into three groups: those using a third-party DMARC monitoring tool, those self-reporting to an inbox on their own domain, and those with no reporting configured at all.

Primary domain policy shown. Where an MSP directed reports to multiple destinations spanning both a third-party tool and their own domain, the third-party tool categorisation was used.

MSPs using a dedicated third-party monitoring platform were twice as likely to have reached p=reject (54%) compared to those self-reporting (26%), and eighteen times more likely than those with no reporting (3%). Conversely, 72% of MSPs with no reporting at all fell into the Poor or Critical categories.

However, the full policy breakdown reveals a more encouraging picture than the headline enforcement figures suggest. Half of all self-reporting MSPs (50%) have progressed to p=quarantine, meaning the majority have moved beyond monitoring-only and are actively on the path toward full enforcement. Crucially, the proportion remaining at p=none is similar across both groups (19% for tool users vs 24% for self-reporters), suggesting that the presence of a monitoring tool does not prevent stalling at none, but rather accelerates the final step from quarantine to reject.

Across both groups combined, 76% of MSPs with any form of reporting have moved beyond p=none. This is a strong indicator that the UK MSP market is actively maturing its DMARC posture, not simply publishing records and forgetting about them. The 81% of third-party tool users who have progressed to quarantine or reject are particularly likely to continue advancing: they have committed budget to DMARC visibility, creating a financial incentive to reach enforcement and extract value from the investment.

Self-reporters at quarantine face a different challenge. Without parsed report data, they lack the visibility to confidently make the final move to reject, and without a subscription cost, there is less urgency to progress. DMARC aggregate reports are delivered as XML files, typically compressed and attached to emails. Without a tool to parse, aggregate, and visualise this data, the reports are effectively unreadable. EasyDMARC's 2025 global adoption report, presented at Black Hat Europe, found that over 70% of DMARC-enabled domains worldwide lack an RUA tag entirely^[5]. Among UK MSPs, 85% do configure reporting, but where those reports are directed and whether they are actively processed determines whether the organisation can progress beyond quarantine.

When Reporting Is (and Isn't) Worth the Effort

For a non-sending domain already at p=reject, the policy itself does the work and aggregate reports add limited value without a parsing tool. However, if the organisation already uses a monitoring platform, adding a rua= tag is zero-effort and provides visibility into spoofing attempts. The scoring model awards 10 points for reporting presence as an indicator of mature DMARC management, but acknowledges that its absence on a locked-down non-sending domain is not a material security gap.

Most Popular Monitoring Tools

Some MSPs direct aggregate reports to more than one platform and appear in multiple rows. The total above therefore exceeds the 93 unique MSPs categorised as third-party tool users in the monitoring correlation table.

Tool selection was observed to correlate with existing security stack. Proofpoint users tended to be existing Proofpoint email gateway customers. Smaller MSPs gravitated toward standalone platforms such as EasyDMARC, Cloudflare, or Sendmarc that offer simpler onboarding. DMARC Analyzer (acquired by Mimecast) was the most widely adopted, reflecting Mimecast's strong presence in the UK MSP market.

It is worth noting a limitation specific to Cloudflare DMARC Management in the MSP context. Cloudflare's DMARC reporting is scoped to domains within the user's own Cloudflare account. For an MSP monitoring its own primary and brand domains, this works well and at no additional cost. However, MSPs that manage email security for client organisations will not have visibility into client DMARC reports unless those client domains are onboarded into the MSP's own Cloudflare tenant. In practice, most client domains are either managed through the client's own Cloudflare account, hosted with a different DNS provider entirely, or use Microsoft 365 or Google Workspace DNS directly. This means that an MSP relying on Cloudflare for DMARC monitoring is likely only seeing reports for its own domains, not the client domains it is responsible for protecting. For the 9 MSPs in this audit using Cloudflare, the tool may be serving the MSP's own domain well, but it is unlikely to be providing the multi-tenant visibility that an MSP managing client email security actually needs.

The Cost Barrier to Monitoring

A factor that is rarely discussed in DMARC adoption literature, but is clearly visible in the data, is cost. The majority of DMARC monitoring platforms charge per domain. For an MSP managing its own primary domain alone, the expense is trivial. But the moment brand domain protection enters the picture, costs multiply. An MSP with a .com and a .co.uk, plus a legacy domain, plus a handful of client domains they manage on behalf of customers, can quickly find itself paying for 10, 20, or 50 domain slots across its monitoring tool.

This per-domain pricing model creates a perverse incentive. It discourages MSPs from monitoring the very domains that need it most: non-sending brand domains, legacy domains, and alternate TLDs that exist only as impersonation targets. These domains generate minimal report volume (often zero), yet they consume a paid domain slot on most platforms. The result is that MSPs either leave them unmonitored, or more commonly, never add them to their DMARC configuration at all. The 80% of MSPs in this audit with an unprotected alternate domain may reflect this economic reality as much as any technical oversight.

The cost of popular tools varies widely. Entry-level plans typically start at £80-160/month for 10 domains, with enterprise tiers running to £400/month or more. For a small MSP operating on tight margins, that is a significant overhead for a control that produces no visible output for the customer. Unlike a firewall dashboard or an endpoint protection console, DMARC monitoring is invisible to the client until something goes wrong. This makes it a difficult line item to justify, particularly when the MSP is already paying for an email security gateway that feels like it should be enough.

Some platforms have begun to address this. Cloudflare offers basic DMARC management at no cost (though with limited reporting depth). ShieldMarc, the tool used to conduct this audit, does not count inactive domains (those with no MX record and a secure DMARC policy) against the domain limit on Professional and MSP plans, meaning an MSP can monitor an unlimited number of non-sending brand and legacy domains at no additional cost. This pricing model directly targets the brand domain protection gap identified in this report: if adding a defensive domain costs nothing, the economic barrier to protecting it disappears.

To put the cost disparity in perspective: ShieldMarc's MSP plan, which includes 100 domain slots (with TLD variants of the same brand counted free under the brand protection promise), unlimited team members, DMARC reporting with staged advancement, SSL and DNS monitoring, uptime monitoring, and DMARC health auditing, is priced at £129/month (£99/month billed annually). Additional domain slots are available in buckets of 50 for £39.99/month each, with no upper limit. A comparable tier from established competitors typically starts at £240-400/month and may still impose per-domain limits. ShieldMarc's Professional plan at £69/month (£49/month billed annually) covers 25 active domains with unlimited inactive domains, providing more capacity than many competitors' entry-level offerings at a fraction of the cost. At these price points, the economic argument against monitoring client domains largely disappears.

DMARC as a Revenue Opportunity for MSPs

The cost discussion has so far focused on DMARC monitoring as an expense. But for MSPs, it can equally be positioned as a billable service. An MSP that deploys DMARC enforcement across its client base, monitors aggregate reports, and provides ongoing policy management is delivering a measurable security improvement that clients are willing to pay for. Email security is increasingly a procurement requirement, particularly for organisations working with the public sector, regulated industries, or supply chains governed by frameworks such as Cyber Essentials.

An MSP paying £129/month for 100 domain slots (expandable in buckets of 50) can distribute that cost across its client base and bill per-client for DMARC management as a line item. At even a modest per-client charge, the service becomes margin-positive from the first handful of clients. The MSP gains a recurring revenue stream, the client gains verifiable email protection, and the tool provides the reporting and dashboards to demonstrate ongoing value. Features such as SSL monitoring, DNS change detection, uptime monitoring, and scheduled compliance reports extend the proposition further, giving the MSP a broader managed security offering built on a single platform.

The broader point is that the DMARC monitoring market has, until recently, been priced for large enterprises with dedicated security budgets. MSPs, particularly smaller providers managing a handful of their own domains alongside client work, have been underserved. Any serious effort to improve DMARC adoption in the MSP sector will need to account for the economics of monitoring, not just the technical configuration. When the tooling is affordable enough to make DMARC management profitable rather than a cost centre, the incentive structure changes entirely.

The findings of this audit carry implications beyond the MSPs themselves. Managed Service Providers occupy a position of trust in the IT supply chain: they hold elevated access to client networks, manage security tooling on behalf of their customers, and communicate with those customers via email as a matter of routine.

The UK National Cyber Security Centre (NCSC) has repeatedly warned about supply chain attacks targeting managed service providers^[6]. In such attacks, the MSP is compromised (or impersonated) as a vector to reach the MSP's downstream clients. Email spoofing is one of the simplest and most effective methods available to an attacker in this scenario. The timing of this audit is also notable: the NCSC's Mail Check service, which monitored DMARC compliance for thousands of public sector organisations, was retired in March 2026^[7], shifting the responsibility for DMARC monitoring back to individual organisations and their MSPs.

An MSP without DMARC enforcement presents a tangible risk to its client base. An attacker can craft emails that appear to originate from the MSP's domain, requesting password resets, invoice payments, software installations, or access credentials. Without p=reject, these emails will be delivered to the recipient's inbox as though they are genuine.

The brand domain protection findings add a further dimension. Even MSPs that have fully locked down their primary email domain may be exposing their clients to impersonation risk through an unprotected alternate domain. A phishing email from the .co.uk variant of a well-known .com MSP brand is just as credible to a recipient.

This risk is compounded by a common marketing practice: many MSPs publicly list their clients on their websites, publish case studies detailing the services they provide, and display client logos on their homepage. From an attacker's perspective, this is a ready-made target list. If the MSP's domain can be spoofed, the attacker knows exactly who trusts that brand, what services the MSP provides to each client, and can craft highly targeted phishing emails referencing real engagements. A spoofed email reading “your annual security review is due” or “please approve the attached invoice for this month's managed services” becomes almost indistinguishable from a legitimate communication when sent from a domain the client recognises and the context matches a real service relationship.

For organisations that rely on MSPs for their IT security, the audit data suggests several questions worth raising with providers:

• What DMARC policy is published on your primary email domain?
• Is DMARC enforcement also in place on your alternate brand domains (.co.uk and .com)?
• Are you using a dedicated DMARC monitoring tool to parse aggregate reports?
• Is your SPF record configured with ~all (soft fail) on active domains and -all (hard fail) on non-sending domains?
• Do you have a subdomain policy (sp=reject) in place?
• What DMARC enforcement level do you recommend and deploy for your clients' domains?

The credibility gap between an MSP advising its clients to adopt DMARC enforcement while failing to enforce it on its own domains is difficult to overlook.

The NCSC Mail Check Retirement and What It Means for MSPs

The timing of this audit coincides with a significant shift in the UK's DMARC monitoring landscape. The NCSC's Mail Check service, part of the Active Cyber Defence programme, provided free DMARC monitoring and compliance reporting for over 2,400 public sector organisations since its launch. In March 2026, the NCSC retired Mail Check's DMARC and TLS reporting features^[7], leaving thousands of organisations without the DMARC monitoring tool they had relied on.

For public sector bodies and the MSPs that support them, this has created an immediate gap. Mail Check provided aggregate report parsing, policy compliance tracking, and actionable guidance at no cost. Organisations that had configured their rua= tags to point at Mail Check have now lost visibility into their DMARC reporting entirely unless they have migrated to an alternative DMARC monitoring tool. Those that have not acted are effectively flying blind: their DMARC records may still exist, but no one is reading the reports.

This is particularly relevant to the MSP sector. Many UK MSPs serve public sector clients, including local authorities, NHS trusts, educational institutions, and government-adjacent bodies that were covered by Mail Check. With the NCSC stepping back from direct DMARC monitoring, the responsibility shifts to these organisations and, in many cases, to the MSPs they rely on for IT security. An MSP that previously pointed its public sector clients at Mail Check now needs to offer a replacement, or accept that those clients will have no DMARC monitoring at all.

The retirement has also removed a compliance backstop. Mail Check did not just parse reports; it flagged organisations that had not progressed beyond p=none, providing a form of external accountability. Without that oversight, the risk is that domains currently at p=none or p=quarantine will stall indefinitely, with no mechanism prompting the organisation or its MSP to enforce.

For organisations evaluating NCSC Mail Check alternatives, the key requirements are: aggregate report (RUA) parsing with human-readable dashboards, policy progression guidance, support for multiple domains (including non-sending and brand protection domains), and, for MSPs, multi-tenant management so that client domains can be monitored from a single account. Several commercial platforms offer these capabilities, including those listed in the monitoring tools section of this report. ShieldMarc was designed with this use case in mind, offering a staged DMARC advancement workflow, unlimited inactive domain monitoring, and multi-domain management suitable for MSPs and IT teams managing DMARC on behalf of others. For a step-by-step migration walkthrough, see our guide to the NCSC Mail Check retirement.

The Multiplier Effect: MSP Posture and Global DMARC Adoption

Red Sift's analysis of 73.3 million domains found that only 14.9% have any DMARC policy at all, and roughly 2.5% have reached p=reject^[3]. These numbers are often cited as evidence of a broad awareness gap, but the findings of this audit suggest a more structural explanation. MSPs are the organisations most commonly responsible for deploying and managing email security on behalf of others. If MSPs themselves are averaging an adjusted score of 57 out of 100 on their own domains, the question of what they are deploying for their clients becomes unavoidable.

The data in this report points to a compounding failure across the supply chain. First, many MSPs have not achieved enforcement on their own primary domain. Second, the cost of DMARC monitoring tools creates a barrier to scaling beyond the MSP's own domains. Per-domain pricing means that an MSP managing 50 client domains faces a significant monthly expense to monitor them all, with no visible return for the client. Third, the most common cost-free alternative, Cloudflare DMARC Management, is scoped to the MSP's own Cloudflare account and does not provide visibility into client domains hosted elsewhere. Fourth, 35% of MSPs in this audit are self-reporting DMARC data to their own inbox, meaning the XML reports are almost certainly going unread, both for the MSP's own domain and for any client domains configured the same way.

The result is a multiplier effect. Each underperforming MSP is not a single unprotected domain. It is an organisation responsible for the email security of dozens, sometimes hundreds, of downstream client domains. If the MSP has not invested in a monitoring tool that can handle multiple domains, has not progressed its own policy beyond p=none, and is relying on a free tool that only covers its own infrastructure, it is reasonable to assume that client DMARC is either not being deployed at all, or is being deployed at p=none with no path to enforcement. This pattern, replicated across thousands of MSPs globally, would contribute meaningfully to the adoption gap that Red Sift and others have documented.

Put differently: global DMARC adoption may be low not because organisations are unaware of DMARC, but because the providers they rely on to implement it are themselves struggling with cost, tooling, and operational maturity. Fixing DMARC adoption at the MSP level has the potential to improve posture not just for 192 providers, but for the thousands of client domains they collectively manage.

The recommendations below follow the NCSC's email security and anti-spoofing guidance^[14], which outlines a phased progression toward p=reject. This approach is consistent with CISA BOD 18-01^[15] and the bulk sender requirements enforced by Google and Yahoo since February 2024^[16].

• No DMARC record: Publish a record immediately at p=none with a rua= tag pointing to a monitoring service.
• On p=none: Review aggregate reports, identify all legitimate senders, set sp=reject immediately (most subdomains do not send mail), then progress the parent policy to p=quarantine and then p=reject.
• On p=quarantine: Set pct=100 and establish a timeline for p=reject.
• On p=reject: Ensure sp=reject is set and aggregate reporting is active and directed to a monitoring platform.
• Brand domains: Audit all publicly associated domains (.co.uk/.com variants, legacy domains). Non-sending domains should publish p=reject; sp=reject and v=spf1 -all. Unregistered alternates should be registered defensively. Use a lookalike domain scanner to identify typosquatting threats beyond TLD variants.
• Forensic reporting (ruf): Avoid unless specifically required. Forensic reports can expose full email headers and content, creating GDPR risk.

The UK MSP sector has made meaningful progress in DMARC adoption on primary email domains, with 95% of providers publishing a record. However, the gap between having a DMARC record and achieving comprehensive brand protection is substantial. When alternate domain protection is factored in, only 9% of MSPs achieve an Excellent rating.

The data points to two critical enablers of strong email security posture. First, monitoring: providers using dedicated DMARC monitoring tools were more than twice as likely to have reached p=reject compared to those relying on self-reporting. Encouragingly, 76% of MSPs with any form of reporting have already moved beyond p=none, with half of all self-reporters now at quarantine, indicating a market actively progressing toward enforcement rather than stalling. Second, domain hygiene: the 20% of MSPs that protected both their primary and alternate domains demonstrated a fundamentally more mature approach to brand security.

Regional disparities, while present, are less significant than the operational factors that determine enforcement outcomes. Whether an MSP invests in report parsing, understands the distinction between inbound filtering and outbound authentication, and commits to protecting all publicly associated domains are far stronger predictors of posture than geographic location.

For the downstream clients of these MSPs, the findings underscore the importance of verifying provider claims around email security. A DMARC record on a single domain is not comprehensive protection. The policy behind it, the monitoring practices that support it, and the consistency of protection across all brand-associated domains are what determine whether an MSP's identity can be weaponised against its own clients.

This Q1 2026 audit is the first in a quarterly series. Starting in Q2 2026, ShieldMarc will publish updated results each quarter, tracking how the UK MSP sector's email security posture evolves over time. Each edition will re-scan every provider, capture new entrants, and highlight quarter-on-quarter changes in DMARC policy adoption, enforcement rates, and brand domain protection.

Expanding the dataset

The current dataset of 192 providers represents a meaningful cross-section, but the UK MSP market is far larger. We are actively working to expand coverage and include more UK-based MSPs in each subsequent quarterly audit. If your organisation is a UK MSP and you would like to be included, or if you know of providers we should add, we welcome that input.

Engaging with the sector

We want this research to be useful to the MSPs it covers, not just about them. We are looking to engage directly with UK MSPs for their perspective on email security challenges, DMARC deployment barriers, and what they would find most valuable in these reports. Whether it is additional metrics, deeper regional breakdowns, or practical implementation guidance, we want to hear from the people on the front line.

If you are an MSP and would like to contribute your thoughts, flag corrections, or discuss the findings, please reach out at [email protected].

Looking ahead: MTA-STS

DMARC addresses domain spoofing, but it does not protect the transport layer. MTA-STS (Mail Transfer Agent Strict Transport Security) is an emerging standard that enforces TLS encryption for email delivery, preventing downgrade attacks and man-in-the-middle interception. Adoption of MTA-STS among UK MSPs remains negligible, but as email security requirements tighten, it is expected to become the next frontier. Future editions of this audit will track MTA-STS adoption alongside DMARC enforcement.