DEV Community: SealedMail

DMARC for law firms: protecting client money from email fraud

SealedMail — Mon, 22 Jun 2026 06:33:02 +0000

The most expensive cybercrime in the legal sector does not involve breaking into anything. It involves an email that looks like it came from your firm, sent to a client at the worst possible moment - typically a Friday afternoon before completion, with "updated" bank details for the deposit.

The Solicitors Regulation Authority (SRA) has reported that email hacks of conveyancing transactions are the most common cybercrime in the legal sector, with £7m of client losses reported in a single year (SRA risk outlook, 2016 figures, via Legal Futures). The SRA's own analysis found the majority of cyber fraud in the sector is "Friday afternoon fraud", and email modification fraud accounts for a large share of cases. A 2018 NCSC and Law Society report found three in five firms had experienced a security incident, with one partner receiving more than 11,500 phishing emails in a single month.

The consequences land on the firm, not just the client. The Solicitors Disciplinary Tribunal has fined solicitors over these incidents - in one case £26,000, after more than £290,000 of client money was transferred to a fraudster.

This post explains where Domain-based Message Authentication, Reporting and Conformance (DMARC) fits into that picture - honestly, including what it does not do.

How the fraud works

In a typical conveyancing diversion, the criminal needs one thing: an email to the client that appears to come from the firm. There are three ways to get it:

Exact-domain spoofing. The email genuinely shows yourfirm.co.uk in the From address. No hacking required - email's original design lets anyone claim any sender address, unless the domain owner has published controls that say otherwise.
Look-alike domains. The criminal registers yourf1rm.co.uk or yourfirm-conveyancing.co.uk and hopes nobody looks closely.
Account takeover. The criminal compromises a real mailbox - at the firm or at the client - and joins the genuine email thread.

DMARC addresses the first of these completely, and gives you intelligence on attempts. It does not address the second or third - anyone telling you otherwise is overselling. But the first category is the cheapest and most scalable attack, which is exactly why it is common: a fraudster can spoof an unprotected domain at scale, for free, with no compromise of any system.

What DMARC does for a law firm

DMARC lets your firm publish a public instruction to every receiving mail server: if an email claims to be from our domain and cannot prove it, reject it. Once your policy reaches enforcement (p=quarantine or p=reject), a spoofed email from yourfirm.co.uk simply does not reach the client's inbox.

Just as importantly, DMARC sends you reports. Every day, providers such as Google and Microsoft report back on every message they saw claiming to be from your domain - where it came from and whether it authenticated. For a law firm, those reports answer questions your compliance file currently cannot:

Is anyone, anywhere, sending email pretending to be us?
Are our own systems - case management, e-signature platforms, billing software - sending email that authenticates correctly, or is legitimate client correspondence at risk of landing in spam?
Can we evidence, in writing, that we monitor this?

That last point matters more than it used to. Professional indemnity insurers increasingly ask about email authentication controls at renewal, and client due-diligence questionnaires from commercial clients routinely include them.

What the SRA actually says

Precision matters here, because overstated compliance claims help nobody. The SRA does not mandate DMARC. What is true, and verifiable:

The SRA Code of Conduct for Firms requires effective governance, risk and compliance arrangements (paragraphs 2.1 and 2.5), and the confidentiality duties in paragraphs 6.3 and 6.4 - alongside Principle 7 - underpin firms' information security obligations.
The SRA's published cyber security guidance and thematic reviews explicitly reference DMARC as an NCSC-recommended control.
The Law Society's cyber security guidance points firms in the same direction.

So the honest framing is: DMARC is a recommended control within SRA and Law Society cyber guidance, and implementing and monitoring it is consistent with your obligations under the Code. If a regulator or insurer ever asks what reasonable steps the firm took against email impersonation, a DMARC policy at enforcement plus weekly monitoring reports is a concrete, documented answer.

What it does not do - said plainly

It does not stop look-alike domain fraud. Client education and transaction verification procedures (calling on a known number before transferring funds) remain essential.
It does not stop account takeover or thread hijacking. Strong authentication on mailboxes addresses that.
It does not guarantee deliverability of your legitimate email, although fixing the authentication failures DMARC reporting reveals usually improves it.

