Why your business email is being spoofed — and how to stop it

Anyone can send email as you — until your DNS says otherwise

Somewhere in the last few months, one of your customers probably got an email that looked exactly like it came from you — your domain, maybe your usual signature — with a line buried in an invoice saying the banking details had changed. They paid it. The money didn't reach you, and by the time anyone noticed, it was gone.

That isn't a hacked account. It's simpler, and harder to spot: email's default setting is open. Nothing in the underlying protocol stops a stranger's server from putting your exact domain in the "From" line of a message sent to someone else. Your domain is the weapon, your customer is the victim, and you're the one left explaining what happened — because your name is on the invoice they paid.

The fix isn't a new tool or a security subscription. It's three DNS records most small businesses have never touched.

The three DNS records, in plain language

Skip the acronyms for a second. Here's what each one actually does:

• SPF is the published list of mail servers allowed to send email for your domain. Anything not on the list is a signal to the receiving server that the message doesn't belong.
• DKIM is a cryptographic signature attached to every outgoing message, proving it left your real system and wasn't altered along the way.
• DMARC is the instruction telling a receiving server what to do when a message fails SPF or DKIM — do nothing, quarantine it, or reject it outright — and it sends you reports on exactly who is sending mail as your domain, spoofers included.

SPF and DKIM authenticate. DMARC enforces, and tells you what's actually happening across your domain. None of the three does much on its own; the value is in running all three as a set.

Why "we'll do it later" expired in 2026

Two dated shifts closed that option.

First, the big receivers moved the goalposts. Google, Yahoo and Microsoft now require SPF, DKIM and a published DMARC record from anyone sending bulk email — Microsoft's requirement for its consumer platforms took effect in May 2025. You don't need to be running a marketing list to feel this: an unauthenticated domain increasingly lands in spam even when nobody is actively spoofing it, simply because it reads as unverified to the receiving server.

Second, in May 2026 the IETF published RFC 9989, obsoleting the older RFC 7489 and putting DMARC on the Standards Track as a proposed standard for the first time. That's not "DMARC is now the law of email" — it's one formal step in a standards process — but it ends the excuse that DMARC is still experimental or a nice-to-have extra. (If you want the wider mechanics of how spoofing and phishing chain together, our cybersecurity checklist covers that ground.)

The POPIA angle: when "nice to have" becomes "reasonable measure"

Section 19 of POPIA requires "appropriate, reasonable technical and organisational measures" to secure personal information, with "due regard to generally accepted information security practices." A recent industry analysis argues — and this is an argument, not a ruling — that once the major mailbox providers and the IETF treat SPF, DKIM and DMARC as baseline practice, an unauthenticated domain becomes harder to defend as "reasonable."

The Information Regulator hasn't fined anyone specifically for a missing DMARC record. But the enforcement direction is real: it fined the Department of Justice R5 million in 2023 for ignoring an enforcement notice (not for an email misconfiguration), Section 109 caps administrative fines at R10 million, and enforcement notices keep landing — Central Johannesburg TVET College received one on 22 May 2026. None of that is about email authentication specifically. All of it points the same way. (More on POPIA compliance.)

Check your own domain in five minutes

Before fixing anything, find out where you actually stand. Paste your domain into any free SPF/DKIM/DMARC checker, or ask whoever manages your email to. You'll land in one of three places:

1. All three present and passing. Good — just confirm DMARC isn't still sitting at p=none (monitor-only) a year after you set it up.
2. Some present. You're partway through the job. Finish it.
3. None present. Your domain is usable against your own customers, today, by anyone who tries.

The one-afternoon fix, in the right order

The sequence matters more than the urgency. Get it wrong and you can break your own outgoing mail before you've fixed anything.

1. Publish SPF first. List every real sender on your domain — your mail host, your invoicing system, any newsletter tool. Miss one and its mail starts failing silently.
2. Turn on DKIM signing at your mail host. Microsoft 365, Google Workspace and most South African hosting panels have it built in — a toggle and a DNS record, not a project.
3. Publish DMARC at p=none first — monitor mode only. Run it for a couple of weeks and read the reports; they'll show you every service sending mail as your domain, including ones you'd forgotten you ever connected.
4. Only then tighten to quarantine, and eventually reject. Jumping straight to reject is how a business discovers, the hard way, which of its own tools it forgot to whitelist.

Three DNS records, one afternoon of setup, plus a few weeks of patience before you switch on full enforcement. That patience is the part a rushed checklist skips — and it's the part that keeps you from blocking your own invoices while trying to stop someone else's fake ones.

If the person who set up your email years ago hasn't touched the DNS since, that's worth a second pair of eyes — see our IT support page for what that looks like in practice.

Want someone to check and set up your SPF, DKIM and DMARC properly — records published, reports monitored, enforcement tightened without breaking your own mail? Get in touch.

General information, not legal or tax advice.