Arabic domain names and email: a production checklist for MENA products

A signup form can accept مستخدم@مثال.السعودية and still fail everywhere that matters next: validation, storage, password reset, CRM sync, support tooling or SMTP delivery.

The problem is usually a blurred boundary. The domain after @ follows internationalized domain-name rules. The mailbox local part before @ follows email internationalization rules. Punycode handles the domain. It does not convert the mailbox name. Treating the whole address as one "Unicode email" string creates bugs that are hard to reproduce and worse to unwind.

This guide separates those lanes and turns the standards into an implementation path for product and engineering teams serving Arabic-speaking users.

Start at the @ boundary

An internationalized email address has two technically different identifiers:

مستخدم @ مثال.السعودية
local part   domain

The domain can have two useful forms. RFC 5890 calls the Unicode form a U-label and the ASCII form beginning with xn-- an A-label. DNS-facing systems use the A-label. A product may show the U-label when it passes the product's display and security policy.

The local part is different. RFC 6530 defines the framework for internationalized email, while RFC 6531 extends SMTP with SMTPUTF8. There is no Punycode step for the local part. Keep its UTF-8 value intact unless the mailbox provider gives you an explicit canonicalization contract.

This distinction leads to a simple data model:

type InternationalAddress = {
  original: string;        // what the user submitted
  localPartUtf8: string;   // preserve exactly
  domainUnicode: string;   // validated display candidate
  domainAscii: string;     // A-label for DNS/network use
};

Do not use toLowerCase() on the entire email address. Domain names are case-insensitive in normal lookup. Local-part equivalence belongs to the receiving mail system, not your application.

Normalization is a policy, not a cleanup function

Teams often reach for Unicode normalization, lowercase conversion and a permissive regex. That is not enough.

The domain should pass one pinned IDNA policy. Unicode Technical Standard #46 defines Unicode IDNA Compatibility Processing used by web implementations. It includes configurable behavior, including transitional versus nontransitional processing. Record the library and mode in tests. A browser successfully navigating to a name does not prove that a registry will accept it, and a registrar accepting it does not prove that every downstream SaaS product will preserve it.

Arabic labels also have bidirectional requirements. RFC 5893 applies rules per label, not to the full domain as an undifferentiated string. One easily missed rule: an RTL label cannot mix European digits and Arabic-Indic digits. Validate each label before storage and give the user a precise error instead of silently rewriting it.

For web code, use a standards-backed URL implementation rather than a handwritten Punycode package. Node's URL API exposes domainToASCII() and domainToUnicode():

import { domainToASCII, domainToUnicode } from 'node:url';

export function normalizeDomain(input: string) {
  const unicode = input.trim().replace(/\.$/, '');
  const ascii = domainToASCII(unicode);

  if (!ascii) throw new Error('Invalid internationalized domain');
  if (domainToASCII(domainToUnicode(ascii)) !== ascii) {
    throw new Error('Domain did not survive IDNA round trip');
  }

  return { unicode: domainToUnicode(ascii), ascii };
}

This is a lookup conversion, not a registry-availability check. Keep registration policy and domain availability outside your generic input validator.

Store both the submitted value and the DNS identity

A single email VARCHAR(255) column hides too much.

Store the original address for audit and support, the local part as UTF-8, and the domain's Unicode and ASCII forms separately. The A-label is useful for DNS, MX lookup and stable comparisons. The Unicode form is useful for display. Neither should be regenerated with a different library version on every read.

A practical schema might look like this:

create table user_email (
  id uuid primary key,
  original_utf8 text not null,
  local_part_utf8 text not null,
  domain_unicode text not null,
  domain_ascii text not null,
  delivery_status text not null default 'unverified',
  unique (local_part_utf8, domain_ascii)
);

That unique constraint is only a product rule. If a provider says two local parts are equivalent, model that provider-specific rule explicitly. Do not assume Gmail-style dot or case behavior applies to another mailbox host.

Plan for the boring systems too. CSV exports need UTF-8 with a declared encoding. Support dashboards must preserve right-to-left text without reordering punctuation. Analytics pipelines should not split an address at a visually rendered boundary. CRM and identity providers need round-trip tests, not a checkbox in a vendor feature table.

