No, we do not support domains with special characters (such as _ or %). We also do not support IDN (internationalized domain names) or Punycode domains at this time.

This limitation preserves stability across our hosting infrastructure. Non-standard characters create parsing failures in DNS resolution, web server hostname binding, certificate validation, and application request handling. Selecting a compliant domain from the start prevents deployment delays and support escalations.

#Special Characters in Domain Names

The DNS protocol and hostname standards restrict valid characters to ASCII letters a-z, digits 0-9, and the hyphen. Special symbols fall outside this set and trigger errors at multiple layers. On Windows servers, IIS and the .NET runtime expect clean hostnames; symbols break URL routing, virtual host matching, and SSL subject name validation. The underscore and percent sign are two of the most commonly attempted invalid characters.

  • Underscores (_): Occasionally used by administrators in internal naming or SRV records, but invalid for HTTP host headers and web hosting.
  • Percent signs (%): Reserved for URL percent-encoding and cannot appear in registered domain labels.
  • Additional symbols (@, #, $, &, *, !, spaces): All produce immediate rejection during domain addition or DNS zone loading.

#IDN and Punycode Domains

Internationalized Domain Names permit native-language characters such as accented Latin letters, Cyrillic, Arabic, or Han script. Because core DNS remains ASCII-only, these names are converted to Punycode strings prefixed with "xn--". While this encoding enables global accessibility, our current platform does not decode or route traffic for Punycode labels. Support for the additional character tables, encoding/decoding logic, and certificate SAN handling has not been implemented.

Unsupported domain examples:

- café.com (native IDN form)
- xn--caf-dma.com (Punycode representation)
- bücher.example (IDN)
- my_site.com (contains invalid _ character)

#Technical Reasons for the Restrictions

Introducing IDN or special-character support requires coordinated changes: updated DNS zone parsers, modified IIS site bindings, extended certificate request handling for Unicode subjects, and application-layer canonicalization routines. Until these components are validated for production use, the platform enforces the narrower character set. This prevents subtle bugs such as mismatched redirect rules, failed email delivery on custom domains, or SSL handshake errors that would otherwise appear only after deployment.

Register a domain using only lowercase letters, numbers, and hyphens. Avoid leading or trailing hyphens. This format works with every feature we offer: primary domains, addon domains, subdomains, email addresses, and SSL issuance. Most registrars provide real-time availability and syntax validation; use those tools before checkout. After registration, update the nameservers to ours or create A/AAAA records pointing to the assigned IP. The control panel then lets you add the domain and configure the site.

  • Validate the full FQDN for forbidden characters prior to purchase.
  • If an international audience is required, use a compliant base domain with language-specific paths or subdirectories rather than depending on IDN.
  • Test DNS propagation and host header resolution immediately after pointing the domain.

In practice, always confirm domain compatibility before transfer or nameserver changes. A standards-compliant name eliminates configuration friction and lets you focus on site deployment rather than troubleshooting hostname errors. Refer to the domain addition and DNS record documentation for the exact steps once you have a supported domain.