The R1 Million Email: How to Shield Your Sales Team from Procurement Scams and Operational Chaos

It starts with an email that feels like a lottery win.

A prospective client — let's call them a corporate procurement entity — reaches out. They want a quote for a massive order: high-end laptops, specialised software, monitors and more. The total value is well over a million Rand.

Your sales team springs into action. They spend hours meticulously checking specifications, sourcing exact SKUs, calculating exchange rates, and putting together a highly professional, detailed quotation. There's a buzz in the office. This is the deal that could make the quarter.

Then the red flags start to creep in.

The prospective client's LinkedIn profile hasn't been active in seven years. The company website is a generic template. The specifications in their RFQ contradict themselves. And when you check the email headers, you realise the "corporate" email was sent from a residential laptop IP address, routed through a foreign hosting provider.

It's a scam.

Suddenly that million-Rand deal evaporates, and your sales team is left deflated, having wasted days of productivity on a ghost.

As a business owner, you know this feeling. But what many don't realise is that inbound scams like this are only half the battle. The other half — the side that generates the endless internal drama — is what happens when scammers use your domain to target others, or when your internal processes aren't strong enough to stop the chaos before it starts.

Here's how to build a defence-in-depth strategy that protects your business, your reputation and, most importantly, your sales team's sanity.

The Real Cost: Sales Team Drama

Most businesses think of email security as an IT issue. But bad email infrastructure is an operational time bomb. It turns your sales team into scam detectors, and it creates a cycle of internal drama:

• The "Chasing Ghosts" drama. Your team spends ten or more hours building quotes for orders that were never real. That's ten hours they could have spent closing deals that pay.
• The "Internal Blame Game" drama. When a scammer spoofs your CEO's address and tells a junior salesperson to urgently release stock to a new delivery address, it creates panic. If they do it, the company loses money. If they don't, they feel they've let the boss down. Either way, they were set up to fail by a system that put the decision on them.
• The "Is the Money Real?" drama. A team gets excited over a flawless PDF proof of payment, promises stock to the "client", and then watches the funds fail to appear — days later, after the expectation has already been set.

To remove that drama you have to address two separate things: the technical infrastructure around your domain, and the internal protocol your team follows when money moves. Neither one covers for the other.

How to Tell If You're Protected Right Now

Before fixing anything, it's worth knowing where you actually stand. This takes about ten minutes and needs no specialist tools.

Check your DMARC record

Look up the TXT record on _dmarc.yourdomain.co.za using any free DNS lookup tool. There are three possible outcomes, and only the third is real protection:

• No record at all. Anyone on the internet can send email that appears to come from your domain. This is the situation behind the majority of spoofed-invoice cases we see.
• p=none. You're collecting reports but blocking nothing. Spoofed mail still lands in inboxes. Most businesses that think they're protected are sitting here.
• p=quarantine or p=reject. You're publishing an enforceable policy. That's the goal — with one important caveat we'll get to below.

Read an email's authentication results

Send a message from your own domain to a Gmail or Outlook account, open it, and choose "Show original" or "View message source". You'll see three verdicts for that message: SPF, DKIM and DMARC, each marked PASS, FAIL or NONE.

Three passes means the mail you send is properly authenticated. A FAIL tells you exactly which system is misconfigured — and it's the kind of thing most providers only discover when they go looking for it, rather than hearing about it from a client whose invoices stopped arriving.

List every system that sends mail as you

This is the step almost everyone skips, and the one that causes the damage later. Every one of these has to be declared in SPF, or signing with DKIM, before a strict policy is safe to publish:

• Your website's contact form
• Accounting and invoicing software
• Payroll and HR systems
• Your CRM or ticketing tool
• E-commerce and order notifications
• Any newsletter or marketing platform
• Shared mailboxes, document scanners and multifunction printers

Miss one and a strict DMARC policy will quietly block your own business email. That's not a hypothetical — it's the single most common way an email-authentication project goes wrong.

The Technical Shield: Stop Making Your Sales Team the Firewall

