DMARC is the record that turns email authentication from advice into policy: it tells every mail system in the world what to do with a message that claims to be from your school but can’t prove it. Without it, forged email carrying your school’s name is delivered and it is the parent’s job to spot the fake. With it — at full strength — the forgery never arrives.
What DMARC actually is
A single DNS record on your domain, readable by anyone, that answers two questions for receiving mail systems: how strictly should you treat mail that fails authentication? and where should you send reports about what you saw? The first is the policy; the second is the feedback loop that makes a safe rollout possible. The NCSC’s anti-spoofing guidance (sources below) recommends DMARC for every UK organisation; what follows is how it plays out for a school specifically.
The SPF and DKIM relationship — and “DMARC vs SPF”
People often ask whether they need DMARC or SPF, as if they compete. They don’t: DMARC is the judge, and SPF and DKIM are the two kinds of evidence it weighs. SPF says which servers may send as your domain. DKIM signs each message so it can be checked for tampering. A message passes DMARC when at least one of them passes and aligns— and without DMARC on top, SPF and DKIM are opinions nobody is obliged to act on.
Alignment — the detail that catches schools out
Alignment means the domain that passed the check must match the domain in the “from” line the reader sees. This matters because plenty of legitimate services send on your behalf from their infrastructure — and unless they are set up to sign or send as your domain, their mail passes checks for the wrong domain and fails DMARC. Which is exactly why the rollout starts in monitoring mode, below, rather than at full enforcement.
none, quarantine, reject — what each really does
- p=none — monitoring. Nothing is blocked; you receive reports showing who is sending as your domain. This is the correct starting point, and the wrong place to stay: it announces to attackers that failures carry no consequence.
- p=quarantine — failures go to spam. Real protection, forgiving of mistakes: a mis-configured legitimate sender lands in junk rather than vanishing.
- p=reject — failures are refused outright. The destination, and where the protection actually lives: the forged message to a parent is never delivered at all.
A rollout that doesn’t lose real mail
The fear that stalls every school DMARC project is losing legitimate email. The sequence below is how you get to reject without that happening — it is the one we use in practice:
- 1 · Publish at p=none with reporting switched on. Nothing changes for anyone; the reports start arriving.
- 2 · Inventory your real senders. Schools are surprised by their own list: the office (Microsoft 365 or Google), the MIS, the payment system, the catering platform, the comms tool, sometimes the photocopier. The reports reveal all of them — including the ones nobody remembered.
- 3 · Fix each legitimate sender so it passes with alignment — usually a setting or a DNS entry per service, done by whoever runs your DNS or the service itself.
- 4 · Step up: quarantine, then reject — once the reports show your real senders passing, and not before. Weeks, not months, for most single-domain schools.
Reading the results without drowning
DMARC reports arrive as machine-readable XML from every large mail receiver, which is why “send them to the office inbox” fails immediately — they need something that aggregates them into an answer. Whatever tool you use (ours or anyone’s), the two questions to ask of it are: which senders are failing that we recognise? (fix those) and which senders are failing that we don’t? (that is the forgery attempt, and at reject it is being blocked — which is the record working, not a problem). One honest caution from practice: a 100% pass rate means your own records vouch for every sender seen — it does not mean nobody tried.
When to get help
Publishing p=none and running the free check is safely within any school’s reach today. The moment to bring in whoever runs your IT — or us — is the sender-fixing stage on a domain with many services, or any school that sends from multiple domains (trusts especially: every academy domain needs its own records, and the estate is only as strong as its weakest one). The full record-by-record how-to lives in our records guide, and the wider picture in the email security hub.


