Typosquatting and email fraud: why DMARC cannot stop it

16 March 2026 · 12 min read

Typosquatting is the practice of registering domain names that are close misspellings of a real one, then using them to deceive people. In a web context it is the classic fat-finger trap: you mean to type gmail.com, you actually type gmial.com, and somebody is waiting there. In an email context it is more dangerous, because the attacker does not need you to make a typo at all. They register the misspelt domain themselves, set up perfectly valid email authentication on it, and send mail that passes every check you have. The recipient skims the sender address, reads it as your domain because the brain corrects small errors automatically, and acts on the message.

This article is specifically about the ASCII typosquatting flavour of look-alike email fraud: domains built from ordinary keyboard characters through misspellings, transpositions, omissions, doubled letters, hyphen insertions and alternative top-level domains. It is the cousin of the Unicode trick covered in homograph and IDN spoofing domains, but the mechanics, the detection signals and the defensive economics are different enough to deserve their own treatment. The crucial shared point, the one that surprises people who have just reached p=reject, is that your DMARC record does nothing to stop any of it. Here is exactly why, and what actually works instead.

What typosquatting looks like for a domain

Typosquatting is not one technique, it is a family of small mutations applied to a target domain. If your domain is northwind.example, the realistic permutations an attacker chooses from include:

Character omission: dropping a letter, so northwind.example becomes northwid.example or orthwind.example.
Character transposition: swapping adjacent letters, so it becomes northiwnd.example or nrothwind.example.
Character replacement: a neighbouring key on a QWERTY keyboard, so northwind becomes northwund or norrhwind.
Doubled or trebled letters: northwwind.example, which the eye glides straight over.
Digit-for-letter swaps that stay in pure ASCII: n0rthwind.example with a zero, or northwlnd.example with an l standing in for an i.
The rn for m and vv for w trick: modernsupport.example becomes rnodernsupport.example, which in many sans-serif fonts is almost perfect.
Hyphen insertion or removal: north-wind.example, or stripping a hyphen the real brand uses.
Alternative top-level domains (TLD swaps): the exact same label under a different suffix, so northwind.example is shadowed by northwind.co, northwind.io, northwind.net, northwind.support or any of the hundreds of newer TLDs.
Combosquatting: appending a plausible word, so northwind-billing.example, northwind-secure.example or northwindpayments.example. Strictly this is not a typo at all, but it travels with the same family because it exploits the same trust in your brand string.

None of these requires Unicode, IDN encoding or xn-- Punycode. They are all things you could type on a plain keyboard, which is precisely what makes them cheap, fast to register in bulk, and easy to spin up at scale. The Unicode homograph case, where a Cyrillic а (U+0430) stands in for a Latin a and the two are byte-different but pixel-identical, is the subject of the homograph article and the lookalike and cousin domains glossary entry. This article stays in ASCII.

Why your DMARC cannot stop it

This is the part worth being completely clear about, because a lot of money gets spent on the false belief that reaching enforcement closes this hole.

DMARC, SPF and DKIM protect your domain from being forged. They prove that a message claiming to be from northwind.example really did come from infrastructure authorised by the owner of northwind.example, and was not tampered with in transit. They are domain-integrity mechanisms. A typosquatted domain is not your domain. It is a different domain that the attacker owns outright. Walk through each check and you can see there is no point at which any of them looks at your real domain:

SPF verifies that the sending IP is authorised in the SMTP envelope domain, the Return-Path / MAIL FROM. The attacker sends as billing@northwwind.example, publishes their own v=spf1 record on northwwind.example listing their own servers, and SPF passes. For their domain.
DKIM verifies a signature against a public key in the signing domain's DNS. The attacker generates a key pair, publishes the public half under northwwind.example, signs with the private half, and DKIM passes. For their domain.
DMARC checks that the visible Header-From domain is aligned with an authenticated SPF or DKIM domain, then applies the policy published by that Header-From domain. The Header-From is billing@northwwind.example. It aligns perfectly with the attacker's own SPF and DKIM. DMARC then reads the policy at _dmarc.northwwind.example, which the attacker controls and typically sets to p=reject to look respectable. DMARC passes.

Three green ticks. Not one of them ever consults _dmarc.northwind.example, your record, because the mail never claims to be from your domain. There is no field anywhere in the SPF, DKIM or DMARC specifications that compares two domain strings and notices that northwwind.example looks like northwind.example. That comparison is a human judgement about visual and semantic similarity, and the attack is engineered specifically to slip past it.

