Your invoices land in clients' spam folders, and on top of that someone is sending emails "from your company" with a swapped bank account number. That's not bad luck or fate — it's usually three missing entries in your DNS.
SPF, DKIM and DMARC sound like buzzwords from a sysadmin conference. In practice they're the cheapest and most underrated protection a small company can deploy in a single day. They decide two things every SME owner feels first-hand: whether your emails reach clients at all, and whether a stranger can impersonate your domain and send a fake invoice "from you".
There's no magic and no AI here. It's boring hygiene that almost nobody has configured correctly — and it costs companies real money when it's neglected.
Why this is a problem at all
A typical 20-person company sends email from several places at once, even though the owner usually doesn't know it. There's Microsoft 365 or Google Workspace for the team. There's the hosting (OVH, home.pl) that sends mail from the website and the contact form. There's the ERP or accounting software that sends invoices straight to the client. Sometimes there's a newsletter tool (FreshMail, MailerLite) and some CRM on top of that.
Each of these sends mail "on behalf of" your domain. The receiving server — Gmail, Outlook, the client's mailbox — has to somehow work out which of those messages are genuine and which are someone impersonating you. If you haven't given it the tools to make that call, it has two options: dump the message in spam "just in case", or let the fraudster through too. Both are bad.
At one of our clients — an 18-person building-materials wholesaler — about 30% of invoices were landing in clients' spam. Sales reps were calling customers to ask them to "check the junk folder", which with dozens of invoices a day burned hours. Then came the worse part: a fraudster sent the wholesaler's clients messages that looked like its invoices, with a swapped bank account number. Two clients paid into the wrong account before anyone noticed. After rolling out SPF, DKIM and DMARC with a reject policy, deliverability was back to normal within two weeks, and domain spoofing simply stopped reaching inboxes.
SPF — who is allowed to send on your behalf
SPF (Sender Policy Framework) is just a list. You publish, in your DNS, which servers are allowed to send mail from your domain — for example Microsoft 365's servers, your hosting and your newsletter tool. The receiving server checks that list: if a message arrived from an address that isn't on it, the server knows something is off.
It's one text (TXT) entry in DNS. The most common mistake we see is several separate SPF records on one domain — at which point none of them works properly. There has to be exactly one record, collecting all the sources. The second mistake is exceeding the limit of 10 DNS lookups that an SPF record expands into — with too many services attached, the record becomes invalid and the whole thing falls apart.
DKIM — a seal that can't be forged
SPF says "from which server". DKIM (DomainKeys Identified Mail) goes further and signs every email cryptographically. It's a bit like a wax seal on an envelope: the recipient checks that the message really came from your domain and that nobody altered the content or the sender along the way.
The public key for that seal goes into your DNS, while the private key stays on your mail server. In Microsoft 365 and Google Workspace, turning DKIM on is literally a few clicks plus one DNS entry. The catch is that you have to do it for each source separately — separately for M365, separately for the newsletter, separately for the ERP if it sends invoices from your domain.
DMARC — what to do with a fake
SPF and DKIM only check. DMARC makes the decision. It's a policy in which you tell receiving servers: "if a message passed neither SPF nor DKIM, then do nothing / quarantine it / reject it". Without DMARC, even correct SPF and DKIM won't block impersonation — because nobody knows what to do with a message that failed the test.
DMARC has a second, underrated function: reports. Every day you get a summary of who sent mail on behalf of your domain and whether it passed authentication. For many owners this is the only moment they see in black and white that someone has been trying to impersonate them for months — or that their own accounting software has been sending invoices without DKIM.
How to roll this out without cutting off your own mail
The most dangerous mistake is setting DMARC straight to "reject" (p=reject) before you know who really sends on your behalf. You'll block your own invoices from the ERP or your newsletter — and you'll find out from furious clients. So you go step by step:
- Inventory every sending source: team mail, hosting, ERP/accounting, newsletter, CRM, the website form.
- Configure SPF (one record, all sources) and turn DKIM on for each source separately.
- Set DMARC to observation mode first (
p=none), with reports enabled. - For 2–4 weeks, read the reports and add the missing sources you didn't know about.
- Only once the reports are clean, tighten the policy — quarantine first, then reject.
For a 20-person company the whole operation is usually a few hours of work spread across a month — most of that time is waiting for reports, not configuration.
The most common slip-ups
Beyond jumping straight to p=reject, the things we see most often are: a forgotten source (someone hooked up a mailing tool two years ago and nobody remembers it), several SPF records instead of one, blowing past the 10-DNS-lookup limit, and — the classic — deploying DMARC and ignoring the reports. Reports you never read are like CCTV that doesn't record: it looks like protection, and after the break-in it turns out it gave you nothing.
The second trap is organisational. These entries live in DNS, and DNS is often held by "the website company" from five years ago that nobody can reach anymore. Before you deploy anything, make sure you have access to your domain's DNS panel — without it you'll stall at the starting line.
Where to start
If you don't know whether your domain is protected, the fastest test takes a minute: ask someone outside to check your domain's SPF, DKIM and DMARC records in a free online tool. If any of them is missing — and in an SME at least DMARC is usually missing — your company is at once an easy target for impersonation and a candidate for your clients' spam folder.
This isn't a quarter-long project. It's one well-organised week, after which your mail gets through and your domain stops being a free tool for fraudsters. If you'd like someone to inventory your sending sources and roll this out without cutting off your invoices — get in touch. The first call is free and takes half an hour.
Without DMARC, your domain is a free tool for anyone who wants to send a fake invoice "from you".