Every so often a customer calls us about a domain that "isn't working right" — email bounces, the SSL cert looks wrong, or a link shared on WhatsApp shows a string like xn--e1aybc.xn--p1ai instead of the name they registered. Nine times out of ten, the domain is an IDN — an International Domain Name using non-Latin characters — and the confusion comes down to one thing: browsers and humans see Unicode, but DNS, mail servers, and SSL systems only ever see ASCII underneath.
What an IDN Actually Is
An IDN lets a domain use characters outside plain a-z0-9-, things like Devanagari script for a .in or .भारत domain, accented Latin letters, or CJK characters. Under the hood, none of that Unicode ever touches the DNS root servers directly. It gets converted to an ASCII-safe form called Punycode, always prefixed with xn--. So मेरा-नाम.in becomes something like xn--c1yn7c1a4b.in in every DNS zone file, every SSL certificate, and every mail server log.
Your browser hides this and shows the pretty Unicode version in the address bar. Almost nothing else in the hosting stack does.
Symptom: What You'll Actually See
- A link pasted into email, Slack, or WhatsApp shows the ugly
xn--string instead of your real domain name - cPanel/WHM refuses to add the domain, or shows it internally as the
xn--form with no obvious link back to the Unicode name you typed - AutoSSL or Let's Encrypt issuance fails, or the certificate's Common Name looks like gibberish when you inspect it
- Mail sent to
info@मेरा-नाम.in-style addresses bounces with a DNS or MX lookup failure - WHOIS lookups or registrar dashboards show the domain oddly duplicated — once in script, once in Punycode
- WordPress's Site URL / Home URL settings get saved in one form and the actual DNS is in the other, breaking redirects
Cause: Why It Breaks
Nearly every failure traces back to someone entering the Unicode version where the system expected — and silently assumed — ASCII/Punycode, or vice versa. A few specific culprits we see constantly:
| Where It Breaks | Why |
|---|---|
| DNS zone editor | A records, MX records, and CNAMEs must reference the Punycode form. Some panels auto-convert on save, others don't — inconsistency causes lookups to fail |
| SSL / AutoSSL | Certificate authorities validate and issue against the Punycode hostname. If your CAA record or DCV check references the Unicode string, validation fails |
| Email (MX/SPF/DKIM) | Mail servers do everything in ASCII. An MX record pointing at a Unicode hostname simply won't resolve for most sending mail transfer agents |
| WordPress wp-config / siteurl | If WP_HOME/WP_SITEURL is set to the Unicode form but Apache/Nginx's server_name uses Punycode, you get redirect loops or mixed-content warnings |
| Copy-paste from browser address bar | Copying a URL from Chrome gives you Unicode; pasting that into a config file, cron job, or curl command that expects ASCII breaks silently |
Fix: Getting It Working
Step 1 — Get the Punycode Form Right
Convert your domain once and keep both forms documented somewhere your team can find them. You don't need special tools for this — WHM's "Domains" list already shows the Punycode form next to any IDN you've added, and most registrar control panels display it under the domain's advanced details.
Step 2 — Add the Domain to cPanel/WHM Using Punycode
When creating the account or adding it as an addon domain, use the xn-- form as the primary hostname. Let cPanel display the Unicode label to you in the UI — that's cosmetic — but the underlying vhost, DNS zone, and SSL request should all be built against Punycode.
Step 3 — Fix DNS Records
Open Zone Editor and check every record tied to the domain — A, AAAA, MX, TXT, CNAME. They should all use the Punycode hostname as the record name. If you find a record with literal Unicode characters in the name field, that record will never resolve correctly for most resolvers and needs to be recreated in ASCII form.
Step 4 — Reissue SSL Against the Right Name
Run AutoSSL again after fixing the DNS. If it still fails, check for a CAA record — it also needs the Punycode hostname, not Unicode, or the certificate authority won't recognize it as matching. Pull the AutoSSL log in cPanel's SSL/TLS Status page; a DCV (domain control validation) failure here almost always means the hostname mismatch above.
Step 5 — Fix Email DNS and WordPress Config
MX, SPF, and DKIM records all need the Punycode hostname. If mail is still bouncing after DNS looks correct, check the actual envelope-from and Return-Path your mail server is using — some older Exim/Postfix configs generated with the Unicode string need to be regenerated. For WordPress, set both WP_HOME and WP_SITEURL in wp-config.php explicitly to the Punycode https://xn--... form; it will render correctly to visitors regardless, since the browser handles the Unicode display on its own.
define('WP_HOME', 'https://xn--c1yn7c1a4b.in');
define('WP_SITEURL', 'https://xn--c1yn7c1a4b.in');Prevention
- Keep a one-line note in your project docs or password manager listing both the Unicode and Punycode forms of every IDN domain you manage
- Always paste the Punycode form into config files, cron scripts, curl commands, and API calls — never copy straight from a browser address bar
- Test new IDN setups with
digornslookupagainst the Punycode hostname before assuming DNS propagation is the problem - If a domain isn't genuinely needed in a non-Latin script, consider a plain ASCII domain instead — it removes an entire category of tooling friction, especially for WooCommerce stores integrating with payment gateways that don't handle Unicode hostnames gracefully
- Watch for homograph look-alikes — characters from different scripts that render identically (a Cyrillic "а" next to a Latin "a") are a known phishing technique, so verify any IDN domain you're asked to trust actually resolves to Punycode you recognize
Frequently Asked Questions
Is an IDN domain technically different from a regular domain once it's set up?
No — once converted to Punycode, it's just an ASCII hostname like any other, and DNS, hosting, and mail treat it identically. The complexity is entirely in getting every system to agree on using that ASCII form consistently.
Can I still get a free SSL certificate for an IDN domain?
Yes. Let's Encrypt and cPanel's AutoSSL both support IDN/Punycode hostnames without issue, as long as DNS and any CAA record are set up against the Punycode form.
Why does my domain show up as "xn--..." in emails and chat apps but fine in the browser?
Browsers translate Punycode to Unicode for display, but most other software — email clients, messaging apps, terminal tools — shows the raw ASCII/Punycode form since that's what actually exists in DNS. This is expected, not a bug.
Will someone typing the Unicode name still reach my site?
Yes. Modern browsers automatically convert what a user types (or a native-script keyboard produces) into Punycode before making the DNS request, so visitors typing the script version reach the same site.
Does using an IDN domain hurt SEO?
Not directly — search engines index and rank the Punycode form the same as any ASCII domain. The bigger risk is user trust and click-through rate, since an unfamiliar xn-- string in a shared link can look suspicious to visitors who don't recognize what it is.