So the honest position is this: there is no DNS record you can publish on your own domain that prevents someone registering a typo of it and sending authenticated mail from it. Your DMARC policy governs your namespace. The attacker is operating in a neighbouring namespace you do not control. This is a categorically different failure mode from the ones that surface when DMARC fails but SPF and DKIM individually pass, or when your DMARC reports show unknown sources using your real domain. In those cases the abused domain is yours, so enforcement does real work. With typosquatting, enforcement on your domain is simply never in the loop.

A worked example

Suppose northwind.example is fully authenticated at p=reject, and finance sends invoices from accounts@northwind.example.

An attacker cannot forge northwind.example directly, because your enforcement blocks it at the receiving server. So they reach for a typo instead. They register:

northwwind.example   (a doubled "w", easy to miss)

On that domain they publish their own authentication:

northwwind.example.            IN  TXT  "v=spf1 include:_spf.attacker-host.example -all"
sel._domainkey.northwwind.example.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
_dmarc.northwwind.example.     IN  TXT  "v=DMARC1; p=reject; rua=mailto:rua@northwwind.example"

They send an invoice from accounts@northwwind.example with new bank details and a polite note that the old account is being closed. SPF passes (their IP, their record). DKIM passes (their key, their signature). DMARC passes (Header-From aligned with their own authenticated domain, policy is theirs). The message lands in the inbox with every authentication header green. The body links to a payment portal on the same look-alike domain, served over HTTPS with a valid certificate, because certificate authorities will happily issue a cert for northwwind.example to whoever controls it.

Nothing in this chain touches northwind.example. Your p=reject, your aligned SPF, your rotated DKIM keys: all correct, all irrelevant to this message. This is the anatomy of a business email compromise and phishing lure that authentication on your real domain cannot reach.

It helps to keep the family tree straight, because the defences differ slightly per branch.

ASCII typosquatting (this article): pure-keyboard misspellings, transpositions, omissions, doubled letters, TLD swaps. Cheap, registrable in bulk, and the most common in commodity BEC.
Homograph / IDN spoofing: Unicode confusables encoded as Punycode, covered in homograph and IDN spoofing. More convincing to a careful reader, slightly harder and more expensive to register, and partly mitigated by registry script rules.
Combosquatting: your exact brand string plus a plausible extra word (-secure, -billing, support-). No misspelling at all, so spelling-distance detectors miss it, but it leans on the same brand trust.
Display-name spoofing: not a domain trick at all. The attacker sets the display name to "Northwind Billing" while the actual address is some unrelated domain. Covered in display-name spoofing. This one your recipients can catch by checking the real address, which is exactly why typosquatting is favoured when the attacker wants the real address to survive scrutiny.

The reason all of these coexist is that they are downstream of the same gap: email authentication proves which domain sent a message, never whether that domain is the one the human meant to trust.

Why enforcing your real domain still matters

Given everything above, it is fair to ask why bother getting to p=reject at all if it does not stop typosquatting. It matters because it changes the attacker's economics.

If your real domain sits at p=none, the attacker has a free, zero-effort option: forge your exact domain. No registration, no DNS setup, no cost. Most receivers will deliver it because you have published no enforcement. Why would anyone bother registering and authenticating a typo when they can just spoof the real thing for nothing?

Only when your real domain reaches p=reject with aligned SPF and DKIM does direct forgery stop working. That is what pushes criminals onto the harder, costlier, more traceable path of registering and authenticating a look-alike. Enforcement does not close the typosquatting hole, but it forces attackers into the one place where they leave a registration trail you can hunt. Confirm where you stand with the DMARC checker, and verify the underlying mechanisms with the SPF checker and DKIM checker. The requirements overview walks through what enforcement involves end to end.

There is a second, quieter benefit. Once your own domain stops generating authentication failures in your aggregate reports, genuine anomalies stand out. A clean baseline is what makes reconnaissance and adjacent abuse visible at all.

Monitoring options that actually help

Because the lever is not DNS policy on your domain, the entire defence is detection, monitoring and takedown. There are four practical layers, roughly in order of effort to value.

1. Enumerate and watch the variants

You cannot defend against look-alikes you have never listed. The first job is to generate the realistic typosquatting permutations of your brand domains and check which already exist in DNS, hold an MX record, or have a TLS certificate. The inputs to enumerate:

