Identify what the message is claiming
A message can imitate a business in several different ways. It may put the business's exact domain in the visible From address, use a familiar person's display name with an unrelated address, or send from a different domain chosen to resemble the business. These are not interchangeable mechanisms. They require different evidence and expose different control boundaries. Calling all three cases a DMARC failure encourages the wrong repair and can hide an incident that needs business verification rather than a DNS edit.
RFC 9989 scopes DMARC to the RFC5322.From domain and aligned authentication. It explicitly excludes display-name attacks, content analysis and authentication of entities other than domains. A receiver can still apply additional protections, but those protections should not be attributed to DMARC itself. This article offers a classification method for defensive triage, with no real message inspection or allegation about a named sender.
Exact-domain use needs a precise comparison
Start with the actual domain in the parsed From address, not the display text shown by the mail application. Compare it with the business domain relevant to the request. Preserve the exact spelling and the evidence source in a restricted investigation record. If the domains are identical, the next question is whether trusted receiver evidence shows aligned authentication, failure, absence of policy or an indeterminate result. Exact-domain appearance alone does not tell you which occurred.
An unauthorized sender using the exact domain may fail alignment, but a compromised authorized account or service can produce aligned mail. The same visible domain can therefore occur in very different incidents. A DMARC pass does not prove the message was approved by a person, and a failure does not by itself prove malicious intent. Forwarding, configuration mistakes and incomplete evidence can complicate the interpretation. State the narrow observed fact before assigning a cause.
Display names are a separate identity surface
RFC 5322, section 3.4, distinguishes a mailbox's optional display name from its address. A display name can identify a person or role to a reader without being the domain evaluated by DMARC. For example, a fictional message may display “Accounts Team” while its address belongs to an unrelated example domain. The familiar label is not proof of organizational ownership.
A small-screen or collapsed view may not expose every identity field at first glance. The defensive action is to inspect the full address using the receiving application's trusted interface and then evaluate the business request independently. Do not invent a universal UI rule or promise that every client highlights a mismatch. The standard's distinction between label and address is stable; presentation and protective warnings depend on the client and receiver.
Lookalike domains can authenticate successfully
A different domain may be visually similar to a trusted domain because of spelling, punctuation or character choices. If its operator legitimately controls its sending setup, mail from that domain can pass SPF, DKIM and DMARC for that domain. Authentication has not necessarily malfunctioned. The recipient's recognition of the intended organization has failed or been manipulated at a different layer.
Compare the actual domain with a trusted business record obtained outside the questionable message. Do not visit a supplied website or reply to the questionable address merely to establish ownership. A familiar brand word embedded in a longer name is not enough. Preserve internationalized-name interpretation carefully and seek qualified analysis if the displayed and underlying forms differ; this draft does not provide a complete Unicode or public-suffix classification algorithm.
Use trusted authentication evidence
An Authentication-Results field is useful only within the receiver's trust boundary. RFC 8601 explains why consumers must distinguish trusted authentication assertions from arbitrary fields carried in a message. Copying a line that says pass out of a forwarded message or screenshot does not establish that the relevant receiver produced it. Record which receiver evaluated the message and how the investigator obtained the result.
Keep the visible From domain, envelope sender domain, DKIM signing domain and Reply-To identity distinct. Their differences may have legitimate explanations and should not be automatically collapsed into a fraud finding. For DMARC, identify the aligned authentication path rather than treating every SPF or DKIM pass as sufficient. For the business request, examine the requested action and the authority of the person supposedly making it.
An identity-comparison worksheet
Prepare a row containing the trusted business domain, visible display label, parsed From address, Reply-To address if present, authenticated domains, receiver result, evidence provenance and proposed classification. Add columns for what remains unknown and which independent channel can verify the request. Minimize personal identifiers in any shared version while preserving whether two domains were identical or different. Changing all values to one placeholder destroys the relationship the worksheet is meant to show.
Use three provisional categories: exact-domain use, display-name imitation and different-domain resemblance. Permit combinations and an unresolved category. A message can use both a misleading display name and a lookalike domain. The worksheet should also allow authorized-account compromise as a hypothesis when aligned mail appears to come from the real organization. Classification is a way to route investigation, not a final determination of intent or responsibility.
Fictional comparison with three messages
Imagine a fictional finance team receives three unusual requests associated with Northbridge Example. The first has Northbridge's exact domain but trusted receiver evidence indicates no aligned pass. The second uses the finance director's display name with an unrelated address that authenticates for its own domain. The third uses a similar-looking but different domain and also authenticates for that domain. These are invented observations, not messages collected during this work.
The first case leads to an authentication and sending-path investigation. The second leads to display-name and business-authority verification. The third leads to domain comparison and impersonation handling. None warrants payment solely because a familiar name appears, and none should be “fixed” by adding the unrelated sender to Northbridge's SPF record. If a fourth message passes alignment using Northbridge's actual domain, account or service compromise remains possible and requires its own evidence.
Verify the request beyond the message
The IC3 cloud-email BEC advisory, published in 2020, recommends verification through known contact methods for suspicious business requests. Its age is explicit: it supports the general control, not a claim about a current incident or a particular receiver's present interface. Use a number or workflow already recorded independently, and verify the specific change requested rather than merely asking whether someone sent an email.
The required redacted abuse scenario with identity evidence, control boundary and independent business verification remains unfulfilled. This manuscript's fictional comparison does not satisfy it. No account was queried, no suspicious domain visited, and no party contacted. Before release, retain authorized real evidence, have a qualified reviewer validate the classification, confirm source applicability and production routes, complete accessibility review, and obtain owner approval. The outcome should be a defensible explanation of which identity was asserted and what the controls actually established.