Preventing email spoofing

Priority 3: monitoring lookalike domains

DMARC protects the exact domain, but not the variants an attacker can register: typos (example.com → exampel.com), visual substitutions (0/O, 1/l), or deceptive additions (example-security.com). These domains are the prime target of typosquatting, a technique complementary to pure spoofing since it bypasses DMARC entirely by using a domain actually registered and controlled by the attacker.

Defense combines several approaches: preemptively registering the most obvious variants of the domain name (common typos, neighboring TLD variations like .com vs .net, character substitutions attackers commonly rely on); monitoring new lookalike-domain registrations via dedicated watch services that raise an alert as soon as a close variant is registered; and training the teams, especially those handling wire transfers and payments, to check the exact address rather than just the display name.

Priority 4: training the teams exposed to wire transfers

Even with DMARC at p=reject and lookalike-domain monitoring in place, the human factor remains an entry point no technical control fully closes. CEO fraud (BEC) often exploits variants that escape technical detection: a legitimate email account compromised elsewhere, or a lookalike domain registered the day before the attack. The topic is developed in CEO fraud (BEC): how to defend against it, which details the organizational procedures to put in place — systematic verification via a second channel for any unusual wire transfer, notably, along with the typical warning signs to teach accounting and finance teams.

Priority 5: documenting and communicating clearly

An often-overlooked measure: a clear statement, on the company website and in official communications, of how the organization actually contacts customers or partners (which domains, which practices). An organization that publicly states "we never request a wire transfer via plain email" reduces social engineering's attack surface, even when the technical gap itself is already closed elsewhere. It gives customers and partners a clear, memorable rule to check any suspicious request against, rather than relying on them to independently notice something technically off about the message. This communication also has direct defensive value: a customer receiving a request that contradicts this stated policy knows immediately to be suspicious, with no technical expertise needed to figure it out.

What DMARC doesn't replace

The division of roles needs to be clear. DMARC is the technical foundation — without it, everything else is built on sand, since direct spoofing of the exact domain stays trivial. But DMARC alone isn't enough for complete protection: typosquatting, display-name spoofing, and compromised accounts require the complementary measures listed above. Treating these five priorities as a coherent whole, rather than stopping at the first, is what distinguishes an organization that's genuinely protected from one that only thinks it is — often until an incident proves otherwise, at which point the gap becomes very expensive to discover.

A typical scenario, to see the defense stack in action

A twenty-person SMB has just discovered its name is being spoofed in a phishing campaign targeting its own customers. Here's how each of the five priorities plays into that real-world scenario.

With no defense in place, the attack works at full strength: the email claims to come from billing@company.com, arrives normally in the inbox (nothing technically distinguishes it from a real email), and customers who click the malicious link or pay a fake invoice have no way to be suspicious. The company only discovers the incident from customer complaints arriving after the fact — far too late to act, with the damage to trust already done.

With DMARC at p=reject (priority 1), the same email, using the company's exact domain, is refused before reaching the customer's inbox. The attack fails silently, with the company not even needing to react under pressure.

If the attacker falls back to a non-existent subdomain (billing.company.com, never created), the np tag (priority 2) blocks that attempt too — an angle many companies leave open thinking root domain protection is enough.

If the attacker registers a lookalike domain (company-billing.com), DMARC can no longer help — it's a different domain, with its own configuration. That's where lookalike-domain monitoring (priority 3) takes over, catching the suspicious registration before, or shortly after, its active use.

If, despite everything, an email from that lookalike domain reaches an employee with an urgent transfer request, training (priority 4) and second-channel verification procedures form the last safety net — the point where a well-rehearsed habit of double-checking matters more than any piece of technology.

Each layer catches what the previous one lets through — that's exactly why the five priorities work together, and why stopping at the first (essential as it is) still leaves exploitable attack angles for a determined attacker willing to try the next one.

The cost of inaction, in perspective

One last argument to convince a hesitant leadership team: the cost of implementing these five priorities is marginal compared to the cost of a successful incident. DMARC is free to publish; lookalike-domain monitoring costs a few dozen to a few hundred euros a month depending on the service chosen; training a ten-person team is measured in hours, not weeks. On the other side, a successful CEO fraud commonly runs into tens of thousands of euros, not counting the reputational cost of a phishing campaign successfully run in the company's name, which can durably erode customer trust and takes far longer to rebuild than the technical fix takes to deploy, sometimes years against a single afternoon of DNS work. The asymmetry between prevention cost and incident cost is the most convincing argument for prioritizing this project, even in a resource-constrained organization where every euro of budget faces real competition from other priorities.

It's also worth noting that the five priorities don't demand equal effort at the same time. Priority 1 is a project with a beginning and an end — a few weeks to a few months of inventory and alignment, then a hardened policy that mostly maintains itself. Priorities 2 and 5 are one-off configurations and decisions, done in an afternoon. Only priorities 3 and 4 are genuinely recurring commitments: monitoring needs someone to read the alerts, and training needs refreshing as teams change. Framed that way, the roadmap looks far less daunting than a five-item list suggests — most of the effort is front-loaded, and the ongoing burden is light.

The fastest test to know where a domain stands

Before any of this gets prioritized, a simple, immediate test: does the domain have a DMARC record, and if so, at what policy? That's the question determining whether the starting point is square one (directly spoofable, absolute priority) or the next priorities (subdomains, lookalike domains, training) — no point building a sophisticated defense stack on a foundation that's still missing.

The free DMARC analyzer returns that answer in seconds, with detail on the current policy, the alignment status, and the subdomain coverage. And to track progress against a whole sector over time, the DMARC Observatory supplies a useful comparison point for justifying the investment to a leadership team still doubting the topic's priority — nothing convinces better than a figure showing comparable competitors are already protected.

In summary

Preventing email spoofing isn't a single action but a stack of complementary defenses: DMARC enforced for the exact domain, coverage of existing and non-existent subdomains, lookalike-domain monitoring, training for exposed teams, and clear communication about the organization's practices. The first step, the most cost-effective and least expensive, is always the same — publishing a DMARC record and hardening it methodically, before investing in the layers above, since none of them compensate for a missing foundation and all of them assume it's already in place.