Stopping email fraud: BEC, phishing and domain spoofing

24 June 2026 · DMARC Engine · 12 min read

Email fraud is the cheapest, most reliable attack on the internet, and almost all of it begins with a single deception: a message that appears to come from someone you trust. Whether the goal is to harvest a password, redirect a payment or trigger a wire transfer, the attacker's leverage comes from impersonation. This guide explains, in technical detail, the distinct mechanisms behind exact-domain spoofing, look-alike domains, display-name spoofing, business email compromise (BEC) and invoice fraud. It then sets out precisely what DMARC does and, just as importantly, does not stop, and finishes with a layered defence plan you can actually implement.

If you only remember one thing: email authentication closes one specific, high-value door. It is essential, but it is not the whole house.

The anatomy of an email address

To understand spoofing you first have to understand that a single email carries two "from" identities, and they need not match.

• The envelope sender (RFC 5321 MAIL FROM), also called the Return-Path or bounce address. This is used during the SMTP conversation between mail servers and is where bounces go. Recipients almost never see it.
• The header From (RFC 5322 From:). This is the human-readable "From" shown in the mail client, typically Display Name <local@domain>. This is the identity your users actually trust.

These two addresses can legitimately differ (mailing lists and many ESPs rely on it), but the gap between them is exactly where attackers operate. SPF authenticates the envelope domain. DKIM authenticates a signature over selected headers and body. DMARC's contribution is to require that one of those passing identities is aligned with the visible header From domain, closing the gap.

Threat 1: Exact-domain spoofing

This is the purest attack. The fraudster sends mail where the visible From: is literally ceo@yourcompany.com, your real domain, character for character. There is nothing subtle to spot; the address is genuine, only the sender is not authorised.

From: "Jane Okafor" <jane.okafor@yourcompany.com>
Subject: Quick favour before my flight

Historically this worked because SMTP has no built-in authentication: any server may claim to send as any domain. Exact-domain spoofing is the threat that DMARC was designed to kill, and it is the one place where DMARC is decisively effective. A correctly published, enforced DMARC policy means an unauthorised server cannot deliver mail that passes alignment for your domain to any receiver that honours DMARC (Gmail, Microsoft 365, Yahoo and most major providers do).

This is why exact-domain spoofing should be treated as a solved problem for any organisation willing to reach p=reject. If it is still possible against your domain, that is a configuration gap, not an unavoidable risk. You can confirm your current posture with a DMARC checker or the spoofing risk calculator.

Threat 2: Look-alike (cousin) domains

When exact-domain spoofing is blocked, attackers move to domains they do control that merely resemble yours. These are entirely separate registrations, so your DMARC policy has no authority over them.

Common techniques:

• Typosquatting: yourcompny.com, yourcompanny.com.
• Homoglyphs / IDN abuse: Unicode characters that render identically to Latin ones, e.g. a Cyrillic "а" (U+0430) in place of the Latin "a", producing a domain that looks identical in many fonts.
• TLD swaps: yourcompany.net, yourcompany.co, yourcompany.io when you only own .com.
• Combosquatting: appending plausible words, such as yourcompany-billing.com, yourcompany-secure.com, accounts-yourcompany.com.
• Subdomain deception: yourcompany.com.login-secure.net, where the real registrable domain is login-secure.net but the eye stops at yourcompany.com.

The uncomfortable truth is that DMARC cannot stop look-alike domains, because the fraudster can publish perfectly valid SPF, DKIM and DMARC records for a domain they legitimately own. Authentication proves control of the sending domain; it says nothing about whether that domain is one your users should trust. Defence here is about monitoring and takedown, not authentication. Periodically enumerate permutations with a look-alike domain checker, defensively register the highest-risk variants, and keep a relationship with a registrar or brand-protection service that can action takedowns quickly.

Threat 3: Display-name spoofing

This is the most common attack against well-defended organisations, and the most psychologically effective. The attacker leaves the actual email address as some throwaway account but sets the display name to a trusted person or brand.

From: "Jane Okafor (CEO)" <ceo.urgent.4471@gmail.com>

On a phone, many mail clients show only "Jane Okafor (CEO)" and hide the address entirely. The message originates from a real, authenticated Gmail account, so it passes SPF, DKIM and DMARC for gmail.com. Authentication is working exactly as designed; it is simply authenticating the wrong thing for the user's purposes.

DMARC does not address display-name spoofing at all. This is where BIMI earns its place: once you are at enforced DMARC, BIMI lets you publish a verified logo (backed by a VMC or CMC) that participating mailbox providers render next to genuine mail from your domain. Users learn that real messages from you carry the mark; its absence is a quiet signal. BIMI does not block the fraud, but it raises the cost of convincing impersonation and trains recognition. See BIMI for the prerequisites.

