The Invoice That Wasn't Yours: Closing the Email Spoofing Door in Half an Hour

A supplier gets an email that looks like it came from your managing director. The display name is right. The tone is right. The bank details are not. The message asks for an urgent payment change and asks the supplier not to ring because everyone is in meetings. If your domain is not protected, that email may not have come from your business at all. It may have come from someone who simply typed your domain name into a From field.

This is email spoofing, and it is the dull cousin of invoice fraud. It does not require anyone to break into your mailbox. It just requires your domain to be unprotected enough that receiving mail servers cannot tell the difference between your real mail and a forgery. The good news is that the fix is not mystical. SPF, DKIM and DMARC sound like a committee meeting, but they are three DNS records and a bit of patience. The half hour gets you started. The full rollout usually takes a few weeks.

What spoofing actually looks like

Spoofing is not the same as a hacked inbox. If someone has your password, that is a different problem. Spoofing is forgery: your domain is used in the From address, but the message is sent from somewhere else entirely. Attackers do it because small UK businesses carry out transactions, pay invoices and hold client data. A convincing message from your finance director can do more damage than a generic phishing email from a stranger.

The warning signs are often small. The display name matches someone senior, but the email address has an extra letter or a different domain after the @. The reply-to address is not the same as the From address. The message is urgent in a way that real colleagues usually are not. Bank details change partway through an existing email chain. The wording is slightly off, or the signature is missing, or the email arrives from outside the normal thread. Staff should be told that any change to payment details gets verified by phone using a number they already hold, not a number in the email.

If a suspicious message has already landed, do not just delete it. Keep the message, preserve the headers if you can, and warn the person or supplier it targeted. If money has moved, call the bank immediately. In the UK, suspicious emails can also be forwarded to the NCSC Suspicious Email Reporting Service at [email protected]. It is not a magic wand, but it helps.

SPF, DKIM and DMARC without the alphabet soup

SPF is a list. It tells receiving servers which systems are allowed to send email for your domain. That list lives in a DNS TXT record and might include Microsoft 365, Google Workspace, your website contact form, your accounts package or a newsletter tool. If a sending server is not on the list, SPF fails.

DKIM is a signature. It lets your mail platform cryptographically sign outgoing messages, and the receiving side checks that signature against a public key published in DNS. If the message has been altered in transit, or the signature is missing, DKIM fails. In Microsoft 365 and Google Workspace, DKIM is usually a switch you enable and a couple of DNS records you publish.

DMARC is the instruction manual. It tells receiving servers what to do when SPF and DKIM do not line up with your domain, and it gives you reports about who is sending mail as you. Without DMARC, a receiving server may still deliver a spoofed message because it has no clear instruction from you. With DMARC, you can start by watching, then move to quarantine, then reject.

The important bit is that DMARC only works properly when SPF and DKIM are in reasonable shape. Do not jump straight to a hard reject policy because a blog post told you to. That is how legitimate invoices end up in junk.

Step 1: Spend ten minutes seeing what is out there

Before changing anything, look at your current DNS. Use a public DNS lookup tool, or ask whoever manages your domain. Check for a TXT record starting with v=spf1 and a TXT record at _dmarc.yourdomain.co.uk. Then look at your mail platform. In Microsoft 365, check DKIM signing in the Defender or Exchange admin centre. In Google Workspace, check the Gmail authentication settings.

Next, make a list of everything that sends email as your domain. This is the bit people skip. Include your website contact form, your CRM, your accounting software, any e-shot or newsletter platform, your payment provider, your scanner if it emails documents, and any line-of-business app that sends notifications. If you use a booking system, it probably sends mail. If you use a recruitment portal, same. Write it down before you touch SPF.

Step 2: Repair SPF and switch on DKIM

You should have one SPF record per domain, not several. If you already have one, add the missing senders as include statements rather than creating a second record. Keep the record under the DNS lookup limit where you can, and end with ~all rather than +all. The +all ending effectively tells the world that anyone can send as you, which is the opposite of what you want.

For DKIM, enable signing in your mail platform and publish the records it gives you. Then send a test email to a service such as mail-tester or check the authentication results in a message header. You are looking for SPF pass and DKIM pass. If either fails, fix that before moving on.

Step 3: Turn on DMARC in monitoring mode

Start with a DMARC record that does nothing except ask for reports. Something like v=DMARC1; p=none; rua=mailto:[email protected]. Publish it at _dmarc.yourdomain.co.uk. Then wait. Two to four weeks is normal. If you have a lot of senders, wait longer.

Read the reports, or use a DMARC reporting service if reading XML sounds like a terrible way to spend a Tuesday. You are looking for legitimate senders that are failing authentication. Update SPF or DKIM for those senders. Do not tighten the policy until the reports are boring.

Step 4: Tighten the policy

When the reports look clean, move to p=quarantine. If you are nervous, use a percentage gradually rather than switching everything at once. After another couple of weeks, move to p=reject. Keep the reporting address in place. This is not a one-off job; senders change, platforms get added, and someone will sign up for a new tool that sends email without telling you.

What staff and suppliers will notice

Some legitimate mail may land in junk during the changeover, especially forwarded mail or messages from old mailing lists. Tell staff that this can happen and ask them to report it rather than whitelisting everything in sight. A broad whitelist can undo the protection you just paid for.

Brief your accountant and key suppliers too. A short note is enough: we have tightened email security, so if you receive a message that looks like it comes from us but asks for new bank details, call the number you already have on file. Add the same warning to your invoice template if you send invoices by email. It sounds obvious, but invoice fraud relies on people being busy and polite.

If you think a spoofed message already landed

Check the headers for SPF, DKIM and DMARC results. Look at the From and Return-Path addresses. If a payment was made, call the bank and report it as a fraud attempt. If a customer or supplier received a fake message, tell them plainly and give them a real phone number to call. If the message came from an actual compromised mailbox rather than a spoofed domain, treat it as a security incident: check sign-in logs, reset passwords, confirm MFA is on and look for suspicious mailbox rules.

The half-hour version is this: check your DNS, list your senders, fix SPF, switch on DKIM and publish a DMARC monitoring record. The full job takes a few weeks of watching and tightening. It is not glamorous, but it is cheaper than explaining to a supplier why your domain sent them a fraudulent invoice.