Email Spoofing: How to Detect and Prevent It

What is email spoofing?

Email spoofing is the practice of forging the sender address of an email to make it appear to have come from a different domain or individual. The from field in an email — the part that displays in your inbox — is simply a piece of text included in the message, not an authenticated claim. Without countermeasures, anyone can set this field to any value they choose.

For businesses, spoofing takes two forms. Inbound spoofing is when criminals send emails to your staff that falsely claim to come from trusted sources — HMRC, your bank, a known supplier, or even your own CEO. Outbound spoofing is when criminals use your domain in emails they send to others — your customers, suppliers or the general public — to give their phishing campaigns the credibility of your brand.

Both forms are damaging: inbound spoofing deceives your employees, while outbound spoofing of your domain damages your reputation and harms your customers.

How email spoofing works technically

SMTP, the protocol that transmits email, was designed in an era when trust between mail servers was assumed. The original protocol includes an EHLO/MAIL FROM command — the sending server identifies itself and the sender address — but there was no mechanism to verify these claims. Modern email clients display the From header address, not the MAIL FROM (sometimes called the envelope sender), which creates further opportunities for misdirection.

Criminals exploit this by registering their own mail servers and setting the From header to impersonate legitimate domains. Basic spam filters may catch obvious cases, but without authentication protocols specifically designed to address spoofing, many fraudulent emails reach inboxes.

SPF: authorising your sending sources

Sender Policy Framework (SPF) allows a domain owner to publish a DNS record listing the IP addresses and mail services authorised to send email on behalf of that domain. When a receiving server processes an inbound email claiming to be from your domain, it checks the sending IP against your SPF record.

A common SPF misconfiguration is having an incomplete record that does not include all legitimate sending services — cloud CRM platforms, marketing automation tools, transactional email services and helpdesk systems all send email on behalf of the business and must be included. An SPF record with a hard fail qualifier (~all vs -all) also affects how strictly receiving servers act on failures.

DKIM: cryptographic proof of authenticity

DKIM adds a digital signature to every outbound email using a private key held by your mail server. The corresponding public key is published in your DNS. Receiving servers can verify the signature, confirming both that the email originated from an authorised source and that the message content was not altered in transit.

DKIM is effective even when email passes through forwarding intermediaries, as long as the message content is not modified. Without DKIM, an attacker who compromises the delivery path between sender and recipient could modify message content undetected.

DMARC: the enforcement layer

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the protocol that puts SPF and DKIM to work. A DMARC record in your DNS tells receiving mail servers what to do when an email claiming to be from your domain fails SPF or DKIM checks:

• p=none: Take no action, but send reports (monitoring mode)
• p=quarantine: Deliver to spam/junk folder
• p=reject: Refuse delivery entirely

A DMARC policy of p=reject is the strongest protection against domain spoofing — emails that fail authentication are refused delivery at the receiving server, preventing them reaching recipients. However, moving directly to p=reject without first auditing your legitimate sending sources risks blocking genuine email.

The recommended approach: deploy DMARC with p=none and set up a DMARC reporting inbox or service. DMARC aggregate reports (RUA) show you every source sending email from your domain and their authentication pass/fail rates. Once all legitimate sources pass SPF and DKIM, advance to p=quarantine for several weeks, review reports for false positives, then move to p=reject.

Lookalike domain attacks: beyond DMARC

DMARC protects your exact domain but cannot prevent criminals registering lookalike domains — amvla.co.uk instead of amvia.co.uk, for example — and sending email from those. Lookalike domains pass DMARC checks because they have their own authentication records.

Countermeasures include: registering common typo variants of your domain defensively; using a domain monitoring service that alerts you when lookalike domains are registered; and training staff to inspect sender addresses carefully. Some email security gateways include lookalike domain detection that flags emails from domains that closely resemble your own or other specified trusted domains.

AMVIA configures SPF, DKIM and DMARC for UK businesses and manages the progression from monitoring through to full rejection policy, ensuring legitimate email continues to flow whilst fraudulent use of your domain is blocked.