DMARC is one layer - the layer that removes the cheapest attack entirely and gives you visibility you otherwise lack.

Where most firms actually are

In our experience, a typical small firm's domain falls into one of three states: no DMARC record at all; a record at p=none added by a web developer years ago, with reports going nowhere; or a record whose reporting address points at the NCSC's Mail Check service, which was retired on 31 March 2026 and no longer receives anything.

All three states look fine from the inside. All three provide no protection and no visibility. The starting point is simply finding out which state your domain is in - and if you have a DMARC record sitting at p=none, read Why DMARC p=none is not protecting you next.

A practical first step

SealedMail's Free Domain Health Check audits your firm's SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI and blacklist status, and emails you a clear, scored certificate you can put straight into your compliance file. No sign-up, no obligation, no sales call.

If the firm then wants the ongoing monitoring handled, SealedMail receives and interprets your DMARC reports and sends a weekly plain-English summary - written for a practice manager or COLP, not an IT department - for £39 per domain per month. For the wider picture on how these frauds operate, see Business email compromise: what UK firms need to know and our plain-English guide, What is DMARC?.

Start your free health check →

Sources and further reading

Originally published at sealedmail.co.uk.

What is DMARC? A plain-English guide

SealedMail — Sun, 21 Jun 2026 06:30:03 +0000

Anyone can send an email that claims to be from your domain. That is not a flaw in your email provider - it is how email was designed in the 1980s, when nobody imagined it would carry invoices, payroll instructions and client funds.

Domain-based Message Authentication, Reporting and Conformance (DMARC) is the standard that fixes this. It lets you publish a public instruction telling every mail server in the world what to do with email that claims to come from your domain but cannot prove it - and it sends you reports about everything they see.

This guide explains how it works, what the three policy levels mean, and why the reporting side of DMARC matters as much as the policy side.

The problem DMARC solves

When an email arrives at, say, a Gmail inbox, Google needs to decide whether the sender is genuine. Two older standards help with this:

SPF (Sender Policy Framework) is a list, published in your domain's DNS, of the servers allowed to send email for your domain.
DKIM (DomainKeys Identified Mail) is a cryptographic signature attached to each message, proving it came from your domain and was not altered in transit.

Both are useful, and both have gaps. SPF checks a hidden technical address, not the "From" address your recipient actually sees. DKIM only helps if the receiving server knows what to do when a signature is missing. Crucially, neither tells receiving servers what action to take when checks fail - and neither tells you anything at all.

DMARC closes both gaps. It ties SPF and DKIM to the visible From address (this matching is called alignment), tells receivers what to do with failures, and creates a feedback loop of reports back to the domain owner.

How DMARC works, step by step

You publish a DMARC record in your domain's DNS - a single line of text. It states your policy and where reports should be sent.
A mail server receives a message claiming to be from your domain.
It checks: did the message pass SPF or DKIM, and does the passing identity align with the From address the recipient sees?
If at least one aligned check passes, the message is treated as authenticated.
If neither passes, the server applies your published policy.
Either way, the server records what it saw. Once a day, major providers bundle these records into an aggregate report and send it to the address in your DMARC record.

No software is installed anywhere. The entire system runs on one DNS record and the cooperation of the world's mail providers - which, for DMARC, is now very broad. Google, Yahoo and Microsoft have all tied their bulk-sender rules to DMARC since 2024, which is why even businesses that have never heard of it are increasingly required to have it.

The three policy levels

Your DMARC record contains a policy tag - p= - with one of three values. This is the instruction every receiving server follows for mail that fails authentication.

p=none - monitor only. Failing mail is delivered as normal. Nothing is blocked. You still receive reports. This is the correct starting point: it lets you see all your legitimate email sources before you risk blocking any of them. It is not protection, and treating it as protection is one of the most common mistakes in email security - we cover this in detail in Why DMARC p=none is not protecting you.

p=quarantine - treat with suspicion. Failing mail is typically delivered to spam or junk folders. A sensible intermediate step.

p=reject - block. Failing mail is refused outright. This is the destination. The National Cyber Security Centre (NCSC) recommends UK organisations progress to p=reject on all domains, including parked ones, and it is the only policy that actually stops spoofed mail reaching inboxes.

