Your busiest weeks are when invoice and wire fraud gets traction. Not because your team is careless, but because the process is moving fast, vendors are emailing “quick updates”, and everyone’s trying to keep cashflow tidy.

If you want a simple, realistic defence, do two things at the same time: make it harder to spoof your email domain (DMARC, SPF, DKIM), and make it harder for a single email to change where your money goes (an approval workflow with out-of-band verification).

Why busy season and new vendors are the danger zone

Most invoice and wire fraud is not fancy malware. It is someone sending a convincing email that looks like it came from a vendor, or from one of your execs, asking for a payment or a change in payment details.

The FBI’s guidance on business email compromise calls out the exact scenario many finance teams see: a vendor “updates” payment instructions, or an invoice arrives with a new remit-to address or account number. The common thread is the same: a normal business request, delivered through a channel that is easy to fake.

Two moments make this worse:

  • End-of-month and end-of-quarter pressure. You have more invoices, more approvals, more “can we get this out today?” messages.
  • New vendor onboarding. Your vendor master file is changing, bank details are being entered for the first time, and nobody has a long history with the contact yet.

Email authentication in plain English: SPF, DKIM, DMARC

Email authentication is one of those topics that sounds technical, but the idea is straightforward. You are publishing “proof points” in DNS that help other mail systems decide whether an email that claims to be from your domain is actually allowed to be.

Here is the simplest way to think about the three pieces:

  • SPF (Sender Policy Framework). A list of which mail servers are allowed to send email for your domain. If a message claiming to be from your domain comes from somewhere else, SPF can fail.
  • DKIM (DomainKeys Identified Mail). A digital signature added to your outbound email so receivers can verify the message was not altered and that it is associated with your domain.
  • DMARC (Domain-based Message Authentication, Reporting, and Conformance). The “policy layer” that ties SPF and DKIM to the visible From address, tells receivers what to do when checks fail, and sends you reports so you can see what is happening.

The FTC explicitly recommends SPF, DKIM, and DMARC for small businesses, because without them scammers can impersonate your domain and send email that looks like it is from you.

A practical DMARC setup that does not break your email

The biggest mistake we see is treating DMARC as a one-and-done DNS change. If you publish a strict policy before your legitimate senders are properly configured, you can cause real delivery problems.

A sensible rollout looks like this:

  • Start with an inventory. List every system that sends email as your domain, not just Microsoft 365 or Google Workspace. Think: accounting system, CRM, marketing platform, payroll, ticketing, copier/scanner, website forms.
  • Get SPF right first. In Microsoft 365, Microsoft notes that you typically already created or modified an SPF TXT record during domain setup, but you still need to make sure it reflects your real sending sources.
  • Turn on DKIM signing for your domain. Microsoft’s guidance is clear that DKIM alone is not enough to prevent spoofing, but it is a key building block for DMARC.
  • Publish DMARC in stages. Many organisations begin with a monitoring-only policy (p=none) to collect reports, then move to quarantine, then reject once they are confident legitimate mail is aligned.

If you are thinking, “Okay, but who reads DMARC reports?”, that is a fair question. The answer is either (1) use a reporting tool that turns them into something readable, or (2) have your IT partner monitor and tune it with you. The point is not pretty charts, it is catching misconfigured systems before you enforce a stricter policy.

The other half: an approval workflow that forces a safe double-check

DMARC reduces spoofing of your domain. It does not stop a criminal from emailing you from a look-alike domain, or from a compromised vendor mailbox. That is why your payment process needs a backstop.

The control that stops the most expensive mistakes is simple: changes to bank details and high-dollar payments must be verified out of band, using contact details you already had on file before the request arrived.

The FBI’s BEC guidance says to verify changes in account number or payment procedures, and to look up the company’s phone number yourself rather than using the one provided in the message.

Here is what this looks like as a lightweight, automatable workflow.

  • Trigger: “bank details changed” request. Any request to add or modify ACH or wire details automatically creates an approval task.
  • Two-person rule. The person who updates vendor banking details cannot be the same person who approves the change.
  • Out-of-band verification required. The approver must confirm the change using a known-good phone number from your vendor file, a contract, or the vendor’s public website (not the email signature).
  • Hold period for first payment. After a banking change, hold the first payment for a set time window (even a few hours helps) so a rushed change cannot turn into a rushed wire.
  • High-dollar step-up. Payments over a threshold (you pick the number) require a second approver and a call-back, even if bank details did not change.
  • Documentation built in. The workflow should require a short note: who was called, which number was used, who confirmed, and when.

This is where “automation-productivity” pays off. You are not asking people to be more vigilant all day. You are designing the process so the risky moments automatically slow down and get checked.

A quick checklist you can use this week

If you want to tighten this up without a big project, start here:

  • Confirm you have SPF, DKIM, and DMARC on your main domain. If you are not sure, ask your IT team for a simple pass/fail summary and what policy your DMARC record is set to.
  • Write one rule for finance. “We never change bank details based on email alone. We call a known number and document it.” Put it in your AP runbook.
  • Add one workflow gate. Even a basic approval tool can enforce “bank changes require two approvals and a call-back note.”
  • Train vendors too. Tell new vendors up front how you verify bank changes so they do not get annoyed when you call. Good vendors will respect it.

Make this boring, repeatable, and easy to audit

The goal is not to turn your AP team into detectives. It is to make fraud attempts fail quietly because your email domain is harder to spoof and your payment process refuses to act on a single message.

If you would like help setting up DMARC correctly and building an approval workflow for vendor bank changes and high-dollar payments, the Flexnet Networks team can help you design and implement a setup that fits how your business actually runs.

Sources