The Email That Says It's From You (But Isn't): Rolling Out DMARC Without Breaking the Post
Picture the scene. A regular customer forwards you an email that appears to come from your address. It carries your logo, your signature, and a polite request to update bank details before paying an invoice. You didn't send it. Nothing has been hacked, at least not obviously. Someone has simply used your domain name in the From line and let the message loose.
This is spoofing, and for a small UK business it is both easy to attempt and easy to ignore until a customer pays the wrong account. The fix isn't a single switch. It's a short sequence of DNS records and a bit of patience. Get it right and you make it much harder for anyone to impersonate your domain without breaking the email you actually rely on.
Why anyone would bother spoofing a small firm
Attackers don't need access to your mailbox to cause trouble. They need your name, your logo, and a plausible request. Small firms are attractive because they often have regular suppliers and customers who recognise the domain, and because they rarely publish email authentication records. A spoofed invoice or a fake change-of-bank-details note can work for weeks before anyone notices.
The damage isn't only financial. Customers lose confidence, your staff spend days explaining, and your domain starts appearing in spam filters for reasons nobody in the office can see.
The three acronyms, minus the jargon
SPF, DKIM and DMARC are usually explained badly. Here's the plain-English version.
SPF is a list, published in DNS, of the servers allowed to send email for your domain. When a receiving server gets a message claiming to be from you, it checks whether the sending server is on that list. Simple enough, but SPF breaks when mail is forwarded, and it doesn't look at the visible From address in the way most people assume.
DKIM adds a cryptographic signature to outgoing mail. The receiving server checks the signature against a public key in your DNS. If the message has been altered in transit, or the signature doesn't match, DKIM fails. It survives some forwarding better than SPF, but it still needs to be set up by whoever sends your mail.
DMARC ties the two together. It tells receiving servers what to do when a message fails both SPF and DKIM, and it asks them to send you reports about what they're seeing. Crucially, DMARC checks alignment: does the domain in the visible From address match the domain that passed SPF or DKIM? That alignment is what stops a lot of spoofing.
Before you touch DNS, find out who sends as you
This is the step people skip, and it's the one that causes the most pain. Before you publish a DMARC policy that quarantines or rejects mail, you need a decent inventory of legitimate senders.
Start with the obvious: Microsoft 365 or Google Workspace, your website contact forms, the accounts package that emails invoices, the booking system, the e-shot platform, payroll, and any scanner that emails documents to staff. Then ask around. Someone in sales may be using a CRM nobody in IT knows about. Someone in operations may have signed up for a delivery notification service that sends as your domain.
Check your DNS for existing SPF and DKIM records, and note every service that needs to be included. If you're unsure, start with a monitoring policy and let the reports tell you what you've missed.
Start with monitoring, not muscle
A DMARC record with p=none asks receivers to take no action on failures, but to send you reports. That's your reconnaissance phase. Publish the record with a reporting address you actually monitor, and leave it for two to four weeks.
During that window, legitimate mail keeps flowing and you get a picture of every source sending as your domain. You'll see your main platform passing, plus the usual assortment of forgotten tools and possibly a few unknown senders. Don't tighten the policy until you've accounted for the legitimate ones.
Reading the reports without a data science degree
DMARC aggregate reports arrive as XML files, which is nobody's idea of a good morning read. Use a reporting service or a free tier from one of the well-known DMARC vendors to turn them into something human. You're looking for three things: which IP addresses are sending as your domain, whether SPF and DKIM passed, and whether the domains aligned.
Ignore the noise from known senders for a moment. Focus on sources you don't recognise, especially those failing alignment. Some will be harmless: a newsletter platform that needs a DKIM key, a printer that needs an SPF include. Others may be the first sign that someone is abusing your domain.
Tighten in stages, not in one leap
Once the known senders are passing and the unknown ones are either fixed or confirmed as unwanted, move to p=quarantine. If you want to be cautious, use pct=25 to apply the policy to a quarter of failing mail, then increase to 50 and 100 over a few weeks. Watch the reports at each step. When you're confident, move to p=reject.
Reject is the strongest setting, and it's the one that genuinely reduces spoofing. But it's also the one that will expose any forgotten sender still using your domain without authentication. That's why the monitoring phase matters.
Warning signs your domain is already being abused
You don't need to wait for a customer to call. Watch for a sudden rise in DMARC failures from IP addresses in countries you don't operate in, a cluster of unknown senders using your domain, or a spike in bounce messages you didn't generate. If customers mention odd emails, or you start receiving replies to messages you never sent, treat it as a signal to review the reports closely.
Also keep an eye on lookalike domains: slight misspellings of your name registered by someone else. DMARC won't stop those, but it will stop direct spoofing of your actual domain once you're at enforcement.
The bits people trip over
Forwarding is the classic problem. An employee forwards mail to a personal account, SPF fails, and if DKIM doesn't survive the forward, DMARC can flag it. Mailing lists can cause similar issues. Third-party platforms sometimes need both an SPF include and a DKIM key, and some need alignment set to relaxed rather than strict. Multiple SPF records on one domain will break things, so consolidate them. And subdomains need their own policy if you want them protected.
None of this is exotic, but it does reward a slow, deliberate rollout.
A sensible timeline for a small firm
Week one: inventory your senders and check existing DNS. Week two: fix SPF and DKIM for the known platforms. Week three: publish p=none with reporting. Weeks five and six: review reports and chase anything unexpected. Week seven: move to quarantine at a low percentage. Week nine: increase to full quarantine, then reject once the reports are clean.
It isn't a silver bullet. DMARC won't stop a compromised mailbox, a convincing display-name spoof from a free webmail account, or a lookalike domain. Pair it with multi-factor authentication, payment verification by phone, and a bit of staff awareness. But as a foundation for stopping someone sending as your domain, it's one of the highest-value bits of DNS housekeeping a small UK business can do in 2026.