The journey from none to reject should be driven by what your reports show - not by guesswork. Move too early and you can block your own newsletters, invoices or booking confirmations sent by legitimate third-party services you had forgotten about.

What aggregate reports are - and why they matter

Aggregate reports (often called RUA reports) are XML files sent daily by receiving mail providers. Each one lists, for your domain: which IP addresses sent mail claiming to be from you, how many messages, whether SPF and DKIM passed, whether alignment passed, and what action the receiver took.

Read properly, they answer the questions that matter:

Who is legitimately sending as us? Your mail provider, yes - but also your accounting software, your CRM, your newsletter tool, your scanner-to-email device.
Is anyone spoofing us? Unauthenticated mail from unexpected sources, often overseas, claiming to be your domain.
Is our own setup broken? Legitimate sources failing SPF or DKIM - the silent cause of email landing in spam.

The catch is that raw aggregate reports are unreadable in practice: dozens of XML files a day, full of IP addresses and result codes. They were designed for machines. This is the gap SealedMail exists to fill - we receive your reports, interrogate them, and send you one weekly email in plain English explaining what happened and whether anything needs attention. We have written a full walkthrough of the raw format in What does a DMARC report actually show?.

Why monitoring is essential, not optional

DMARC without monitoring is a policy you cannot safely change and a smoke alarm with the battery removed. Monitoring is what tells you:

when a new legitimate sender appears (a marketing team signs up to a new tool) before it starts failing;
when an existing sender breaks (a DKIM key rotates, an SPF record hits its lookup limit);
when someone starts actively spoofing your domain - which, for many organisations, is the first time they discover it has been happening for months.

It is also, increasingly, evidence. Cyber insurers, procurement questionnaires and frameworks such as the NHS Data Security and Protection Toolkit ask not just "do you have DMARC?" but "do you monitor it?". A weekly written report you can produce from your inbox answers that question directly.

Where to start

First, find out where you stand. A DMARC record might already exist on your domain - set up years ago by a web developer, possibly still pointing reports at a service that no longer exists (a common discovery since the NCSC retired Mail Check in March 2026).

SealedMail's Free Domain Health Check audits your DMARC record alongside SPF, DKIM, MTA-STS, TLS-RPT, BIMI and blacklist status, and emails you a clear, scored certificate. It is free, with no sign-up and no follow-up sales call. From there, you will know exactly what good looks like for your domain - and if you want the ongoing reporting handled and explained for you, that is what SealedMail does, for £49 per domain per month.

Start your free health check →

Sources and further reading

Originally published at sealedmail.co.uk.

NCSC Mail Check migration guide: what to do now it's gone

SealedMail — Sat, 20 Jun 2026 06:30:02 +0000

The National Cyber Security Centre (NCSC) switched off Mail Check on 31 March 2026. If your organisation relied on it - and roughly 17,000 UK organisations were registered (NCSC) - you have lost your free window into who is sending email using your domain. This guide explains what was retired and when, what it means in practice, and exactly how to migrate to a replacement, step by step.

The short version: the configuration checker is the easy part to replace - plenty of free ones exist. The real loss is DMARC aggregate reporting. Until you re-establish it somewhere, you are blind to anyone spoofing your domain, and you cannot safely move to enforcement.

That blind spot is not hypothetical. When SealedMail analysed 198 major UK organisations in 2026, around 1 in 5 could still be spoofed (no DMARC, or DMARC left at p=none) - rising to 38% in healthcare and 32% across charities. These are large, well-resourced organisations; smaller ones tend to be more exposed, not less.

What Mail Check was

Mail Check launched in 2017 as part of the NCSC's Active Cyber Defence (ACD) programme. Its job was simple and valuable: help UK organisations - initially the public sector, later a much wider group - set up and monitor email authentication correctly. At its fullest it provided:

DMARC aggregate reporting (RUA) - collecting the reports that providers such as Google and Microsoft send back about every message claiming to come from your domain.
DMARC insights and DKIM checks - analysis of your DomainKeys Identified Mail signing setup.
TLS reporting (TLS-RPT) - whether email reached you over encrypted connections.
Configuration checks on SPF, DMARC policy records and inbound TLS.