Threat 4: Business email compromise (BEC)

BEC is the umbrella term for socially engineered fraud that abuses email trust to move money or data. The FBI consistently ranks it among the costliest categories of cybercrime, not because of clever malware, but because it exploits process and authority. BEC typically uses one of the above delivery mechanisms wrapped in a believable pretext.

Recognisable patterns:

• CEO/executive fraud: a "senior leader" urgently requests a transfer, gift cards or confidential data, with pressure and secrecy ("I'm in a meeting, don't call").
• Vendor/supplier impersonation: a known supplier "updates" their bank details just before an invoice is due.
• Payroll diversion: an "employee" asks HR to change their direct-deposit account.
• Account compromise (the most dangerous variant): the attacker has actually logged into a real mailbox, so the mail is genuinely from the real account. No spoofing is involved at all, and therefore no amount of DMARC will detect it.

That last variant is the crucial limit. DMARC is blind to a compromised-but-legitimate account. If a criminal phishes a finance clerk's credentials and sends from the real mailbox, every authentication check passes because the mail genuinely is authentic. Defending against this requires identity controls (MFA, conditional access, anomalous-login detection) and process controls, not email authentication.

Threat 5: Invoice and payment fraud

Invoice fraud is the monetisation layer that sits on top of the techniques above, and it is worth treating separately because the control that stops it is largely procedural.

A typical chain:

1. Reconnaissance. The attacker learns who pays whom, often from a compromised inbox in your supply chain, or from public sources.
2. Insertion. Using a look-alike domain or thread hijacking from a compromised account, they inject a message into a real conversation.
3. The ask. "Please note our updated banking details for this invoice." The amount and reference match a genuine, expected payment.
4. The payout. Funds move to a mule account and are dispersed within hours.

Because step 2 frequently uses a domain the attacker legitimately controls (or a real compromised account), email authentication often cannot flag it. The decisive control is out-of-band verification of any change to payment details: call the supplier on a number you already hold (never one from the email), require dual authorisation above a threshold, and treat "urgent" plus "new bank details" as an automatic stop condition.

Exactly what DMARC does, and does not, stop

It is worth being blunt, because vendors routinely overstate this.

DMARC reliably stops:

• Unauthorised use of your exact domain in the visible From: (at p=reject/p=quarantine, on receivers that honour DMARC).
• The classic phishing pattern of impersonating your brand from servers you don't control, using your real domain.

DMARC does NOT stop:

• Look-alike / cousin domains: they aren't your domain, so your policy has no reach.
• Display-name spoofing: the address may be an unrelated, fully authenticated account.
• Compromised legitimate accounts: the mail genuinely is authentic.
• Inbound mail from domains that publish no DMARC, or receivers that don't enforce it.
• Non-email channels: SMS smishing, voice, collaboration-tool messages.

DMARC, in other words, is necessary but not sufficient. It removes the easiest and most scalable attack so that defenders can concentrate scarce attention on the harder, lower-volume threats.

How the three protocols actually combine

A quick refresher, because the layered plan below depends on getting these right.

SPF (RFC 7208)

SPF authorises which servers may send for the envelope domain via a DNS TXT record:

v=spf1 include:_spf.google.com include:sendgrid.net -all

Critical pitfalls:

• The 10-DNS-lookup limit. Every include, a, mx, ptr and exists mechanism counts; exceed ten resolutions and SPF returns permerror, which most receivers treat as a fail. Nested includes are the usual culprit. SPF flattening, which resolves includes into IP ranges, keeps you under the limit; our SPF checker counts your lookups, and hosted SPF maintains a flattened record automatically.
• ~all (softfail) vs -all (hardfail). ~all asks receivers to accept-but-mark; -all asks them to reject. Aim for -all once you're confident every legitimate source is listed.
• SPF breaks on forwarding. When mail is forwarded, the envelope sender domain stays yours but the connecting IP changes, so SPF fails. This is exactly why DKIM and DMARC alignment matter.

DKIM (RFC 6376)

DKIM attaches a cryptographic signature over selected headers and the body, verifiable via a public key in DNS at selector._domainkey.yourdomain.com. Key points:

• Selectors let you run multiple keys at once, which is essential for clean rotation. Publish the new selector, start signing with it, then retire the old one.
• Use 2048-bit keys where your DNS provider supports the record length; 1024-bit is increasingly considered weak.
• Canonicalisation (c14n). Use relaxed/relaxed so that benign whitespace and header reformatting in transit don't break the signature.
• Rotate keys before they go stale; a leaked or old key undermines the whole chain. Rotation isn't automatic: DMARC Engine sends monthly "rotation due" reminders for selectors older than around 180 days and supports overlapping selectors so you can publish a new key and sign with it before retiring the old one. Generate and validate keys with the DKIM checker.

