Your domain policy cannot prevent someone from putting your brand name beside an unrelated email address. Brand impersonation can use your exact domain, a visually similar domain, a misleading display name or a compromised legitimate account. These are different identity conditions, and each requires evidence beyond the impression created by an inbox preview.
Read the address rather than the presentation
Preserve the original message and extract the complete From address, display name, Reply-To address and relevant URLs. A screenshot may hide the actual mailbox address or shorten a domain. Do not rely on visual similarity alone to identify the domain used in authentication. Keep the original spelling and representation before adding any normalized comparison for analysis.
DMARC relates authentication to the author domain in the message. A separate lookalike domain can authenticate itself successfully; that does not place it under your organization's domain policy. RFC 9989. Use authentication results from the trusted receiving system, not an arbitrary header supplied with the message. RFC 8601.
Classify without overstating intent
For exact-domain forgery, determine whether the claimed author domain is yours and what trusted authentication evidence shows. For a lookalike, record the precise difference and why the message's presentation or request suggests impersonation. For display-name abuse, show the misleading name separately from the unrelated actual address. A domain resemblance by itself does not establish malicious use or legal wrongdoing.
A passing message from the real domain deserves a different investigation: it could reflect an authorized service, account compromise or a legitimate request misunderstood by the recipient. Do not force that case into a spoofing category merely because the content is suspicious. Preserve competing explanations until account and business evidence can distinguish them.
Apply the hypothetical classification example
The written example stipulates three requests all displayed as Brand Finance. The first uses billing at brand.test with an invented trusted fail result and is labeled an exact-domain forgery candidate. The second uses brand-pay.test with a pass and is a lookalike candidate. The third uses unrelated.test with a pass and is a display-name impersonation candidate. The invented known business contact denies every request.
The proposed case ledger retains the classifications and assigns a hold, evidence-preservation and review action to each. It does not verify public domain registrations, calculate full DMARC policy or establish the intent of any real sender. The domains are reserved laboratory names, and the business verification field is a scenario assumption. This is a proposed classification exercise, not an executed detector or accuracy measurement. No known contact was actually approached.
Respond through the relevant channel
Protect the business action first. Confirm payment or account changes through previously established contacts, following the FBI's guidance on business email compromise. FBI advice. Do not reply to the suspect address to obtain the confirmation you then call independent.
Prepare any provider abuse report with the original identifiers, observed behavior and a minimally necessary redacted sharing copy. Request review under the provider's applicable process without promising takedown. Keep your own domain-authentication repair work separate from reports about someone else's domain, because changing your DNS cannot directly disable that domain.
Close with the identity classification, evidence confidence, business exposure and response status. Continue monitoring relevant cases without claiming that every similar registration is malicious. A useful brand-protection programme combines domain authentication with message analysis, reporting, account controls and business verification, each measured against the abuse it can actually address.
Keep findings within the evidence
The examples are defensive decision aids, not observed allegations against real people or current providers. Retain authentication evidence, business verification and attribution separately. Current protocol sources describe domain validation and trusted result boundaries; they do not supply the missing account evidence or authorize publication of an accusation.