It worked. By the NCSC's own account, 100% of UK central government departments reached strict DMARC enforcement by 2022, and over 80 million spoofed emails were blocked in a single 30-day period (NCSC Active Cyber Defence 6th Year Report).

What was retired, and when

The retirement happened in two stages, and it is worth being precise because many organisations only noticed the second:

24 March 2025 - reporting switched off. Mail Check stopped providing DMARC aggregate reporting, DMARC insights with DKIM checks, and TLS reporting. Anyone whose DMARC record pointed only at Mail Check stopped receiving usable data that day.

31 March 2026 - full retirement. Mail Check (and its sibling Web Check) were switched off entirely under the NCSC's Active Cyber Defence 2.0 strategy. The NCSC's position is that the commercial market has matured and government no longer needs to provide these tools.

What has actually been lost

The most important loss is the aggregate reporting. DMARC aggregate reports are the feedback loop of email authentication: they tell you which servers, anywhere in the world, are sending mail that claims to be from your domain, and whether it passed authentication. Without them you cannot see whether anyone is spoofing you; you cannot safely move your policy from monitoring (p=none) to enforcement (p=quarantine or p=reject) without risking blocking legitimate mail; and you lose the evidence trail that auditors, insurers and frameworks such as the NHS Data Security and Protection Toolkit increasingly expect.

A quick test: look at your domain's DMARC record. If the rua= address still points at mailcheck.service.ncsc.gov.uk, your reports are going nowhere.

The replacement options, honestly

The market broadly splits into three approaches. None is "best" in the abstract - it depends on whether you have someone who will read and act on the data.

ApproachBest forWatch out forTypical cost

Self-serve dashboardTeams with a technical person who will log in, interpret charts and actSet up, looked at twice, never reopenedLow monthly
Enterprise / consultant platformLarge estates with many domains and complex sendingPriced and scoped well beyond most SMEsHigh
Report-by-email (e.g. SealedMail)Non-technical teams who want the data read, interpreted and explainedFewer raw charts than a dashboardGBP 49 / domain / month

SealedMail is one credible option among several. If you have an in-house technical team that wants raw data, a self-serve tool may suit you better. If you want the reporting read and explained by a UK specialist in language a practice manager or compliance officer can act on, that is what SealedMail was built for - no dashboard, no logins, on a rolling monthly subscription with no minimum term.

How to migrate off Mail Check, step by step

Migrating is mostly a DNS exercise. You can do it in an afternoon.

Find your current DMARC record. Check the TXT record at _dmarc.yourdomain (use any DMARC checker, or our free health check below). Note the rua= address - if it points only at mailcheck.service.ncsc.gov.uk, you currently have no working reporting.
Choose where reports will go. Pick a replacement from the table above. You will get a reporting address to publish.
Update your DMARC rua (and ruf if used). Point it at your new provider's address. You can keep any existing addresses you still want reports sent to - rua accepts a comma-separated list.
Add TLS-RPT. Publish a _smtp._tls TXT record pointing at your provider so you also regain encryption-in-transit reporting - the part of Mail Check almost nobody replaces.
Do not jump straight to p=reject. Keep your current policy, let two to four weeks of fresh reports come in, fix any legitimate senders failing SPF or DKIM, then progress p=none -> quarantine -> reject. See why p=none is not protecting you and getting to p=reject safely.
Cover parked and unused domains too. Publish v=DMARC1; p=reject and v=spf1 -all on every domain that never sends mail - attackers love a forgotten domain.

What "good" looks like

DMARC at p=reject on every domain, including parked ones
SPF that ends in -all (hard fail)
DKIM signing in place and aligned
TLS-RPT and ideally MTA-STS published
Aggregate reports actually read every week, not just collected

Frequently asked questions

Is NCSC Mail Check definitely gone?

Yes. DMARC and TLS reporting stopped on 24 March 2025, and the service was fully retired on 31 March 2026 along with Web Check. The NCSC has encouraged registered organisations to adopt alternative DMARC tools.

Do I have to pay to replace it?