One-character omissions, transpositions and adjacent-key replacements for every letter in the label.
Doubled-letter variants of each repeated-prone letter.
Pure-ASCII digit-for-letter swaps (0/o, 1/l/i, 5/s).
The rn/m and vv/w glyph pairs.
Hyphen insertion and removal.
The same label under every TLD you can plausibly be confused with, especially the cheap newer ones.
Combosquatting words tied to your high-value workflows: billing, payments, invoice, secure, account, support.

A look-alike domain checker automates the permutation and the registration lookup, so you are working from a real list of what exists rather than guessing. The signal you care about most is a variant that has just acquired an MX record or a certificate, because that is the moment a parked typo becomes a weaponised one. A domain registered years ago and parked is low risk; the same domain sprouting mail records this week is an active threat.

2. Defensively register the small high-risk set

For the handful of permutations that are both highly convincing and cheap, defensive registration is rational. You will never register them all, the combinatorics defeat you and the budget is a money pit, so prioritise hard:

Variants on the same TLD as your primary domain.
The most visually forgiving typos: doubled letters, single omissions, the rn/m pair.
Names that map to your highest-value workflows (billing, password reset, invoice and payment).

Register the winners, point them at nothing (no MX, no web, an empty page at most), and you have denied them to attackers for the price of a domain each. This does not stop a determined adversary finding the next-closest typo, which is exactly why registration supports monitoring rather than replacing it.

3. Read your DMARC reports for the adjacent signal

Your aggregate reports will never contain the typosquatted domain itself, because that mail is never sent as your domain. What they can surface is the run-up to it: a spike in attempts to forge your exact domain from unfamiliar infrastructure, which often immediately precedes a pivot to look-alikes once the attacker discovers your p=reject is real. Feeding your RUA data into the DMARC report analyzer turns the raw XML into source-by-source detail, so an unusual sending pattern becomes legible instead of buried in markup. Continuous monitoring with change alerts means a new failure source, or a sudden change in your own authentication posture, is something you hear about within hours rather than at the next quarterly review.

4. Give recipients a trust signal a typo cannot copy

If genuine mail from you carries a reliable visual cue, a look-alike that lacks it becomes easier to question. BIMI displays your verified logo beside authenticated, DMARC-passing mail from your real domain. A typosquatted domain cannot show your logo, because the logo is bound to your domain's DMARC and, in the stricter tiers, to a verified mark certificate. This is not a complete defence: logo display support varies by mailbox provider, and absence of a logo is a weaker signal than its presence. But it raises the bar and gives a trained finance or support team something concrete to look for. The BIMI product page and the BIMI checker cover setup and verification.

Process beats technology here

Because no DNS lever closes this, the most cost-effective control is often human process, not more tooling. Three habits do most of the work:

Out-of-band verification for money and credentials. Any request to change bank details, reset access or pay an unexpected invoice gets confirmed through a separate channel, a known phone number, never a reply to the email. A typosquatted invoice survives every authentication check but does not survive a phone call to a number you already had.
Tell people the attack exists. Most staff have never heard that a sender address can read as your domain, pass every security check, and still be fraudulent. Naming typosquatting specifically, with a doubled-letter example, changes how carefully they read sender addresses.
A standing abuse-takedown routine. When a malicious variant is found, you want a practised path: registrar abuse complaint, hosting provider notice, and where the brand is registered, a UDRP or local equivalent. Speed matters more than perfection, because the window between weaponisation and the first victim is short.

The practical takeaway

Typosquatting is the clearest everyday proof that email authentication and impersonation defence are two different problems. DMARC, SPF and DKIM prove a message genuinely came from a given domain and was not altered. They say nothing about whether that domain is the one a human meant to trust. A typosquatted domain is authentically itself, and itself is a forgery of you that lives in the reader's glance, not in DNS policy. Your p=reject is necessary and worth having, because it forces attackers off free exact-domain forgery and onto registered look-alikes, but it is not sufficient, and anyone who tells you enforcement alone stops this is wrong.

So the strategy is layered and honest: get your real domain to enforcement so direct forgery is off the table; enumerate the realistic ASCII typos and watch them for new MX records and certificates; defensively register the few that are cheap and dangerous; read your reports for the reconnaissance signal; give recipients a visual cue a typo cannot copy; and back it all with out-of-band verification for anything involving money or access.

Start by confirming where your real domain stands today with the DMARC checker, then build your watch-list of confusable variants with the look-alike domain checker. If you would rather not run the enforcement, monitoring and look-alike hunting yourself, our done-for-you service takes your real domain to p=reject without breaking legitimate mail and keeps watch on the neighbourhood, so the typo someone registers next week is something you are alerted to, not something your customers discover the hard way.

Typosquatting and email fraud