You cannot expect your sales staff to analyse email headers, check IP addresses or verify DNS records — and you shouldn't. The technology has to do that for them.

What SPF and DKIM actually do

SPF is a DNS record that publishes a list of servers allowed to send email for your domain. When a receiving server gets a message claiming to be from you, it checks that list. Think of it as the digital ID card for your mail.

DKIM goes further. It attaches a cryptographic signature to each outgoing message, which the receiving server verifies against a public key published in your DNS. Because the signature covers the message contents, altering the body in transit breaks it. SPF says "this server may send mail for us"; DKIM says "and this message genuinely came from that server, unmodified".

Neither is enough alone. SPF breaks down the moment a message is forwarded — it checks the envelope, not the visible From address — and neither one tells a receiving server what to do when something fails.

What DMARC does — and the mistake most businesses make

DMARC is the policy layer that ties SPF and DKIM together. It lives in a DNS record of its own, at _dmarc.yourdomain.co.za, and it does two jobs: it requires that SPF or DKIM be aligned with the visible From address, and it tells receiving servers what to do when neither passes.

Most businesses that have a DMARC record have it set to p=none. That's monitoring mode. It collects reports about who is sending as you, and it blocks absolutely nothing. A scammer can still send an invoice that appears to come from your domain, and it will still arrive.

Now the part where most email-security advice goes wrong. You will read, often, that you should simply "set your DMARC policy to p=reject". Don't — not yet. If you jump to reject on day one, you will start losing your own legitimate mail: contact-form enquiries, invoices, payroll notifications, the CRM alert that tells your sales team a deal moved. Those senders haven't been declared yet, so they fail the check. Rejections fail silently at the receiving end, so nobody notices until a client asks why your invoices stopped coming.

The four-step rollout

• Step 1 — Monitor. Publish v=DMARC1; p=none; rua=mailto:[email protected] and start collecting reports. Change nothing behavioural yet. This step exists to tell you who actually sends on your behalf.
• Step 2 — Align every sender. Work through the list from the previous section and get each one into SPF, or signing with DKIM, or both. Keep reading the reports until legitimate mail passes consistently.
• Step 3 — Quarantine. Move to p=quarantine. Failing mail goes to spam rather than the bin. If anything legitimate still shows up in junk, you've found another sender to align — and you've lost nothing in the process.
• Step 4 — Reject. Only once the reports show your own senders passing cleanly. Now failing mail is refused outright, and nobody can send mail that pretends to be you.

Two practical notes. The rua address receives machine-generated XML reports, not human mail — point it at a dedicated address or a reporting service, or your inbox fills with files nobody can read. And SPF has a hard limit of ten DNS lookups; a business with a long list of sending platforms can exceed it, at which point receivers stop evaluating and you start failing. That usually means consolidating senders, or moving one onto a dedicated subdomain with its own SPF and DMARC records.

If this isn't something your team has the appetite to own, it is ordinary business IT support work. DNS records, sender alignment and report monitoring are the kind of unglamorous infrastructure tasks we handle for clients as part of looking after their everyday technology.

One honest caveat

Your DMARC record protects your domain's reputation outward. It does not filter the mail coming in to you. Inbound filtering is the job of your mailbox provider's own checks — which is why you should never let anyone whitelist or bypass the spam filter in order to "make sure nothing gets missed".

Blocking spoofed mail that claims to be one of your suppliers is a different problem entirely, and it's the one that costs the most money.

The Scam That Costs the Most: A Changed Bank Account

Inbound fake RFQs waste your team's time. Domain impersonation damages your reputation. But the variant that actually moves money out of South African businesses is quieter, and it rarely looks like a scam at all.

Here's the pattern. You have a real supplier. You have a real order, an agreed price, and an expected invoice. The invoice arrives — maybe a day late, maybe exactly on time. The amount is right. The order reference is right. Everything about it is correct except one detail: the banking details have changed.