No - free and open-source DMARC tooling exists. The question is whether someone in your organisation will install, run and interpret it. Paid services exist precisely because most organisations will not, and the reports are useless unless someone acts on them.

What happens if I do nothing?

Your DMARC policy keeps doing whatever it already does, but you lose all visibility - you cannot see spoofing, cannot safely tighten your policy, and lose the audit evidence. If your rua pointed only at Mail Check, you are already receiving no reports.

How long does migrating take?

The DNS changes take minutes. Re-establishing a clear picture of your mail takes two to four weeks of aggregate reports before you should tighten your policy.

If you are not sure where your domain stands today, SealedMail's Free Domain Health Check audits your SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI and blacklist status and emails you a clear, scored certificate - no sign-up, no sales call. For how SealedMail replaces Mail Check specifically, see our NCSC Mail Check alternative.

Start your free health check ->

Sources and further reading

Originally published at sealedmail.co.uk.

What happens to your DMARC data? A transparency post

SealedMail — Fri, 19 Jun 2026 06:30:00 +0000

Subscribing to SealedMail means adding our reporting address to your DNS, after which the world’s mail providers send your domain’s DMARC and TLS reports to our infrastructure. For a compliance-minded buyer, that should prompt a precise question: what exactly am I handing over, and what happens to it?

This post is the complete answer. It is short, because the honest answer is reassuringly small - but “trust us, it’s fine” is not a standard SealedMail would accept from a supplier, so here is the detail, in the order a data protection review would ask for it.

What a DMARC aggregate report contains

A DMARC (Domain-based Message Authentication, Reporting and Conformance) aggregate report is a statistical summary compiled by a receiving mail provider - Google, Microsoft, Yahoo and others - describing the email it saw claiming to come from your domain. Each report contains:

the IP addresses of servers that sent mail using your domain’s name;
message counts per source;
authentication results - whether each source passed SPF and DKIM checks, and the alignment outcomes;
the policy action the receiver applied (delivered, quarantined, rejected);
your domain’s published DMARC policy as the receiver saw it.

Equally important is what an aggregate report does not contain - by design of the standard itself, not by anyone’s discretion:

no email content or message bodies;
no subject lines;
no sender or recipient mailbox addresses;
no attachments, headers beyond the authenticating domains, or personal data from inside any email.

In other words: the reports describe traffic about your domain’s name, not correspondence. The full field-by-field anatomy is in What does a DMARC report actually show?. One technical footnote for completeness: the DMARC standard also defines a second report type - forensic/failure reports (RUF) - which can contain message detail. SealedMail’s service is built on aggregate reports and TLS reports only; we do not request forensic reports in the DNS entries you publish for us.

A TLS-RPT report is more minimal still: counts of successful and failed encrypted connections to your domain, with technical failure reasons. No content of any kind.

What SealedMail receives, stores and processes

Receives: the aggregate and TLS reports described above, sent by mail providers to the SealedMail reporting addresses in your DNS; plus the ordinary account information any supplier holds - your name, business name, the email address your weekly report goes to, and billing handled by Stripe (SealedMail does not see or store your card details).

Processes: we parse the reports, resolve source IP addresses to their operators, compare each week against your domain’s history, and run the domain health checks (your public DNS records - which are, by nature, already public). The output is your weekly plain-English report.

Stores: the report data and the derived history for your domain - necessary because interpretation depends on trend (“this source is new”; “this failure started Tuesday”). All data is held on UK-based infrastructure and handled under UK GDPR (the UK General Data Protection Regulation). The full legal detail - lawful bases, sub-processors, your rights - lives in our privacy policy, which is written in the same plain English as everything else here.

Retains: report data for the period needed to provide trend-based interpretation, and your account data for the duration of your subscription plus statutory retention for business records. If you cancel, your reporting data is deleted after the wind-down period set out in the privacy policy - and because you control your DNS, redirecting or stopping the flow of reports is always in your hands, instantly, without asking us.

The honest assessment of sensitivity

