After the Beacon breach: how easy is it to send email as your charity?

At the end of July, someone used compromised credentials to copy database backups from Beacon CRM, a customer relationship management platform built for charities and used by more than 1,000 organisations. The route in has since been reported as an access key accidentally exposed in publicly visible website code. By early August, Beacon was advising customers to assume that everything stored on the platform had been downloaded: names, addresses, email addresses, phone numbers, dates of birth and donation histories, the standard fields a CRM holds on every supporter. The Charity Commission has issued guidance, the ICO is involved, and affected charities have spent the weeks since filing serious incident reports and writing difficult emails to supporters.

We published a plain-English guide to that side of things on the day the story broke: your CRM provider has had a security incident, what now? This article is about what comes next. Breaches like this have a predictable second act, and whether it’s merely annoying or genuinely damaging depends partly on three DNS records most charities have never looked at. We’ve just measured them across every charity domain in the UK. The results aren’t comforting.

Stolen donor data is a phishing kit

Think about what the attacker now holds: who supports which charity, how to reach them, and when and roughly how much they last gave. That’s everything needed to write a convincing “there was a problem processing your recent gift” email, personalised at scale. Phishing was already the sector’s most common attack before any of this happened. The government’s Cyber Security Breaches Survey 2025/26 found that 28% of UK charities identified a breach or attack in the previous year, with phishing the most prevalent type, experienced by 25% of charities and the type 69% of affected charities called their most disruptive. Several charities affected by the Beacon incident have already asked supporters to be alert to unusual emails or calls that appear to come from them.

Here’s the distinction that matters, though. The leaked email addresses are the audience for the phishing, not the disguise. The disguise question is separate: when that fraudulent email lands, can it show your charity’s actual domain in the From line, or is the attacker forced to use a lookalike? That’s not a matter of luck. It’s decided by DNS records you control, and it’s exactly what our latest research measures.

Could someone send email as your charity?

Two public DNS records do most of the work here. SPF lists the servers allowed to send email for your domain. DMARC tells the world’s mail servers what to do when a message fails that check: do nothing and report it (p=none), send it to junk (p=quarantine), or refuse it outright (p=reject). No DMARC record, or a record set to monitor-only, means a forged From line is left to each receiving server’s guesswork.

In August we resolved the MX, SPF and DMARC records for 99,606 UK charity domains, drawn from the charity registers for England and Wales, Scotland and Northern Ireland, as part of our ongoing research programme. The headline:

DMARC isn’t a yes/no. A domain sits on one of four rungs, and the sector is heavily weighted to the bottom two:

Where 99,606 UK charity domains sit on the DMARC ladder. Source: Nebula Design Research, DNS measured 22 August 2026.

To be fair to the 31% at p=none: that’s a real step. It means someone published a policy and asked to be told about forgery attempts. But monitoring blocks nothing, and it’s not meant to be a permanent home. Meanwhile 29.8% of charity domains publish no SPF record at all, and a further 814 publish more than one, which sounds diligent but actually disables SPF entirely, because evaluation must fail when a second record is found.

One counterintuitive finding: 9.3% of charity domains publish no MX record, meaning the domain doesn’t receive mail at all. That doesn’t make them safe. A domain that sends nothing and receives nothing still needs a DMARC policy, because a quiet, unprotected domain is exactly what a forger wants to borrow. The NCSC’s advice is the same: DMARC belongs on every domain you own, including parked ones.

What DMARC won’t do

Worth saying plainly, because breach coverage tends to blur these lines:

• None of this caused the Beacon breach. The incident involved compromised credentials and copied backups. Email authentication played no part in it, and enforcing DMARC tomorrow won’t undo the theft. This is about the consequences, not the cause, and it’s no reflection on the affected charities.
• Enforcement only blocks exact-domain forgery. An attacker can still register a lookalike domain or use a free webmail address. Those are real risks, but they’re also easier for spam filters and alert readers to catch. A p=reject policy closes the most convincing route, not every route.
• These figures aren’t a complete picture of any charity’s email security. Our crawl doesn’t measure DKIM, because locating a DKIM key means guessing selector names, and a missed guess is indistinguishable from an absence. The full methodology sets out exactly what was and wasn’t checked.

What to do this week

1. Look up your records. Your DMARC policy lives in a public TXT record at _dmarc.yourcharity.org.uk. Free checkers such as MXToolbox or dmarcian will read it in seconds, or ask whoever looks after your website and DNS. You’re checking for two things: does an SPF record exist, and what does the DMARC policy say?
2. Nothing there? Start with monitoring. Publish SPF for the services that genuinely send your mail, then a DMARC record at p=none with a reporting address. The NCSC’s step-by-step guidance walks through it. It costs nothing, blocks nothing legitimate, and starts telling you who’s sending as your domain.
3. Already at p=none? Do the homework, then climb. Use a few weeks of reports to list every legitimate sender: Microsoft 365 or Google Workspace (which between them handle mail for 42% of charity domains), your CRM, your newsletter tool, your fundraising platform. Get each one passing SPF or DKIM (a cryptographic signature your sending services add, which DMARC also accepts) for your domain, then move to p=quarantine and eventually p=reject. Skip the homework and you’ll junk your own appeal emails, which is precisely why the monitoring rung exists, and why nobody should live on it forever.
4. Brief your people. The Charity Commission’s Beacon guidance notes that “clear communication with your charity’s stakeholders is crucial to retaining trust”. Tell supporters what you’ll never ask for by email, remind staff that finance-related requests deserve a second check, and forward anything suspicious to [email protected].
5. If you’re a Beacon customer, our earlier guide covers the reporting and communication side: your CRM provider has had a security incident, what now?

If you’re a supporter rather than a charity

Treat any unexpected email about a problem with a donation or payment with suspicion, even if the sender address looks right. Don’t click through from the email: go to the charity’s website directly, or phone them. No charity will mind you checking. If an email turns out to be fake, forward it to [email protected], and if you’ve lost money, report it to Action Fraud.

About the data

All figures come from Can you trust email from the UK’s charities?, our study of MX, SPF and DMARC records across 99,606 charity domains, measured on 22 August 2026. It’s aggregate-only: no charity, domain or address is named anywhere in it. The figures are free to quote with credit under CC BY 4.0, and the underlying aggregate table is published so every number can be recomputed.

Nebula is a Bristol agency that designs, builds and looks after websites for charities, and “looks after” includes unglamorous things like DNS. If the list above feels like one job too many this month, we’re happy to help.

Quick answers

Did missing DMARC cause the Beacon breach?

No. The breach involved compromised credentials being used to copy database backups. DMARC governs whether outsiders can forge your domain in the From line of an email; it played no part in the breach and enforcing it won’t undo the theft. What it does affect is how convincing any follow-up impersonation of a charity can be.

What does DMARC actually do?

SPF and DKIM let receiving mail servers check whether a message really came from a server authorised to send for your domain. DMARC is your published instruction for what to do when that check fails: report only (p=none), send to junk (p=quarantine) or refuse delivery (p=reject). Without an enforcing policy, a forged From line is left to each receiver’s judgement.

If we set p=reject, will phishing against our supporters stop?

No, but it changes the game. Compliant mail servers will refuse messages that forge your exact domain, which is the most convincing disguise available. Attackers can still use lookalike domains or webmail addresses, but those are easier for filters and readers to spot.

How do we check our charity’s records?

Look up the TXT record at _dmarc.yourdomain using a free checker, or ask whoever manages your website or IT. If nothing is published, the NCSC’s email security guidance explains how to set up SPF and a monitoring DMARC policy without disrupting your legitimate email.