DMARC (RFC 7489) and alignment

DMARC ties SPF and DKIM to the visible From: via alignment and tells receivers what to do on failure:

v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com; adkim=s; aspf=s; pct=100

• Alignment is the heart of it. SPF alignment requires the envelope domain to match the header From domain; DKIM alignment requires the signing d= domain to match it. A message passes DMARC if either aligned check passes.
• adkim/aspf set strict (s, exact match) or relaxed (r, organisational-domain match) alignment. Relaxed is the sensible default for most senders.
• p= is the policy: none (monitor only), quarantine, or reject. Only quarantine and reject actually block spoofing; p=none stops nothing.
• rua is where aggregate reports go. These XML reports are how you discover every service sending as you before you tighten policy.

A layered defence plan

No single control is sufficient. Build defence in depth across authentication, monitoring, people and process.

Layer 1: Lock down your own domains (authentication)

1. Inventory every sender. Marketing platform, CRM, helpdesk, billing, payroll, support: anything that sends as you. DMARC aggregate reports are the most reliable inventory you'll get.
2. Publish SPF with all legitimate sources, kept under ten lookups (flatten if needed), moving toward -all.
3. Sign all mail with DKIM, 2048-bit, with a selector-based rotation plan.
4. Deploy DMARC and walk it to enforcement. Start at p=none purely to gather data, fix failing-but-legitimate sources, then progress through quarantine to reject. Reaching p=reject is the goal: it is the only policy that fully closes exact-domain spoofing. The staged approach is laid out in the enforcement journey.
5. Cover dormant and parked domains too. A domain you never send from should publish v=spf1 -all and v=DMARC1; p=reject; so it can't be abused.

Layer 2: Harden transport and brand (MTA-STS and BIMI)

• MTA-STS (RFC 8461) enforces TLS for inbound mail and prevents downgrade or man-in-the-middle interception of messages destined for you. Pair it with TLS-RPT for visibility. See MTA-STS.
• BIMI publishes a verified logo on authenticated mail once you're at enforcement, helping users distinguish genuine messages from display-name impostors.

Layer 3: Watch the perimeter you don't control (monitoring)

• Continuously parse DMARC aggregate and forensic reports to spot new sending sources and active spoofing attempts. A DMARC report analyzer turns the raw XML into something legible.
• Monitor for look-alike registrations and homoglyph variants; defensively register the worst, and keep takedown channels ready.
• Watch certificate-transparency and DNS feeds for new domains echoing your brand.

Layer 4: Protect identities and inboxes (account security)

Because compromised accounts defeat authentication entirely:

• Enforce phishing-resistant MFA (FIDO2/passkeys where possible) on all mail accounts.
• Apply conditional access and alert on impossible-travel or anomalous logins.
• Disable legacy/basic auth protocols that bypass MFA.

Layer 5: Train people and tighten process (the human layer)

Authentication can't stop a believable request to a real human, so the last layer is procedural:

• Out-of-band verification for any payment-detail change or unusual transfer, using contact details you already hold.
• Dual authorisation for payments above a threshold.
• Normalise scepticism of urgency and secrecy, the two hallmarks of BEC.
• Run realistic phishing simulations and make reporting frictionless.
• Flag external mail with a banner so display-name spoofing of internal staff is obvious.

How DMARC Engine fits

DMARC Engine handles the parts of this plan that are tedious and error-prone to run by hand: maintaining a flattened, in-limit SPF record; managing DKIM keys and rotation; ingesting and visualising DMARC aggregate reports so you can see every sender; and guiding you safely from p=none to p=reject without dropping legitimate mail. Where it makes sense, it layers in MTA-STS and BIMI to harden transport and brand. It does the authentication heavy lifting so your team can focus on the layers software can't own: identity and process.

Next steps

1. Measure where you stand. Run your domain through the DMARC checker and spoofing risk calculator.
2. Find your shadow senders by collecting DMARC aggregate reports before changing anything.
3. Walk to p=reject to eliminate exact-domain spoofing, the one threat authentication fully solves.
4. Layer the rest: BIMI for brand recognition, look-alike monitoring, MFA on every mailbox, and out-of-band verification for money movement.

Email fraud thrives on a single false identity. Authentication removes the easiest impersonation, brand verification raises the cost of the rest, and disciplined process closes the door on the requests no protocol can ever inspect. Implement all three layers and you turn email from your weakest channel into a well-guarded one.