Email Spoofing: How to Detect and Prevent It

Spoofing is cheap, fast, and effective. The "From" address you see in your inbox is just a line of text — nothing in the original email protocol checks whether it is true. That single design gap is why a criminal can send a message that looks like it came from your finance director, your bank, or your own domain. The good news: the fix is well understood, and most UK businesses are running it badly or not at all. This guide explains what email spoofing is, how it works, and the exact DNS controls that shut it down.

What is email spoofing and why does it matter?

Email spoofing is forging the sender address of an email to make it appear to come from a different domain or person. Because the "From" header is unauthenticated text, anyone can set it to any value. For a business, that means criminals can impersonate your brand to your customers, or impersonate trusted senders to your staff.

Spoofing takes two damaging forms:

• Inbound spoofing — criminals send your staff emails that falsely claim to come from HMRC, your bank, a known supplier, or your own CEO. This is the engine behind invoice fraud and CEO fraud.
• Outbound spoofing — criminals put *your* domain in the "From" field of emails they send to your customers, suppliers, and the public, borrowing your brand's credibility for their phishing.

Both hurt. Inbound spoofing deceives your employees; outbound spoofing of your domain damages your reputation and harms the people who trust you. Phishing, which spoofing makes more convincing, is the most common type of cyber attack on UK businesses, according to the government's Cyber Security Breaches Survey 2025. If you want the human-layer defence as well as the technical one, our managed phishing protection pairs domain authentication with staff training. Locking down spoofing is a core part of managed cybersecurity — one provider, security-first.

How does email spoofing work technically?

SMTP, the protocol that transmits email, was designed in an era when mail servers trusted each other by default. The sending server announces itself and a sender address using EHLO and MAIL FROM, but the original protocol has no way to verify either claim. There is also a gap between the envelope sender (MAIL FROM) and the "From" header your client actually displays.

Criminals exploit this by running their own mail server and setting the "From" header to impersonate a legitimate domain. Basic spam filters catch the obvious cases, but without authentication protocols built specifically to defeat spoofing, plenty of fraudulent mail still lands in inboxes. The fix is not a filter — it is three published DNS records that let receiving servers check whether mail claiming to be from your domain is genuine. The UK's National Cyber Security Centre treats these as baseline controls in its email security and anti-spoofing guidance.

SPF, DKIM and DMARC — what does each one do?

These three records work as a chain. SPF lists who is allowed to send for you, DKIM cryptographically signs your mail, and DMARC tells receivers what to do when a message fails. None is sufficient alone; together they make your domain very hard to forge.

How does SPF authorise your sending sources?

Sender Policy Framework (SPF) lets a domain owner publish a DNS record listing the IP addresses and services authorised to send email for that domain. When a receiving server gets inbound mail claiming to be from you, it checks the sending IP against your SPF record. A pass means the source is on your list; a fail flags it.

The most common SPF mistake is an incomplete record. Cloud CRM platforms, marketing automation tools, transactional email services, and helpdesk systems all send on your behalf and must be included, or their genuine mail gets flagged. The trailing qualifier also matters: `~all` (soft fail) tells receivers to accept-but-mark suspicious mail, while `-all` (hard fail) tells them to reject it outright. Get the inventory right before you harden the qualifier.

How does DKIM prove a message is authentic?

DKIM (DomainKeys Identified Mail) adds a digital signature to every outbound email using a private key held by your mail server. The matching public key is published in your DNS. Receiving servers verify the signature, confirming the mail came from an authorised source and that its content was not altered in transit.

DKIM survives forwarding, as long as the message body is not modified — which makes it more durable than SPF when mail passes through mailing lists or relays. Without it, an attacker who intercepts the delivery path could alter content undetected. If you want the mechanics in depth, see our explainer on DKIM email authentication for business.

How does DMARC enforce the policy?

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the layer that puts SPF and DKIM to work. A DMARC record in your DNS tells receiving servers what to do when mail claiming to be from your domain fails authentication, and it requests reports so you can see who is sending as you.

The policy has three settings:

• p=none — take no action, but send reports (monitoring mode)
• p=quarantine — deliver failing mail to spam/junk
• p=reject — refuse delivery entirely

A policy of p=reject is the strongest protection against domain spoofing: failing mail is refused at the receiving server and never reaches the recipient. But jumping straight to p=reject without first auditing your legitimate senders risks blocking real email. Our full walkthrough of what DMARC is and how to roll it out covers the staged approach.

How do you roll out DMARC without breaking real email?

Deploy in stages. Start at p=none with a reporting address, use the aggregate reports to find every legitimate source, fix their SPF and DKIM, then move up to quarantine, then reject. Rushing to reject before your senders all pass is the single biggest cause of self-inflicted email outages.

The recommended sequence:

1. Publish p=none with a DMARC aggregate (RUA) reporting inbox or service. 2. Read the reports. RUA data lists every source sending mail from your domain and its pass/fail rate — including shadow systems IT forgot about. 3. Fix legitimate senders so they all pass SPF and DKIM. 4. Advance to p=quarantine for several weeks and review for false positives. 5. Move to p=reject once the reports are clean.

This typically takes four to eight weeks. AMVIA configures SPF, DKIM and DMARC for UK businesses and manages the progression from monitoring through to full rejection, so legitimate mail keeps flowing while fraudulent use of your domain is blocked. We run this alongside a managed email security gateway and Microsoft Defender for Business so the inbound and outbound sides are covered by one accountable provider.

What about lookalike domains that DMARC can't stop?

DMARC protects your exact domain but cannot stop criminals registering a lookalike — for example amvla.co.uk instead of amvia.co.uk — and sending from it. Lookalike domains pass DMARC because they carry their own valid authentication records. Defending against them needs a different layer.

Effective countermeasures:

• Defensive registration — buy the obvious typo variants of your domain before someone else does.
• Domain monitoring — a service that alerts you when a near-match domain is registered.
• Staff awareness — train people to inspect sender addresses character by character, especially on payment requests.
• Gateway detection — many email security gateways flag mail from domains that closely resemble yours or other trusted domains.

Treat domain authentication and lookalike defence as two halves of the same job. One closes the door on your domain; the other watches for criminals building a copy of it next door.