# Arabic Domains and Email in Production: An IDNA and SMTPUTF8 Guide

The `@` character is an architectural boundary. IDNA handles the domain on the right; SMTPUTF8 carries an internationalized mailbox on the left.

Consider the illustrative address `مستخدم@مثال.إختبار`. The domain `مثال.إختبار` can be converted into ASCII labels for DNS. The local part `مستخدم` cannot. Punycode belongs to domain labels, not mailbox names.

That distinction is easy to lose when a product team adds "Unicode email support" as one ticket. A form can accept the address while the mail relay, identity provider or support platform later rejects it. Production support needs two separate policies and an end-to-end test path.

## Start with the two standards paths

An internationalized domain name (IDN) lets people use Unicode in domain labels. [RFC 5890](https://www.rfc-editor.org/rfc/rfc5890.html#section-2.3.2.1) calls the validated Unicode form a U-label and its ASCII-compatible form an A-label. A-labels begin with `xn--`. DNS-facing systems use the A-label; a localized interface may display the U-label after validation.

Internationalized email is different. [RFC 6530](https://www.rfc-editor.org/rfc/rfc6530.html#section-3.2) separates an IDN in the domain from non-ASCII characters in the mailbox local part. An Arabic display name in `Name <user@example.com>` is not an internationalized mailbox either. It is ordinary message-header presentation.

The capability matrix is small enough to make explicit:

| Address shape | IDNA needed | SMTPUTF8 needed |
| --- | --- | --- |
| ASCII local part + ASCII domain | No | No |
| ASCII local part + Arabic domain | Yes | No |
| Arabic local part + ASCII domain | No | Yes |
| Arabic local part + Arabic domain | Yes | Yes |

The second row is often the sensible first release. It gives Arabic brands a localized domain while retaining an ASCII mailbox local part and the widest mail compatibility.

## IDNA2008 and web URL processing are not identical

A backend team may expect every standards-compliant library to accept and transform the same input. That is not a safe assumption.

[RFC 5891](https://www.rfc-editor.org/rfc/rfc5891.html#section-4.1) defines IDNA registration and lookup processing. Registries also apply their own policies, including reserved labels and variant handling. Browser URL parsers generally follow the [WHATWG URL Standard](https://url.spec.whatwg.org/#idna), which uses Unicode IDNA Compatibility Processing. [Unicode Technical Standard #46](https://www.unicode.org/reports/tr46/#Processing) supplies mappings intended to make user input work with IDNA, and current guidance uses nontransitional processing.

Those layers solve related problems, but they are not interchangeable. A browser successfully navigating to a domain does not prove a registrar will accept the label. A conversion library returning an A-label does not prove the chosen top-level domain allows registration.

Pin one library and processing mode on the server. Record its Unicode data version. Use the same policy in validation jobs, imports and administrative tools. Frontend conversion can improve feedback, but the server should remain authoritative.

Arabic labels also need the bidirectional rules in [RFC 5893](https://www.rfc-editor.org/rfc/rfc5893.html#section-2). An RTL label must begin and end with permitted character classes, and it cannot mix European digits with Arabic-Indic digits in the same label. Let a conforming library enforce these conditions label by label. Visual inspection is unreliable because rendered order is not network order.

## A safe production pipeline

The same five stages should be visible in architecture, code ownership and error telemetry.

![Five-step production pipeline for Arabic domains and internationalized email. Separate IDN domain and EAI mailbox lanes move through input, normalization, validation, storage and display, with a reminder that IDNA applies to domain labels while SMTPUTF8 carries non-ASCII mailbox syntax.](https://cdn.hashnode.com/uploads/covers/60ecf4a0fc37a15ec15655e8/093af32e-e5c0-49a0-9a28-88dc788dee3e.png align="center")

*Five-stage processing path for Arabic domains and internationalized email. Sources: RFC 5890, RFC 5891, RFC 5893, RFC 6530, RFC 6531, Unicode UTS #46 and UTS #39. Credit: SultanByte editorial artwork.*

### 1\. Input

Accept typed or pasted Unicode without rewriting it on every keystroke. Parse mailbox syntax with an email-aware parser rather than splitting on `@` or relying on an ASCII-era regular expression. Quoted local parts and escaped characters make naive splitting brittle even before Unicode enters the picture.

Retain the submitted value when policy permits, especially if support staff need to explain a rejection. Treat it as personal data in logs. A useful error record identifies the failed stage and code-point position without copying the full address into every telemetry system.

### 2\. Normalize the domain, not the mailbox identity

Process each domain label with the pinned IDNA policy. Produce a validated U-label for controlled display and an A-label for DNS, certificates and ASCII-only integrations.

Do not apply that transformation to the local part. [RFC 6530's normalization guidance](https://www.rfc-editor.org/rfc/rfc6530.html#section-10.1) makes the receiving system responsible for mailbox interpretation. Global NFKC normalization, case folding, dot removal or punctuation cleanup can merge mailboxes that a provider considers distinct.

### 3\. Validate each concern separately

For the domain, reject disallowed code points and enforce contextual and bidirectional checks. Convert to the A-label before DNS and MX lookup. Remember that each encoded DNS label is limited to 63 octets, so character count in Arabic is not a useful proxy.

For the mailbox, validate EAI syntax separately. Then check transport capability. [RFC 6531](https://www.rfc-editor.org/rfc/rfc6531.html#section-3.2) requires a server to advertise `SMTPUTF8` through EHLO. The client uses the `SMTPUTF8` parameter when the envelope or message needs it.

An MX record only shows where mail should go. It says nothing about whether every relay on the selected path can carry an Arabic local part. If the required next hop cannot support SMTPUTF8, reject the operation clearly or use a deliberately provisioned ASCII alias. Never invent a transliteration.

### 4\. Store representations deliberately

Store the original UTF-8 mailbox value. Store the domain A-label separately for DNS operations, security review and integrations that need ASCII. If the application stores a U-label too, verify that it round-trips through the same pinned implementation.

Database collation is not mailbox equality. Document uniqueness rules instead of letting a default case-insensitive collation decide them. The local part should remain opaque unless the receiving provider has supplied a specific canonicalization contract.

### 5\. Display according to risk

A consumer profile can show the validated Arabic domain prominently. An administrator reviewing a redirect, payment recipient or security alert should be able to see both Unicode and A-label forms.

Clients may make their own display decision. [Chromium's IDN policy](https://github.com/chromium/chromium/blob/main/docs/idn.md#google-chromes-idn-policy), for example, can show Punycode when a label fails security heuristics. Do not promise that every address bar will display the Arabic spelling.

Keep RTL presentation separate from stored order. Use direction isolation around addresses in mixed-language interfaces and test copy/paste into plain text, support tickets and audit tools.

## Valid does not mean safe

IDNA checks whether a label satisfies protocol rules. It does not decide whether the label is deceptive.

[Unicode Technical Standard #39](https://www.unicode.org/reports/tr39/#Confusable_Detection) defines mechanisms for mixed-script and confusable detection. Use them as risk signals. A pure Arabic label is easier to reason about than an unnecessary Arabic-Latin mixture, but a confusable match is not proof that two domains are the same.

Security-sensitive flows should compare the A-label used for navigation or DNS with the value shown to the operator. Allowlists, certificate checks and audit records must use a documented representation. Otherwise one service may approve a Unicode string while another evaluates a different ASCII result.

Direction controls and invisible characters deserve explicit tests. Reject characters that the chosen profile disallows, and show code points in review tooling when two strings look identical. This is particularly useful for incident response, where screenshots and rendered logs can hide the difference.

## Audit the whole dependency chain

A UTF-8 database and an SMTPUTF8-capable mail server do not make the product ready. [ICANN's Universal Acceptance guidance](https://www.icann.org/resources/pages/universal-acceptance-2012-02-25-en) treats acceptance, validation, storage, processing and display as an end-to-end problem.

Check the browser and mobile form, API schema, backend parser, database indexes, DNS resolver, outbound MTA and bounce processor. Then check the systems teams tend to discover late: identity, CRM, help desk, marketing automation, fraud tooling, analytics, CSV exports and warehouse jobs.

For each dependency, record:

*   which address shapes it accepts;
    
*   which representation it stores and returns;
    
*   whether it preserves the local part exactly;
    
*   what happens when SMTPUTF8 is unavailable;
    
*   how a rejection is exposed to users and operators.
    

Avoid a checkbox marked "supports Unicode." Ask for a working fixture and observe the round trip.

## Test the deployed path, not just a validator

Build fixtures for all four rows in the capability matrix. Add mixed-script labels, confusable characters, RTL text beside punctuation, disallowed code points and context-sensitive characters. Record the code-point sequence next to the rendered string so failures remain diagnosable.

For domains, test U-label to A-label to U-label round trips with the exact production library. Test DNS and MX lookup against A-labels. Include labels that exceed the DNS octet limit after encoding.

For email, run controlled delivery through the real relay path. Capture both cases: the next hop advertises SMTPUTF8 and it does not. Verify rejection, bounce, retry and dead-letter behavior. Repeat through password reset, login, CRM synchronization, support replies and export/import paths.

A staged rollout reduces the blast radius:

1.  Support Arabic domains with ASCII local parts.
    
2.  Map every downstream system that touches an address.
    
3.  Enable non-ASCII local parts only on tested SMTPUTF8 paths.
    
4.  Track rejection stage, IDNA errors, MX failures and missing SMTPUTF8 capability.
    
5.  Publish the limits in product and API documentation.
    

Do not promise universal delivery. State which address shapes are supported, preserve identity through every hop, and give users a recovery route that does not silently change their address.

## The production acceptance test

The implementation is ready when the same address survives input, domain conversion, DNS, storage, delivery, support tooling and display without changing identity. IDNA and SMTPUTF8 meet at the `@`, but neither can stand in for the other.

*Cover and infographic credit: SultanByte editorial artwork.*