Assess the exact proposed domain and email addresses across the complete website and mail workflow; use standards-aware validation and keep a usable contact fallback.
An address containing accented or non-Latin characters is not automatically unusable, and an ASCII-looking version is not automatically compatible with every system. Separate the domain name, the email local part and the applications that handle them. Then review the exact address through the complete journey people need.
Imagine a fictional cultural workshop whose public name uses accented characters. It is considering a matching domain and contact address. The workshop wants a respectful public identity, reliable enquiries and recoverable accounts. The example below is a proposed decision process; no name has been registered or tested.
Distinguish the name people read from its domain representation
RFC 5890 distinguishes valid Unicode U-labels from their ASCII A-label representations in IDNA. Validity is evaluated at the label level; registration policy remains a separate matter. An xn-- prefix alone proves neither a valid label nor ownership or safety.
For the workshop, keep the intended spelling and the registrar’s actual supported representation in the same decision record. Do not invent an encoded equivalent by guessing at the characters. A valid representation would still need availability and policy checks before the organization could choose it.
The domain registrar checklist covers control and commercial terms. Add compatibility to that review rather than choosing a registrar solely because its search box displays the desired spelling.
Separate the email domain from the local part
The part before the at sign and the domain after it need separate consideration. RFC 6531 defines SMTPUTF8 for internationalized email. A non-ASCII local part differs from an ASCII local part using an IDNA domain representation; an internationalized domain alone does not necessarily require SMTPUTF8.
Write down the workshop’s proposed contact address exactly. Ask the mail provider which form it supports and what the intended recipients and administrative systems can handle. Do not substitute an ASCII local part silently and then claim the original address has been validated.
A visitor may enter a valid address that is different from the workshop’s own format. That is a second workflow. Review both sending from the workshop and receiving enquiries from visitors, instead of assuming that support for the organization’s address establishes support for every correspondent.
Use maintained processing, not a homemade character rule
Unicode UTS #46 describes IDNA compatibility processing. The checked revision uses nontransitional processing and deprecates transitional processing. It does not make every Unicode character valid or guarantee protection from visually confusable names. Use a maintained, standards-aware implementation rather than a handwritten encoder or broad character-removal rule.
Give the implementer examples of the journeys to support, not an instruction to “remove everything unusual.” The workshop’s booking form should either accept the address through its documented supported processing or explain a real limitation. Quietly changing a visitor’s address can send the reply somewhere unintended.
Preserve enough context to explain a validation failure without exposing a visitor’s full address in a public error report. A support record can identify the failing field and processing stage. Production address data should not be copied into a public demo merely to demonstrate the defect.
Review the entire chain of systems
| Journey | Question for the responsible owner | Evidence to retain |
|---|---|---|
| Registration and renewal | Does this registry and registrar support the exact proposed name? | Supported spelling, representation and account control |
| Website delivery | Do the intended hostname, HTTPS and navigation agree? | Approved address and observed destination |
| Enquiry form | Does the address survive validation and storage unchanged in meaning? | Input, accepted representation and reply destination |
| Mail workflow | Can the agreed senders and recipients handle the address? | Provider capability and controlled delivery results |
| Recovery and export | Can administrators recover access and move the stored records? | Documented recovery and export journey |
This is a proposed responsibility map, not a claim that each component has passed. Assign an owner to every row. A single successful browser visit leaves unanswered questions about a customer database, notification tool or account-recovery service used later in the journey.
Coordinate domain connection carefully. The website and email DNS guide explains why those services should be reviewed together. Do not treat an address-format decision as authorization to replace existing receiving records.
Make compatibility a practical acceptance question
ICANN’s Universal Acceptance work aims for valid domain names and email addresses to be accepted by software and services. That goal does not establish that every application in a particular organization already complies. Ask for evidence about the tools and versions the workshop actually plans to use.
For a controlled review, use addresses and accounts the organization is entitled to test. Check a new enquiry, its stored record, the staff reply and the normal recovery route. Include an exported and re-imported record if that movement is a real operational requirement. These are proposed tests, not results.
Record failures precisely. “The browser page opens, but the enquiry tool rejects the email domain” is actionable. “International domains do not work” is too broad and may lead to an unnecessary identity change instead of a focused software repair.
Keep a usable fallback without misrepresenting support
The workshop can publish an additional contact route while a particular integration is unresolved. Label it as an alternative, keep it monitored and decide how staff will reconcile enquiries. An abandoned fallback is worse than a clearly documented temporary limitation.
Do not claim that an alias solves every compatibility issue. Confirm what that alias actually changes in the workflow and whether the visitor can complete the task. Keep the public name, website hostname, sending address and reply address understandable rather than allowing them to drift independently.
Account recovery deserves its own review before the organization depends on a new address. Use the email administrator recovery guide to keep access continuity separate from whether the address looks correct on a marketing page.
Review identity and confusable addresses deliberately
Have a reader familiar with the intended language review the visible name and its context. Also examine easily confused alternatives when choosing public links and support instructions. This is an editorial identity check, not a declaration that internationalized names are inherently suspicious.
Use links whose destination the organization has verified, and give staff a consistent reference for the approved address. Avoid solving a concern with a blanket ASCII-only policy that has never been assessed against the audience’s actual needs.
- Approve the exact proposed name and email format with the responsible registration and mail providers.
- Review the website, enquiry, reply, export and recovery journeys.
- Record supported representations, observed failures and owners.
- Keep an understandable contact fallback until the required workflows pass.
- Revisit compatibility when a relevant service or implementation changes.
Choose the address when its real operational chain meets the workshop’s needs. Neither a pleasing spelling nor a generic claim of Unicode support can replace that end-to-end evidence.
Sources and verification
Editorial review 2026-10-15. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- RFC 5890: IDNA definitions and document frameworkChecked U-label and A-label distinctions, label validity and the separate role of registration policy.
Limits: A valid label or xn-- prefix does not prove availability, ownership, safety or universal application support. - Unicode UTS #46: IDNA compatibility processingChecked Compatibility processing and current nontransitional handling; transitional processing is deprecated.
Limits: Processing is not arbitrary-character acceptance, a replacement for a maintained implementation or an anti-phishing guarantee. - RFC 6531: SMTP extension for internationalized emailChecked SMTPUTF8 support for internationalized email and the distinction between a domain representation and a non-ASCII local part.
Limits: An internationalized domain alone does not require SMTPUTF8 when an ASCII local part and suitable domain representation are used. - ICANN: Universal AcceptanceChecked The goal of accepting valid domain names and email addresses across software and services.
Limits: Universal Acceptance work is not evidence that every existing system already supports a proposed address.