When someone sends email pretending to be you

Two different things get called impersonation, they have completely different defences, and confusing them is why companies with perfect DMARC still get calls about invoices they never sent.

5 min read

The same display name arriving from a domain you own and one you do not
One of these your DMARC policy governs. The other it has never heard of.

Exact-domain spoofing is mail claiming to be from you@yourcompany.com that you did not send. This one you can stop.

Lookalike domains are mail from you@yourc0mpany.com or yourcompany-support.com, registered by someone else. DMARC on your domain has no opinion about a domain you do not own, and never will.

What DMARC actually covers

Enforcement at p=reject means a receiving server refuses mail that claims your domain in From and does not align with your SPF or DKIM. That closes exact-domain spoofing at every provider that honours the policy, which is effectively all the large ones.

So the first defence is simply finishing the job most people leave half done: get to reject rather than parking at none. The route is in what DMARC reports are actually telling you, and for an agents-only subdomain it is quick because there is one legitimate sender.

Two details worth getting right while you are there. sp= governs subdomains, so a parent at p=none with sp=reject protects every subdomain you have not thought about yet, including ones nobody has created. And every domain you own but never send from should carry a null SPF and a reject policy, because an unused domain with no policy is a free identity for someone else.

_dmarc.parked-domain.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@yourcompany.com"
parked-domain.com         TXT  "v=spf1 -all"

That pair takes a minute per domain and closes an entire category.

What DMARC does nothing about

A lookalike domain is a different domain, correctly authenticated by whoever registered it, sending mail that passes every check it should. The techniques are old and effective: a character swap, an extra hyphen, a different suffix, or the display name carrying your company while the address is nonsense nobody reads on a phone.

Your defences are detection and response rather than prevention.

Monitor for registrations. Certificate transparency logs and domain monitoring services will tell you when something close to your name appears. Cheap, and the alert usually arrives before the campaign does.

Watch what your own agents see. An agent inbox is an early-warning system nobody uses: mail arriving that references your brand from domains you do not own is a signal, and it lands where you can see it. The message.filtered events on whitelisted identities are worth reading for the same reason, per deciding what reaches your agent.

Have a takedown path ready. Registrar abuse contact, hosting provider, and the relevant reporting form. Prepared in advance it takes an hour; improvised during an incident it takes days.

Detection, response, and prevention covering different halves of the problem
Prevention covers your domains. Detection and response cover everyone else's.

The agent-specific angle

An email agent changes this in two directions, and both are worth knowing.

It is a target. An agent that reads mail and acts is a more attractive victim than a person, because it can be instructed. A lookalike domain plus a plausible instruction is exactly the shape covered in prompt injection by email, and the reason the defence is architectural: the From header is a claim, and no amount of it should authorise an action.

It is also a sensor. Agents read more mail than people do and never get bored, so an agent that flags "this claims to be from a domain we correspond with, but is not" catches things a human skims past. That check is cheap: compare the sender domain against the contact record and the thread history, and escalate mismatches rather than answering them.

The rule that follows for finance-adjacent agents: any request to change bank details, from any domain, always escalates and is verified out of band, per chasing quotes and vendors.

The day it happens

  1. Collect evidence. Full headers from a received sample, the sending domain, the IPs. Headers, not screenshots.
  2. Confirm it is not you. Check your own sending, since an internal misconfiguration can look like spoofing from the outside.
  3. Tell the people being targeted. Customers, staff, or both, plainly, with what the real address looks like. This is the step that limits damage, and it belongs to a person rather than an agent.
  4. Report to the registrar and host, with the evidence from step one.
  5. Tighten what you can. If exact-domain spoofing got through, your policy was not at reject. Fix that permanently rather than for the incident.
  6. Write it down. Same postmortem discipline as when the agent sends something it should not have.

What not to bother with

Registering every possible lookalike is a budget with no end; buy the handful that are one keystroke away and stop. Adding warning banners to inbound mail helps internally and does nothing for customers. And there is no point pursuing every spoofing attempt visible in your DMARC reports, since low-volume background noise arrives at every domain that exists and reacting to it consumes attention you need for the sustained ones.

Questions

Does DMARC stop people impersonating my brand?
It stops mail that claims your exact domain, once you are at p=reject. It has no effect on lookalike domains, which are different domains someone else owns and authenticates correctly.
What should I do with domains I own but never send from?
Publish v=spf1 -all and a DMARC record at p=reject. An unused domain with no policy is a free sending identity for anyone.
How do I find lookalike domains?
Certificate transparency monitoring and domain watch services flag registrations close to your name, usually before a campaign starts. Your own agent inboxes are a second sensor.
Can an agent detect impersonation?
It can flag it: compare the sender's domain against the contact record and thread history, and escalate mismatches. It must never treat a From header as authorisation, which is an architectural rule rather than a prompt one.
What is the first step when it happens?
Collect full headers from a real sample, confirm the mail is not actually yours, and tell the people being targeted. Registrar and host reports come after the evidence exists.
Should I buy every similar domain?
Buy the handful one keystroke away and stop. The full space is unbounded and the money is better spent on detection and a prepared takedown path.

Give your agent an address it can answer from.

Create an inbox