A domain displayed in Unicode may be queried through an ASCII-compatible representation. Preserve both forms and the conversion rules so that a checker result can be reproduced. Visual familiarity is not evidence that two names identify the same domain or belong to the same organization.
Separate the domain from the mailbox
References: RFC 5890 §2.3.2.1, RFC 5891 §5.
An internationalised domain label can have a U-label, its valid Unicode form, and an A-label, its validated ASCII-compatible form beginning xn--. IDNA processing operates on domain labels. It does not convert an email local part into an ASCII mailbox and does not establish SMTPUTF8 support.
Authentication records add protocol labels around the domain. Convert the internationalised domain portion with the appropriate IDNA implementation, then construct the owner, such as _dmarc. plus the A-label domain. Do not run a hostname-only IDNA validator over protocol underscore labels and conclude that the underlying domain is invalid.
Validate rather than merely encode
References: RFC 5890 §2.3.2.1, RFC 5891 §4, RFC 5895 §2.
Punycode is part of the A-label representation, but not every string beginning xn-- is a valid A-label. Validation includes the applicable IDNA rules, permitted characters and contextual restrictions. RFC 5891 defines protocol processing, while application mapping choices can affect user input before that processing.
Record the library and version, IDNA profile, Unicode input and resulting ASCII form. Tool defaults can differ, especially for characters affected by mapping or older IDNA behavior. Avoid silently normalizing an ambiguous user entry and presenting the result as the only possible intended domain.
Reproduce a round-trip fixture
Using an installed Python idna library that implements IDNA2008, run idna.encode("bücher.example", uts46=False).decode("ascii"). Expected output is xn--bcher-kva.example. Decode it with the same library and verify the Unicode round trip. The example is illustrative and is not a claim about an organization's live domain.
Construct _dmarc.xn--bcher-kva.example and s1._domainkey.xn--bcher-kva.example as DNS owner strings. In a lab or controlled checker, capture whether the tool accepts the Unicode input, converts it, rejects it or sends a different question. The retained historical capture records only library conversion, with idna version 3.18. The new offline conversion check in this review records its own installed version separately; neither is a DNS or SMTPUTF8 test.
Add a negative fixture with an invalid xn-- label and retain the actual library exception. Treat rejection as useful evidence rather than deleting characters until the input happens to pass. For other user-facing mappings, document the alternative profile explicitly instead of assuming an IDNA2008 strict result matches every browser.
Compare actual identities in mail evidence
References: RFC 9989 §4.4, RFC 9989 §5.3.1.
Preserve the original From header and the domain representations used by SPF, DKIM and DMARC analysis. For DMARC, RFC 9989 §5.3.1 requires an extracted U-label Author Domain to be converted to A-label form for further processing. Use the protocol's alignment rules rather than a visual comparison of displayed names. Where message syntax or internationalisation behavior is unsupported by a tool, report the limitation instead of silently picking a convenient identity.
Use known ownership context to investigate lookalikes. A domain can pass its own authentication and still visually resemble another organization's name. IDNA conversion improves reproducibility; it does not certify brand ownership, remove phishing risk or prove that an email message was authorized by the expected party.