Lookalike domains: the attack DMARC cannot stop

Why authentication cannot see it

SPF, DKIM, and DMARC answer one question: is this message really from the domain it claims to be from? A message from acme-billing.com claims to be from acme-billing.com. The attacker owns that domain, publishes its SPF record, signs with its DKIM key, and sets a DMARC policy. The receiver checks, everything lines up, and the message is delivered with a green padlock. Your own p=reject was never consulted, because nobody claimed to be you.

That is not a flaw in DMARC. It is the edge of what DMARC is for. Enforcement closes the exact-domain door; lookalikes are the window next to it.

How attackers pick a name

Lookalikes are not random. A handful of rules produce almost all of them, roughly in the order attackers reach for them:

• Homoglyphs. Characters that read as another at a glance: rn for m, l for 1 or I, 0 for o, vv for w. Internationalized domains extend this with accented and Cyrillic letters that render nearly identically.
• Typos. A dropped letter, a doubled one, two swapped, or a neighbor on the keyboard. These also catch real customers who mistype your address, which is why attackers like them.
• Hyphens. acmecorp.com becomes acme-corp.com, or the reverse.
• Keyword affixes. acme-billing.com, acme-hr.com, secure-acme.com, acme-invoice.com. These are the workhorses of invoice fraud and payroll redirection, because the extra word makes the address look more official, not less.
• A different ending. acme.co, acme.net, acme.io, acme.cm (the Cameroon ending that absorbs mistyped .com).

For a typical company name those rules produce around two thousand plausible candidates. Only a small fraction are ever registered, and the registered ones are what matter.

Registered is not the same as dangerous

Most registered lookalikes are harmless: an unrelated business with a similar name, a domain investor holding acme.co, a forgotten side project. The signals that separate a threat from noise are what the domain is set up to do:

• It resolves. Name servers answer for it. This is the floor: the domain exists.
• It can receive mail. An MX record means replies to a phishing message will land somewhere. Invoice fraud needs this.
• It is configured to send. An SPF or DMARC record on a lookalike is a sender getting ready to pass authentication checks. Established businesses have these too, so on its own this proves intent only when the domain is new.
• It was registered recently. Registration data (RDAP) gives the creation date. A mail-capable lookalike registered in the last few months is the profile of a campaign being set up; one registered in 2011 is usually a neighbor.
• A certificate was issued. Certificate transparency logs record every public TLS certificate. A fresh certificate on a lookalike usually means a credential-harvesting page went live.
• It has already sent mail as you. The strongest signal there is. Your DMARC aggregate reports list the envelope and header domains receivers saw on mail attributed to you, and a lookalike appearing there means a real mailbox provider saw the impersonation happen.

How to find yours

Two sources, and you want both. The first is the DMARC reports you already receive: scan the sender domains they name for anything that is a close variation of yours. That costs nothing and is receiver-confirmed. The second is generating the candidate list yourself and checking which ones resolve, then reading MX, SPF, DMARC, the registration date, and the certificate logs for each hit. Doing that by hand for two thousand names once is tedious; doing it every week is a job for software.

trustyourinbox does both for every protected domain: receiver-reported lookalikes surface as they appear in your reports, and a weekly permutation scan checks the candidate set, keeps the registered hits, and grades each one on the signals above. The result is a Lookalikes tab per domain that says what exists, what it is set up to do, and which rows deserve attention today.

What to do about one

• If it is yours or a partner's, mark it so and move on. A monitoring tool that cannot be told "we know" becomes noise within a month.
• If it is unregistered and cheap, consider registering the handful of highest-risk variants yourself (the billing and HR affixes, the .co and .cm swaps) and pointing them at a v=spf1 -all record and p=reject. A domain you own cannot be used against you.
• If it is registered and mail-capable, warn the people it would target. Finance, HR, and anyone who approves payments should know the exact spelling to distrust. Add it to your mail gateway's block or quarantine list.
• If it has sent mail as you, report it. Every registrar publishes an abuse contact through RDAP, and a report that includes the domain, the dates, the registrar, and the evidence that it impersonated you is usually acted on within days. Registrars suspend domains for phishing far more readily than people expect.

None of this replaces DMARC enforcement. It is what comes after it: once your own domain cannot be forged, the domains that look like it are the remaining surface, and watching them is how you keep the ground you won.