The message explaining this usually reads something like "please update your records, our banking details have changed", and it frequently arrives inside an existing email thread, which is part of why it works. The person paying isn't being tricked into paying a stranger. They're being tricked into redirecting a payment they were always going to make. The funds clear. They clear into the wrong account. And by the time anyone notices, they've moved again.

Notice what that does to your "clear funds" control. The funds did clear. Payment verification doesn't catch this one, because nothing about the payment itself is unusual.

Why a strict DMARC policy doesn't stop it

DMARC stops someone sending mail that pretends to be your domain. It does nothing about an attacker who has actually gained access to a legitimate mailbox — the supplier's, or a colleague's. Mail from a compromised account authenticates correctly, because it genuinely was sent from that account. It passes SPF, DKIM and DMARC, and it looks exactly as trustworthy as every other message that supplier sends.

Which is why technical controls and process controls have to work together. Authentication raises the cost of impersonation. Process is what catches the case where impersonation was never needed.

The tells

• An unsolicited change to banking details, however routine it is made to sound.
• A reply that arrives inside an existing thread from a slightly different address. Check the actual From and Reply-To fields, not the display name.
• Urgency tied to a deadline: month-end cut-off, stock release, "please pay today so we can despatch".
• A lookalike domain — an extra letter, a hyphen swapped for a period, a .co.za standing in for a .com.
• An invoice attached as a PDF when your normal process is a portal, a link, or a system-generated email.
• The stated reason for the change quietly disappearing from later messages in the same thread.

The Operational Shield: Five Rules for Your Sales Team

Technology alone won't stop a determined scammer if your internal processes are weak. These five rules take the emotional pressure off the decision, so your team isn't relying on instinct in the moment.

1. The "Clear Funds" rule

No order is placed, and no stock is released, until payment reflects as cleared in your actual bank account. A PDF proof of payment is not acceptable — scammers generate flawless ones in seconds. Check the balance in your own online banking portal, and wait for the funds to genuinely settle rather than showing as pending.

2. The "Verify the Client" rule

Any RFQ above an agreed threshold — R500,000 is a reasonable place to start — requires independent verification before your team invests serious time in it:

• Look the company up on the CIPC register to confirm it exists, and check who its directors actually are.
• Request a short video call with the procurement officer. Scammers refuse these almost universally, because a call exposes their location and their face.
• Ask for a landline and phone it. A number that only ever rings a mobile — or a switchboard that has never heard of the person — tells you plenty.

3. The "Call Back" rule for banking details

Any request to change banking details is confirmed by phoning a number you already hold: from the signed contract, a previous invoice, or the supplier's own website. Never a number supplied in the email requesting the change, and never a number that appears only in the new document.

Two additions make this stick in practice. The person who makes the call should not be the person who received the email. And any change to a beneficiary should need a second authorisation before it goes live. Both are cheap, and both remove the single point where these attacks succeed.

4. The "Trust Your Gut" rule

If the order looks too big, the specs are oddly specific, or the language feels slightly off, flag it. Build a culture where nobody is in trouble for flagging something that turns out to be genuine — the cost of checking a real order is a five-minute call. The cost of not checking is your quarter.

5. The "Ignore and Delete" rule

Once a scam is identified, block the sender and delete the email. Don't reply, and don't try to waste their time. Replying confirms that your address is live and monitored by a human — which is exactly the signal that puts you on a list for the next attempt.

If You Think You've Already Paid: The First Hour

Speed matters enormously here, and it's measured in hours rather than days. Work through this in order.

• Call your bank's fraud line immediately and ask them to attempt a recall on the payment. If the money hasn't left the receiving institution yet, a fast call is the difference between a recovery and a write-off.
• Open a case with SAPS and keep the case number. Your bank and your insurer will both ask for it.
• Notify your insurer and check whether you carry cyber-crime or commercial-crime cover. Many policies treat this differently from theft, and some exclude it entirely — better to find out now than at claim stage.
• Tell the supplier whose name was used, so they can warn their other customers and secure their own mailbox. You may not be the only target.
• Preserve the evidence before deleting anything: the email with its full headers, the invoice file, the bank confirmation. This is much harder to reconstruct later.
• Change passwords and switch on multi-factor authentication for any mailbox involved, and check for forwarding rules you didn't create. Attackers routinely leave a silent forward in place for next time.
• Check what personal information was exposed. Under POPIA, a security compromise affecting personal information can carry a duty to notify the Information Regulator and the affected people. That obligation doesn't disappear because the attacker was external.