Production flow for Arabic domains and internationalized email. Sources: RFC 5890, RFC 5893, RFC 6530, RFC 6531, Unicode UTS #46, Unicode UTS #39 and ICANN Universal Acceptance. Credit: SultanByte original artwork.

SMTPUTF8 is a delivery capability

A valid address and a working MX record do not prove that mail can reach an internationalized mailbox.

During SMTP negotiation, a server that supports internationalized envelope addresses advertises SMTPUTF8. RFC 6531 requires the extension when non-ASCII addresses are used in the envelope or when internationalized header information requires it. Every relay on the chosen delivery path has to preserve the message correctly.

Test the path you deploy:

1. Submit the exact UTF-8 address through the product UI and API.
2. Confirm the application preserves the local part and converts only the domain for DNS-facing operations.
3. Resolve MX records using the domain A-label.
4. Connect through the same email service and relay configuration used in production.
5. Verify that the receiving path advertises and accepts SMTPUTF8.
6. Deliver a verification message, then test reply, bounce and complaint handling.

If the path cannot carry SMTPUTF8, do not downgrade the mailbox name or replace characters. Ask for an ASCII fallback address and explain why. Silent rewriting can send account recovery mail to a different mailbox or make an address impossible to reproduce later.

Password-reset and login flows need extra care. Decide whether the submitted address is an identifier, a delivery destination or both. A failed delivery should not mutate the account identifier. If a user changes to a fallback address, log that as an explicit account event.

Valid IDNA is not safe display

A domain can be valid under IDNA and still be confusing to a user.

Unicode Technical Standard #39 describes mechanisms for detecting confusable characters, mixed scripts and mixed-number patterns. Use those signals in registration, admin and security-sensitive screens. They are risk indicators, not automatic proof of abuse.

The WHATWG URL Standard explains how browsers process domain names, but browser rendering is not a guarantee that every client will display Unicode. Security heuristics may show an A-label instead. Your product should be ready for both.

Useful display rules include:

• Show the Unicode domain in ordinary user-facing contexts only after policy checks.
• Show both Unicode and A-label forms in admin, fraud, payment and account-recovery screens.
• Flag unexpected mixed scripts and confusables for review.
• Never rely on font shape or visual similarity as identity.
• Keep copy and support instructions explicit about which form users should paste.

For a high-risk action, a compact display such as مثال.السعودية (xn--... ) is less elegant but easier to verify.

Universal Acceptance reaches beyond the form

ICANN's Universal Acceptance guidance frames the job across acceptance, validation, storage, processing and display. A regex that permits Unicode solves only the first few milliseconds of the flow.

Build a dependency matrix for every place the identifier travels:

Do not trust documentation alone for downstream systems. Run a test corpus through every integration and compare exact output.

A release gate that catches real failures

Create a judged set before enabling internationalized addresses for every account. Include:

• Arabic-only domain labels;
• mixed Arabic and ASCII labels across separate domain levels;
• Arabic-Indic digits and European digits in separate valid cases;
• an invalid RTL label that mixes both digit classes;
• an ASCII local part with an Arabic domain;
• a non-ASCII local part with an Arabic domain;
• decomposed and precomposed Unicode input;
• a confusable or unexpected mixed-script domain;
• trailing dots, leading or repeated separators, and overlong labels;
• bounce, reply, password reset, export and account deletion flows.

For each case, record the submitted string, parsed boundary, Unicode domain, A-label, validation result, display decision and delivery result. Pin these fixtures to the same library version and processing mode used in production.

Roll out behind an account or market flag. Watch verification completion, bounce classes, support tickets and provider-specific failures. Keep the old ASCII-only path available as a fallback during the first release, but do not coerce valid internationalized input into it.

The implementation decision

Support the domain lane first if your delivery provider cannot yet handle non-ASCII local parts. An address such as user@مثال.السعودية can use an ASCII local part while still requiring IDNA handling for the domain. That gives Arabic-speaking users meaningful support without pretending the mail path can carry more than it does.

Full EAI support comes later: preserve the UTF-8 local part, confirm SMTPUTF8 end to end, test every relay and downstream system, then expose it gradually.

The safe design is not complicated once the boundary is explicit. Split at @. Apply IDNA only to the domain. Keep the mailbox name intact. Store both domain forms. Treat delivery and secure display as separate checks. Most failures begin when one of those responsibilities is hidden inside a generic "email validator."