8 August 2026
How to Stop Scammers From Sending Emails in Your Company's Name

Photo by Brett Jordan on Unsplash
Right now, with no hacking at all, someone could send an email that looks like it came from your business.
They put your domain in the "from" line, email one of your clients or suppliers, and ask them to pay a fake invoice or change bank details. It works because email was never built to check that senders are who they say they are.
Here at Atema, we work with a lot of small and mid-sized businesses across the South West, and this is one of the gaps we see most often when we review a new client's setup. Three settings on your domain, called SPF, DKIM and DMARC, stop this specific trick. Most businesses we look at have one or two configured and the third missing, or they've left the third one on a setting that only watches for abuse rather than actually blocking it. That's usually all it takes to let a spoofed email straight through.
Why scammers can send email in your company's name
Email was built in a more trusting time. The system that delivers mail doesn't, on its own, check that the sender is who they claim to be. The "from" address on an email is about as trustworthy as the return address handwritten on an envelope: anyone can write anything there, and the message still gets delivered.
Spoofing takes advantage of that. A scammer puts your domain in the "from" field, sends the message, and unless your domain is set up to prevent it, the receiving mail server has no reason to question it. The message lands in your client's inbox looking exactly like it came from you. The NCSC publishes anti-spoofing guidance for precisely this reason, and it's one of the first things we check when we take on a new client's IT.
The three records that stop email spoofing
Three DNS records work together to prove an email genuinely came from your domain. You add them once, at your domain registrar or DNS host, and receiving mail servers check them on every message you send.
SPF (Sender Policy Framework)
SPF is a list of the mail servers allowed to send email for your domain, published as a DNS record. When a receiving server gets a message claiming to be from you, it checks whether the sending server is on that list. A server that isn't on the list trying to send as your domain gets flagged.
DKIM (DomainKeys Identified Mail)
DKIM adds a tamper proof signature to every message you send. Your mail server signs outgoing email with a private key, and the matching public key sits in your DNS. The receiving server checks the signature to confirm two things: the message really came from your domain, and nobody altered it along the way.
DMARC (Domain-based Message Authentication, Reporting and Conformance)
DMARC ties the other two together and tells receiving servers what to do when a message fails the check. It also confirms that the domain in the visible "from" address matches the domain SPF and DKIM verified, which is the part that stops someone forging your exact address. It sends you reports too, showing who is sending email using your domain, including the senders who shouldn't be.
The DMARC setting most businesses get wrong
DMARC has three policy settings, and choosing the wrong one is the mistake we see most often.
- p=none tells receiving servers to do nothing when a message fails. It only monitors and sends you reports. Your domain can still be spoofed.
- p=quarantine tells them to send failing messages to the junk folder.
- p=reject tells them to block failing messages before they ever arrive.
A lot of businesses set up DMARC at p=none, watch the reports come in, and never move past it. At p=none, you get visibility but no actual protection. Real protection only starts at quarantine or reject. The NCSC's own guidance is to move to quarantine once you're confident SPF and DKIM are configured correctly, then on to reject as soon as you're confident they're continuing to work, since reject is the setting that actually prevents spoofing rather than just reporting on it.
What SPF, DKIM and DMARC don't stop
These records stop someone forging your exact domain. There are two things they don't catch, and both are worth knowing about.
- Lookalike domains. A scammer can register a domain that resembles yours, such as yourcompany-invoices.com or yourcompany.co instead of .com, and send from that instead. Your records protect your real domain, not a different one the attacker owns.
- Display name spoofing. The name shown in the "from" line can read "Your Company Accounts" while the real address behind it is a random free email account. DMARC checks the domain, not the display name.
For those, your team still needs the habits that catch any phishing attempt: check the full email address rather than just the display name, and verify any request to change payment details by calling a known number, not one taken from the email itself.
Why this matters even if you don't send bulk email
The first reason is protection. These records stop scammers from impersonating your domain to your clients, your suppliers and your own staff.
The second is deliverability. The major mailbox providers now require these records from anyone sending in volume. Since February 2024, Google and Yahoo have required bulk senders, meaning those sending around 5,000 messages a day or more, to have SPF, DKIM and a DMARC record in place. Microsoft brought in a similar requirement for Outlook.com, Hotmail and Live.com from 5 May 2025, and non-compliant bulk mail to those addresses is rejected outright rather than just filtered to junk. Even well below those thresholds, a properly authenticated domain is more likely to land in the inbox than the spam folder.
How to check and fix your domain
You can get a rough sense of where you stand without any technical work. Several free SPF and DMARC checker tools let you type in your domain and see which records exist. That tells you whether the records are present, though not whether they're configured correctly.
Fixing them properly is a job for whoever manages your IT or your domain, since the records live in your DNS and a mistake can send your own legitimate email to spam. The rollout is done in stages:
- Publish SPF and DKIM so all of your genuine mail sources are covered.
- Add DMARC at p=none and read the reports to confirm your legitimate mail passes.
- Move DMARC to p=quarantine, then to p=reject, once the reports look clean.
This is exactly the kind of domain and email housekeeping our cyber security & compliance work covers as part of ongoing support, rather than something left until a client asks why they were sent a fake invoice from "you". If you'd like us to check where your domain currently stands and take it through to p=reject properly, book a call with our team and we'll take it from there.
