We read the public DNS records of twenty UK businesses. Two had no DMARC record at all, four were set to monitor and block nothing, and six sent forged mail to junk rather than refusing it.
Twelve of the Twenty Business Domains We Checked Can Be Spoofed
We read the public DNS records of twenty UK businesses across construction, manufacturing, legal and professional services. We were looking at one thing: whether a stranger could send an email carrying their domain name and have it land in a customer's inbox.
For twelve of the twenty, the answer was yes.
Two had published no DMARC record at all, which means nothing checks whether an email claiming to come from them really did. Four had a record set to monitor and block nothing. Six were set to send forged mail to the junk folder rather than refuse it. Only eight were in the finished state.
None of these businesses is careless. Several had done real work on their email security and stopped one step short of the end.
How to check your own domain in about a minute
Open MXToolbox's DMARC lookup, type your domain and read the policy value. DMARC is the record that tells the receiving mail server what to do with an email that fails authentication, and it has three settings plus the option of not existing at all.
If nothing comes back, anyone can send as you and nobody is being told when they do.
If it reads p=none, that's monitoring with no protection. A forged email arrives in the inbox exactly as it would if the record were absent.
If it reads p=quarantine, a forged email goes to junk. That's better, and people do check junk.
If it reads p=reject, the forged email is refused before it arrives. That's where you want to be.
Why so many domains stop at p=none
Setting a DMARC record to none is the correct first move, which is exactly why so many domains are still sitting on it years later.
The sequence works like this. You publish a monitoring policy, you collect reports for a few weeks to learn which systems legitimately send email in your name, you fix anything unexpected, then you tighten the policy. Skipping the middle and going straight to reject will stop your own invoices and marketing from being delivered.
So the first step is right. The problem is that nothing about it says "unfinished". No alert fires, no mail breaks, and the record reads as a completed job to anyone who glances at it. A DNS record carries no date, so there is nothing on the four domains we found at p=none to say when the decision was made or by whom.
The business ends up with the paperwork of email authentication and none of the protection.
Who pays when this goes wrong
The bill lands in different places depending on what you do.
For an accountancy practice or a law firm, the attack is an email that appears to come from a partner telling a client their bank details have changed. The client has a real relationship and a real reason to expect payment instructions, and the argument about who was at fault is expensive however it ends.
In construction and manufacturing, it follows the invoices. On a job with a main contractor, subcontractors and suppliers who change between projects, a new bank account on familiar letterhead gets processed. The businesses most exposed are the ones everybody in the chain recognises.
For a consumer brand, fake order confirmations reach customers who genuinely did just order something, and those customers ring your support team. You carry the cost of an attack aimed at someone else, and it gets worse through Christmas trading when a confirmation email is unremarkable.
After an acquisition it is the old domain that bites. Suppliers keep recognising the name for years after the rebrand, and if the original Microsoft tenant is still live with nobody responsible for it, that domain is trusted and unwatched at the same time.
The list nobody reviews
Reaching p=reject is the right destination and there's one more thing to check once you're there.
Your SPF record lists which services are allowed to send email on your behalf. It only ever grows. Marketing platforms, invoicing tools, CRMs, helpdesks and mail filters get added as the business signs up to them, and almost nothing gets removed when a contract ends.
One of the twenty had a properly configured reject policy and six separate senders authorised, ranging from mail filtering services to marketing platforms. We have no way of telling from the outside which of the six are still in use, and in our experience the person who could answer that has usually left. Every entry on the list is a service that can send email as that company, protected by whatever security that supplier happens to run.
A reject policy doesn't help when the forged mail goes through something you've already told the world to trust. Reviewing the list is a separate job from setting the policy, and once a year is enough.
What to do about it
Run the lookup first. If it returns nothing or p=none, you've found something worth putting on somebody's list and it took under a minute.
Publish a monitoring policy if there isn't one, and make sure it includes an address to send reports to. A record with no reporting address collects nothing, and three of the twenty had exactly that.
Read a month of reports before you tighten anything. They arrive as XML, one file per sending source per day, and they aren't written for people. This is the step that gets skipped, and skipping it is what breaks legitimate mail.
Move to quarantine, then reject. Two steps, with a few weeks between them, gives you time to catch anything the reports missed.
Put the SPF review in the calendar for a year's time. It'll have grown by then.
The cost is a few weeks of waiting for reports to accumulate and a couple of hours of attention spread across them. If you're on Microsoft 365 or Google Workspace, the tools to authenticate your mail sit inside the licence you already pay for.
The honest summary
Twelve of twenty domains we checked could be spoofed, and the majority of those were not neglected. They belonged to businesses that started the work and had nothing to tell them it was unfinished.
We hold UKAS-accredited ISO/IEC 27001:2022, which means our own email authentication is audited rather than self-declared, and we do this work for businesses across the South West and the Midlands.
The other half of this problem is the email arriving at your staff rather than leaving in your name, and we wrote about how to protect your staff from phishing attacks separately.
If you'd like us to read your DMARC reports and tell you what is sending as your domain, book a discovery call and we'll go through it with you.