Could DMARC data harm you if mishandled? A fair due-diligence question deserves a straight answer: the realistic sensitivity is low but not zero. The reports reveal which platforms send email for your business (your mail provider, your CRM, your invoicing system) and the volume rhythm of your sending - commercially mundane, but a picture of your operations nonetheless. They contain no client correspondence, no personal data from emails, and nothing approaching special category data. SealedMail treats them with the same care regardless: UK storage, access limited to the one named person who runs the service, no sale or sharing of data, no use of your data for anything except producing your reports.

That last point bears repeating as a plain commitment: your data is used to deliver your service. Nothing else. No analytics products, no “anonymised industry insights”, no marketing lists.

Why we publish this

SealedMail sells to regulated, cautious buyers - solicitors, practice managers, charity trustees - and asks them to route security telemetry to a sole trader. The only honest response to that asymmetry is transparency specific enough to be checked: what arrives, what it contains, where it lives, who can see it, when it is deleted. If your due-diligence process needs more - a completed supplier questionnaire or our supplier information sheet - ask at hello@sealedmail.co.uk and it will be provided during service hours.

And if you would like to see exactly what we produce from such data before pointing anything anywhere, the Free Domain Health Check uses only your public DNS records - handing over nothing at all - and shows you the plain-English certificate format every subscriber receives weekly.

Start your free health check →

Sources and further reading

