Separate internationalization from impersonation
Internationalized domain names let people use domain labels beyond the traditional ASCII letters, digits and hyphen. That capability is legitimate and important. The security concern is not the presence of a particular script; it is whether a displayed identifier can be confused with another identity in a consequential context. A homograph or confusable-domain investigation must therefore preserve the actual name, its validated DNS representation and the receiver's presentation without declaring every non-ASCII name malicious.
RFC 5890 defines terminology for Internationalized Domain Names in Applications, including A-labels and U-labels. Unicode Technical Standard 39 describes mechanisms for identifying confusable strings. These are related but different tasks. IDNA representation and validity are not a verdict about affiliation; a confusability comparison is not proof of fraud. This article proposes a defensive review method without registering names, sending messages or visiting suspicious domains.
Preserve the forms instead of collapsing them
RFC 5890 section 2.3.2.1 defines an A-label as the ASCII-compatible form of an IDNA-valid label and a U-label as its Unicode form under the specified requirements. Not every string beginning with the familiar xn-- prefix is a valid A-label. A parser must validate the relationship rather than treating the prefix alone as proof. Likewise, an arbitrary Unicode string is not automatically a valid U-label simply because it looks like a domain label.
Retain the raw observed value before transformation. Then record the parser and version used, the validated label forms it produced, and any errors. Keep the displayed value from the mail client as a separate observation. A screenshot can document appearance, but it cannot replace the underlying code points or parsed address. This manuscript has not run a normalization tool and does not supply purportedly measured conversions. Actual examples must be generated and retained in an authorized evidence exercise.
A confusable skeleton is not a DNS name
Unicode TR39 describes confusable detection using defined transformations and data. The retained current document includes direction-aware skeleton processing and notes that comparisons can be overly inclusive. A skeleton is a comparison artifact. It should not be used as the address to query, the domain to allowlist or the value to publish in DNS. Two strings matching under a comparison method do not become the same domain or acquire the same owner.
Record the Unicode data version, algorithm and relevant direction assumptions when using such a method. Do not simplify the current specification into an undocumented instruction to lowercase and replace visually similar characters. That would be a different algorithm with unknown behavior. If a product offers a similarity score, retain the product's method and limitations separately from the standard. A score can prioritize human review without establishing malicious intent or a receiver's actual display behavior.
Presentation depends on the consuming application
The same underlying domain may be presented differently by different applications and contexts. Do not promise that every mail client displays Unicode, always exposes an ASCII form or consistently warns about mixed scripts. A current receiver outcome needs an actual observation of the relevant client, version, platform and message context. This article has not performed those observations and therefore makes no claim that a particular provider would display or block a specific test name.
When collecting authorized evidence later, preserve both the raw identity and what the user saw. Include whether the address was expanded or collapsed, whether the display name was shown separately and which interface supplied any warning. Avoid generalizing from one screenshot to all recipients. Accessibility review matters as well: a visual resemblance and a spoken rendering can create different comprehension problems, but neither should be asserted without an appropriate observed example.
Authentication follows domains, not perceived resemblance
RFC 9989, section 2.2, states that DMARC does not address visually similar domain names or display-name abuse. A separate domain can authenticate mail for itself even when a recipient mistakes it for a trusted organization. That is not a reason to stop checking alignment. It is a reason to preserve the distinction between the actual domain and the identity the recipient inferred from its appearance.
Use trusted receiver authentication evidence, following the trust-boundary concerns in RFC 8601. Record which domain authenticated and which visible From domain was evaluated. Do not replace those domains with a confusable skeleton before assessing their relationship. Normalizing a display for comparison must not silently change the protocol identity being investigated. Keep the authentication result and the human-recognition issue as linked but distinct observations.
An identity-representation worksheet
Build a worksheet with the original message field, raw extracted domain, code-point representation where needed, validated A-label and U-label forms, parser version, validation outcome and displayed client form. Add the comparison target from a trusted business record, confusable-detection method and version, comparison result, receiver authentication provenance and requested action. Include separate columns for observed facts and analyst interpretation.
For privacy, redact unrelated message content and personal identifiers while preserving the exact domain distinctions needed for the case. Do not publish a real suspicious domain as a clickable link merely to illustrate the worksheet. Use an approved non-interactive evidence presentation. If fictional strings are used for teaching, label them as illustrative and do not claim they were registered, accepted by a provider or displayed by a receiver. A fabricated receiver outcome would defeat the purpose of the evidence requirement.
Fictional diagnosis: a name that looks familiar
A fictional procurement analyst notices that a supplier message appears to use a familiar name, but an expanded address view reveals a different underlying domain. The security team proposes preserving the raw address and comparing validated representations using a documented tool. At this stage the team has a concern about confusability, not proof of malicious intent or ownership. The requested supplier-record change remains paused under the normal business process.
The team would verify affiliation through a supplier contact already recorded independently. It would also retain actual receiver evidence if an authorized investigation proceeds. The hypothetical case deliberately includes no invented Unicode conversion, skeleton output or claim that a named mail client displayed a particular string. Those are observations that must be collected, not details to fill in for narrative convenience. No domain was queried, registered or used to send mail during this work.
Release only with the required examples
A defensible conclusion distinguishes valid representation, similarity, affiliation, authentication and observed harm. It can state that a comparison method found confusability without claiming a crime. It can state that a different domain authenticated without certifying the business request. It can document a receiver's presentation without claiming that every receiver behaves the same way. These distinctions make the resulting guidance useful across legitimate internationalized naming as well as impersonation investigations.
The catalogue requires raw and displayed identity examples with normalized DNS forms and receiver outcomes. Those original observations remain open. This manuscript contains a worksheet and fictional diagnostic process, not that evidence. Human specialist review, source applicability, production routes, visual accessibility and owner release also remain open. Publication requires retained, authorized examples with exact tool versions and observed outcomes, reviewed without exposing unnecessary personal data or making unsupported allegations about a domain operator.