Where Supplyd Fits

We are not an email security vendor, and this article isn't a pitch for one. But the technical half of this problem — SPF, DKIM, DMARC records, aligning every system that sends as you, and monitoring the reports while the policy moves from monitoring to quarantine to reject — is exactly the kind of infrastructure work that sits inside ongoing business IT support.

The same applies to the hardware these scams are usually about. Whether you're buying a fleet of laptops or sourcing IT equipment and office supplies on a recurring basis, the procurement process behind the order matters as much as the order itself — and we've written before about where procurement quietly leaks money and about the hidden cost of buying business technology. If you would rather hand the whole function over, that is what our business procurement service exists for.

The Bottom Line

Setting up your email correctly isn't just an IT project. It's a sales enablement tool. It spares your staff the emotional rollercoaster of chasing fake deals and lets them focus on the clients who actually pay.

Stop making your sales team the firewall. Build the firewall around them: lock down your domain with SPF, DKIM and a DMARC policy that ramps properly to reject, and put a call-back rule in front of every change to banking details. Technical controls stop people pretending to be you. Process controls are what stop everything else.

Building digital infrastructure that businesses can rely on isn't only about technology — it's about giving your team the peace of mind to do their best work.

Frequently Asked Questions

What is the difference between SPF, DKIM and DMARC?

SPF publishes a list of servers that are allowed to send email for your domain. DKIM attaches a cryptographic signature to each outgoing message so receiving servers can verify it wasn't altered in transit. DMARC ties the two together and tells receiving servers what to do when both fail. You need all three — SPF and DKIM on their own leave the receiver with no instruction about what to do when a message fails verification.

Can I switch my DMARC policy straight to reject?

No, and this is the most common and most costly mistake. If you publish p=reject before every legitimate system that sends as your domain is aligned, you will start losing your own mail — contact-form enquiries, invoices, payroll and CRM notifications — because those senders aren't declared in SPF or signed with DKIM yet. Rejections fail silently, so nobody notices until a client asks why your invoices stopped arriving. The correct path is p=none to collect reports, align every sender, then p=quarantine, then p=reject.

How long does email authentication take to set up?

The technical work is quick. SPF and DKIM records for your main sending systems are typically a few hours. The DMARC policy is the slow part, and deliberately so: you need a few weeks of report data to discover every system sending as your domain before you can safely move to quarantine and then reject. Plan on a few hours of work spread across two to six weeks.

Will a strict DMARC policy stop all procurement scams?

No. A reject policy stops someone sending mail that pretends to be your domain, which closes off fake invoices issued in your name. It does nothing about a scammer who has gained access to a genuine mailbox, because mail sent from a compromised account authenticates correctly. Authentication raises the cost of impersonation; process is what catches the case where impersonation was never needed.

What should our rule be on changes to banking details?

Any change to banking details is confirmed by phoning a number you already hold — from the signed contract, a previous invoice or the supplier's own website. Never a number supplied in the email requesting the change. Ideally a different person makes the call than the one who received the email, and the new beneficiary needs a second authorisation before it goes live.

Is this relevant to a small business, or only to corporates?

It's arguably more relevant to a small business. Smaller companies are targeted precisely because they process invoices with fewer checks and less separation between the person who approves a payment and the person who releases it. A five-person team with no call-back rule and no DMARC policy is a softer target than a corporate with a finance department — and the loss, relative to turnover, is far bigger.

Keep Reading

Related reads from the Supplyd blog:

• Where Is Your Business Losing Money in Procurement? — the leakage most companies never see.
• The Hidden Cost of Buying Business Technology — what a "cheap" purchase really costs once downtime is counted.