ICO (Information Commissioner's Office)
DMARC.org

Originally published at sealedmail.co.uk.

Email blacklists: what they are and how to check yours

SealedMail — Thu, 18 Jun 2026 06:30:01 +0000

Among the systems silently deciding whether your email arrives, blacklists are the bluntest. A spam filter weighs dozens of signals and reaches a nuanced verdict; a blacklist is a register - your domain or your sending server’s address is on it or it is not - and for many receiving servers, “on it” simply ends the conversation.

Most businesses on a blacklist have no idea. Nobody writes to inform you; mail just starts bouncing or vanishing into junk folders, customer by customer, until someone joins the dots. Here is how the system works, how businesses end up listed, and how to check your status in one pass.

What blacklists are

Blacklists - also called blocklists or DNSBLs (Domain Name System blocklists) - are shared databases of IP addresses and domains associated with sending spam or malicious mail. Dozens of significant ones exist, operated by independent organisations: some venerable and widely trusted (Spamhaus chief among them), some niche, some aggressive to the point of eccentricity.

Receiving mail servers consult them in real time. When a message arrives, the receiver checks the sending server’s address - and often the sender’s domain - against one or more lists. A hit, depending on the receiver’s configuration, means outright rejection, junk-folder placement, or a heavy negative mark in the wider filtering decision covered in Why your emails are going to spam.

The crucial nuance for a small business: lists track sending infrastructure as well as domains. Your mail typically leaves through servers you share - your mail provider’s, your newsletter platform’s, your web host’s. Reputation is communal property on shared infrastructure, which cuts both ways, as we are about to see.

How domains and senders get listed

The common routes, in rough order of frequency for UK small businesses:

A compromised mailbox. A criminal obtains a password, quietly sends thousands of spam messages through the genuine account, and the spam traps and complaint systems that feed blacklists do their job. The business discovers the compromise via the listing - often the first symptom.

A compromised website. An out-of-date plugin lets an attacker turn the web server into a spam cannon. Since many small-business websites send legitimate mail (contact forms, order confirmations), the listing catches that too.

Marketing missteps. Sending to bought lists, to old lists full of dead addresses, or without working unsubscribe mechanisms generates the bounce rates and spam complaints that listings are made of. Enthusiasm plus a spreadsheet of “contacts” from 2017 has blacklisted many an innocent firm.

Bad neighbours. On shared hosting, another customer of the same server misbehaves and the shared IP address is listed - your mail suffers for someone else’s spam. You did nothing; you carry the consequence until the host resolves it or you move your sending elsewhere.

What it costs you, and how delisting works

The damage is silent and uneven: some recipients get your mail, some do not, depending on which lists each receiving server consults. Invoices unpaid because they never arrived, quotes that “must have gone to spam”, candidates who never got the offer - blacklisting presents as a string of small unexplained failures rather than one loud one.

Delisting follows a standard shape, with varying friction. First, fix the cause - delisting without remediation is a revolving door, and the major lists treat repeat offenders harshly. Then, request removal via the list’s own process: the reputable lists provide lookup and removal request pages, and respond in hours to days once the underlying problem is genuinely resolved. Some minor lists expire entries automatically; a few operate slowly or idiosyncratically. Beware of third parties selling “express delisting” - the legitimate processes are free, and no paid intermediary can shortcut Spamhaus.

One scope note, honestly stated: identifying the cause and fixing it - cleaning a compromised mailbox or website, changing sending practices - is remediation work for you or your IT supplier. SealedMail’s role is detection and explanation: telling you that you are listed, where, and what that means, in plain English.

Checking your status - and why once is not enough

Checking any single blacklist is straightforward; the catch is the plural. Meaningful coverage means querying your domain and sending infrastructure against the set of lists that receivers actually consult - and doing it regularly, because listings happen at any time and the silence afterwards is total.

Blacklist status is one of the seven checks in SealedMail’s Free Domain Health Check: your domain is screened against the major registers alongside SPF, DKIM, DMARC, MTA-STS, TLS-RPT and BIMI, with the results scored and explained in a plain-English certificate, by email, free, no sign-up. For subscribers, the same screening runs as part of every weekly report - so a new listing surfaces within days, with an explanation of what it is and what it implies, rather than months later via a customer’s puzzled phone call. (Authentication and reputation travel together: a domain with broken SPF is both more spoofable and more listable, which is why the checks come as a set - see What is SPF?.)

Start your free health check →

Sources and further reading

Originally published at sealedmail.co.uk.

Education email security in 2026: schools, MATs and universities under pressure

SealedMail — Wed, 17 Jun 2026 13:16:40 +0000

Education sits in an awkward position. Schools, multi-academy trusts (MATs) and universities handle pupil data, safeguarding records, parental payments and large research budgets, yet they often run on stretched IT teams and a sprawl of domains accumulated over years. That combination makes the sector one of the most spoofed and least consistently protected in the UK.

This guide sets out where education stands on email authentication going into 2026, why it is targeted, and the practical steps that actually move a school or trust to a defensible position. If you are new to the underlying controls, start with our plain-English guide to DMARC and come back.

Why education is a soft target

The Cyber Security Breaches Survey has repeatedly found that education providers report higher rates of attack than most other sectors. Phishing is the most common attack type by a wide margin, and email impersonation is the engine behind it.

Several factors compound the problem in education specifically:

Trusted by everyone. Parents, pupils, suppliers and other institutions open email from a school without hesitation. A spoofed message from the school office carries instant authority.
High-value, time-sensitive payments. Trip payments, fee invoices, supplier transfers and university tuition all create moments where a fraudulent "updated bank details" email can succeed. This is classic business email compromise.
Domain sprawl. A single MAT may own dozens of domains: the trust, each academy, legacy school names, and unused variations bought "just in case". Every one of those is a spoofing opportunity if it is not locked down.
Seasonal staff churn. Term cycles, new starters and shared mailboxes make it harder to spot an unusual message.
Federated systems. Universities in particular send mail from many third-party platforms: admissions, alumni, library, payments, learning environments. Each one needs to be authorised correctly or it breaks.

Where the sector actually stands in 2026

Education has improved, but it is uneven. Most large MATs and universities now publish an SPF record and many have a DMARC record in place. The problem is what that record says.

A DMARC record set to p=none tells the world to monitor and report but to take no action when a message fails. It produces useful data, but it stops nothing. A large share of education domains that "have DMARC" are sitting at p=none, sometimes for years, mistaking the presence of a record for protection. We explain exactly why that is a false sense of security in why p=none is not protection.

The three common positions

Nothing meaningful. No DMARC, or a broken SPF record. Common among smaller standalone schools and primaries with no dedicated IT. Anyone can send email as the domain.
Monitoring only. A DMARC record at p=none, often added during a Cyber Essentials push or by an MSP, then left untouched. Visible but not enforced.
Enforced. p=quarantine or p=reject, with SPF and DKIM aligned across all legitimate senders. This is the minority, but it is achievable.

The NCSC Mail Check change and what it means

Many education bodies relied on NCSC Mail Check for free DMARC reporting and monitoring. The public sector and education focus of that service has changed, and organisations that leaned on it need an alternative source of reporting and aggregation. NCSC guidance remains a sound reference for the standards themselves, but the day-to-day job of collecting reports, reading them and acting on them now sits with you or your provider.

The MAT problem: many domains, one policy mindset

For multi-academy trusts, the single biggest practical issue is scale. You are not protecting one domain, you are protecting a portfolio. Each academy domain, each legacy name and each parked variation needs its own correctly configured records.

Two principles help:

Treat parked domains as live risks. An unused domain with no DMARC can still be spoofed. Old school names that pre-date a merger are a favourite for attackers because recipients still recognise them. Lock every parked domain to reject.
Standardise, then exception. Apply a consistent baseline across the estate, then handle the genuine sending exceptions (a finance platform here, a comms tool there) deliberately rather than per-school guesswork.

The university problem: too many legitimate senders

Universities rarely struggle with caring about security. They struggle with the sheer number of authorised senders. Admissions, finance, alumni relations, faculties, the library, halls, students' unions and dozens of SaaS tools all send mail "as" the institution.

Moving to enforcement without breaking those flows requires patience. You read the DMARC reports, identify every legitimate source, bring each one into alignment with SPF or DKIM, and only then tighten the policy. Rushing it means blocking real admissions or fee emails, which is worse than the original exposure. Our guide on the safe route to enforcement sets out the staged approach.

What good looks like

SPF published and accurate on every sending domain, within the lookup limits.
DKIM signing enabled on all legitimate platforms.
DMARC at p=reject (or at minimum p=quarantine) on every active domain.
Every parked and legacy domain set to p=reject with a null SPF.
DMARC reports collected and reviewed so new senders and spoofing attempts are spotted early.
A named owner for the email estate, not an assumption that the MSP "has it covered".

What DMARC does not do

We are honest about limits. Enforcing DMARC stops attackers sending email from your exact domain. It does not stop look-alike domains (a trailing letter swapped, or a .org instead of .ac.uk), inbound phishing, or a genuine account that has been compromised through stolen credentials. Those need separate controls: lookalike monitoring, staff awareness, multi-factor authentication and good mailbox hygiene. DMARC is a foundation, not the whole building.

A sensible order of work

For a school or trust starting from scratch, the practical sequence is: confirm what domains you own, publish a DMARC record in monitoring mode to start collecting data, fix SPF and DKIM for every legitimate sender, then move steadily to enforcement, and finally lock down the parked domains. Each step is reversible if something breaks, which is why the order matters.

Education does not need to be the soft target it has been. The standards are free, the route is well understood, and the main thing missing is sustained attention.

If you run a school, MAT or university and you are not sure whether your domains are actually enforced or just monitoring, our free health check will show you exactly where each domain stands and what to fix first.

Check your domain free →

Sources and further reading

Originally published at sealedmail.co.uk.

DEV Community: SealedMail

DMARC for law firms: protecting client money from email fraud

How the fraud works

What DMARC does for a law firm

What the SRA actually says

What it does not do - said plainly

Where most firms actually are

A practical first step

Related reading

Sources and further reading

What is DMARC? A plain-English guide

The problem DMARC solves

How DMARC works, step by step

The three policy levels

What aggregate reports are - and why they matter

Why monitoring is essential, not optional

Where to start

Related reading

Sources and further reading

NCSC Mail Check migration guide: what to do now it's gone

What Mail Check was

What was retired, and when

What has actually been lost

The replacement options, honestly

How to migrate off Mail Check, step by step

What "good" looks like

Frequently asked questions

Related reading

Sources and further reading

What happens to your DMARC data? A transparency post

Related reading

Sources and further reading

Email blacklists: what they are and how to check yours

Related reading

Sources and further reading

Education email security in 2026: schools, MATs and universities under pressure

Why education is a soft target

Where the sector actually stands in 2026

The three common positions

The NCSC Mail Check change and what it means

The MAT problem: many domains, one policy mindset

The university problem: too many legitimate senders

What good looks like

What DMARC does not do

A sensible order of work

Related reading

Sources and further reading