Sending Email From Domains With UTF-8 or Non-ASCII Characters

Sending email from internationalized domains is possible, but it requires separating what people see from what DNS and mail transport systems actually process. A domain such as bücher.example can appear in branding, but the email infrastructure behind it must consistently use its ASCII-compatible form where the relevant standards require it.

This distinction matters because “non-ASCII email” can describe several very different things: a Unicode character in the domain, a Unicode character in the mailbox name before the @, a sender display name, or raw UTF-8 in message headers. They do not have the same compatibility requirements, and treating them as one problem is the fastest way to produce failed verification, broken SPF/DKIM/DMARC alignment, or SMTP rejections.

Start by identifying which part of the address is non-ASCII

An email address has two major components:

local-part@domain

For example:

support@bücher.example
márta@bücher.example

These examples look similar, but they involve different standards and operational risks.

• support@bücher.example has an ASCII local part (support) and an internationalized domain name (IDN).
• márta@bücher.example has both an internationalized local part and an IDN.
• Bücher Team <support@bücher.example> may also include a Unicode display name, which is a separate header-formatting issue.

The practical rule is simple: an internationalized domain can normally be converted to an ASCII-compatible domain name, while a non-ASCII local part requires SMTPUTF8 support throughout the relevant mail path.

IDNA, the Internationalized Domain Names in Applications standard, exists so applications can register and resolve internationalized names without changing the underlying DNS protocol. It distinguishes the human-readable Unicode form from the encoded ASCII form used in compatible DNS contexts. (rfc-editor.org)

Understand U-labels, A-labels, and Punycode

A Unicode representation of an internationalized domain is called a U-label. Its ASCII-compatible representation is called an A-label. A-labels normally begin with xn-- and are produced with the Punycode encoding algorithm.

For example:

U-label: bücher.example
A-label: xn--bcher-kva.example

Both strings refer to the same intended domain, but they are not interchangeable in every field and protocol. The U-label is useful for a customer-facing address, documentation, and a visible sender identity. The A-label is the reliable operational value for DNS hostnames, DNS record owners, authentication identifiers, and systems that only accept ASCII.

DNS does not store raw UTF-8 labels as ordinary names

The DNS wire format is not “Unicode DNS.” IDNA is an application-layer translation model: an IDNA-aware application turns a valid U-label into an A-label before DNS lookup or DNS record publication. RFC 5891 explicitly describes IDNA as a way to register and look up internationalized names without requiring changes to DNS itself. (rfc-editor.org)

That means you should not paste bücher.example directly into a DNS zone file or assume every DNS provider UI will convert it correctly. Use the A-label when creating records unless your DNS provider documents that it performs IDNA conversion and shows the resulting A-label for confirmation.

Convert once, then keep a canonical infrastructure form

For mail infrastructure, store both forms deliberately:

Do not treat a U-label and an A-label as two separate sender domains. They are two representations of the same domain name, and your application should normalize them before comparing configurations, checking allowlists, or choosing a DKIM signing domain.

Why an IDN domain is not the same as an SMTPUTF8 address

The most important compatibility distinction is between an internationalized domain name and an internationalized email address.

If you send from:

notifications@xn--bcher-kva.example

the full envelope address is ASCII. Traditional SMTP servers can process it without the SMTPUTF8 extension because Punycode has converted the domain to ASCII.

If you send from:

márta@xn--bcher-kva.example

the local part still contains UTF-8. Punycode does not apply to mailbox names before @. That sender address needs Email Address Internationalization (EAI) support, including the SMTPUTF8 SMTP extension.

RFC 6531 defines SMTPUTF8 for transporting messages that use internationalized email addresses or internationalized header information. (rfc-editor.org)

The safe default for broad compatibility

If your goal is to use a localized domain while retaining the widest possible compatibility, use:

ASCII-local-part@A-label-domain

For example:

billing@xn--bcher-kva.example
support@xn--fiqs8s.example
hello@xn--caf-dma.example

You can still use a localized display name:

Bücher Rechnungen <billing@xn--bcher-kva.example>

The display name can be encoded safely in the message header when necessary. It does not require the envelope sender to have a Unicode local part.

When SMTPUTF8 becomes mandatory

SMTPUTF8 is required when the SMTP envelope or message headers contain UTF-8 in places that traditional SMTP does not permit. The clearest case is a non-ASCII local part:

MAIL FROM:<márta@xn--bcher-kva.example> SMTPUTF8
RCPT TO:<客户@example.net>

The receiving SMTP server must advertise support in response to EHLO, typically with a line such as:

250-SMTPUTF8

A sender must not assume that every route, relay, forwarding service, mailbox provider, or legacy gateway supports it. SMTPUTF8 is standardized, but end-to-end deployment is still a compatibility concern because delivery depends on every SMTP hop that needs to process the internationalized address. (rfc-editor.org)

Use the A-label in DNS authentication records

Email authentication depends on DNS. For internationalized domains, the stable operational approach is to publish authentication records under the A-label version of the domain.

RFC 8616 updates SPF, DKIM, and DMARC specifications to clarify handling of internationalized mail because a domain can appear in both U-label and A-label form. (rfc-editor.org)

Assume the public-facing domain is:

bücher.example

and its A-label is:

xn--bcher-kva.example

SPF example

A typical SPF TXT record might be published at the zone apex:

xn--bcher-kva.example. IN TXT "v=spf1 include:spf.your-mail-provider.example -all"

In most hosted DNS interfaces, you would enter the record name as @ for the apex, not the full domain. The actual provider include mechanism varies, so use the exact include value supplied by your sending provider rather than copying the placeholder above.

Important details:

1. The DNS record owner resolves under the A-label domain.
2. SPF mechanisms that contain domain names should use ASCII-compatible domain names.
3. Publish only one SPF record at a given name. Multiple TXT strings can form one record, but multiple independent v=spf1 records create a permanent SPF error.
4. An SPF pass alone does not guarantee visible-From alignment for DMARC.

DKIM example

DKIM records are published at a selector below _domainkey. If your selector is s1, the DNS owner name is:

s1._domainkey.xn--bcher-kva.example. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

Your email service signs messages with a DKIM domain identifier, commonly represented in the d= tag of the DKIM-Signature header. Use the A-label form unless the signing system explicitly documents standards-compliant IDN handling and exposes the canonical domain it actually signs with.

A valid-looking record is not enough. Confirm that:

• the selector in the DNS record exactly matches the selector in the signature;
• the d= domain is the intended A-label domain or an aligned subdomain;
• the public key is complete and has not been truncated by the DNS provider;
• no unwanted quote characters, line breaks, or copied UI formatting have been added;
• the message signature verifies at the recipient.

DMARC example

DMARC lives under _dmarc:

_dmarc.xn--bcher-kva.example. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@xn--bcher-kva.example; adkim=s; aspf=s"

Start with p=none while you observe reports and validate legitimate streams. Moving to p=quarantine or p=reject before every sender is authenticated can cause real mail to be filtered or rejected.

The example uses strict alignment (adkim=s; aspf=s) to demonstrate that exact domain matching is possible. It is not universally the right first configuration. Relaxed alignment can be appropriate when you deliberately send from subdomains or use a separately delegated return-path domain.

Custom return-path and bounce domains

Many transactional providers ask you to create a custom MAIL FROM, bounce, or return-path subdomain. With an IDN parent domain, the DNS name still needs its A-label form.

For example, if the desired subdomain is visually described as:

bounce.bücher.example

the infrastructure name is:

bounce.xn--bcher-kva.example

A provider may request a CNAME, MX, TXT, or a combination of records. Do not guess at the requested record type, hostname, or destination. Copy the exact values supplied by that provider, while ensuring that the parent IDN is represented as its A-label in the DNS configuration.

Configure sender addresses for APIs and SMTP relays

The same rules apply whether you submit mail through an HTTP API or an SMTP relay.

REST API submissions

An email API usually accepts JSON. JSON strings are Unicode-capable, so an API request can technically contain:

{
  "from": "Bücher Team <billing@bücher.example>",
  "to": ["recipient@example.net"],
  "subject": "Ihre Rechnung"
}

That does not prove the provider can verify, sign, or transmit the address as entered. The service may normalize the domain to an A-label, reject it during sender validation, accept the API request but reject it later during SMTP delivery, or require explicit SMTPUTF8 support for some message forms.

For dependable sending, pass the canonical A-label in the actual mailbox address unless your provider’s documentation specifically confirms U-label input and shows how it canonicalizes the value:

{
  "from": "Bücher Team <billing@xn--bcher-kva.example>",
  "to": ["recipient@example.net"],
  "subject": "Ihre Rechnung"
}

This keeps the routing address ASCII while allowing internationalized content in the display name and subject.

If your application accepts user-entered domains, normalize and validate the domain before creating a sender identity or calling your mail provider. For implementation guidance on sending through a REST API or authenticated SMTP relay, consult the relevant email API reference and setup guides.

SMTP relay submissions

With SMTP submission, the behavior is observable in the SMTP dialogue. An ASCII envelope sender using an A-label is straightforward:

EHLO app.example
MAIL FROM:<billing@xn--bcher-kva.example>
RCPT TO:<recipient@example.net>
DATA
From: Bücher Team <billing@xn--bcher-kva.example>
To: recipient@example.net
Subject: =?UTF-8?B?SWhyZSBSZWNobnVuZw==?=

Message body.
.

The encoded-word form in the example is one valid way to represent a non-ASCII subject in a traditional ASCII header environment. Modern email libraries normally handle this encoding for you. Do not manually encode headers unless you are working directly with raw RFC 5322 messages and understand folding, encoding, and signing consequences.

For a non-ASCII local part, the session needs SMTPUTF8 support and the SMTPUTF8 parameter on MAIL FROM:

EHLO app.example
250-sender.example
250-8BITMIME
250-SMTPUTF8
250 SIZE 52428800
MAIL FROM:<márta@xn--bcher-kva.example> SMTPUTF8

If the submission server does not advertise SMTPUTF8, do not send the UTF-8 envelope address anyway. Choose an ASCII sender alias or route through an explicitly SMTPUTF8-capable system.

Know the errors you may see

Error text is implementation-specific, but the category and status code often tell you where to investigate.

SMTP response codes

SMTP defines reply classes, but providers and recipient servers may choose different messages for the same condition. Common examples include:

Basic SMTP behavior, including reply handling and the SMTP transaction model, is standardized in RFC 5321. SMTPUTF8 adds internationalized-mail behavior on top of that baseline. (rfc-editor.org)

A 553 or 5.6.7 response should not automatically be interpreted as “the domain is invalid.” First determine whether the rejected character is in the domain or in the local part. If the domain is already Punycode-encoded and only the local part is Unicode, the problem is almost certainly EAI support rather than IDNA conversion.

HTTP API status codes

HTTP status codes are less standardized for email validation than SMTP replies. A provider may return:

• 400 Bad Request when the request JSON, address formatting, or field structure is invalid;
• 401 Unauthorized or 403 Forbidden when credentials or account permissions are the real problem;
• 409 Conflict when a sender identity is already present or in an incompatible state;
• 422 Unprocessable Content when the JSON is valid but the sender/domain value fails validation;
• 429 Too Many Requests when you are rate-limited;
• 5xx when the provider cannot process the request temporarily.

Do not build error handling around an assumed universal 422 schema. Instead, log the provider’s request ID, the exact API error code or error field if one is returned, the U-label input, and the canonical A-label used for the actual sending attempt.

Avoid Unicode normalization and lookalike traps

Unicode is not only a delivery problem. It is also an identity and security problem.

Two strings can look identical while using different underlying Unicode code points. A visually similar domain can also use characters from different scripts. For example, Latin a, Cyrillic а, and Greek α are distinct characters despite potentially similar rendering.

Normalize input without rewriting identity carelessly

When accepting an internationalized domain from a user:

1. Trim surrounding whitespace.
2. Separate the domain from the local part before applying domain logic.
3. Apply an IDNA2008-capable library to validate and convert the domain to an A-label.
4. Reject conversion failures rather than silently replacing unsupported characters.
5. Store the canonical A-label for infrastructure matching.
6. Retain the submitted U-label separately when it is needed for presentation or audit context.

Do not lowercase, normalize, or rewrite the local part as if it were a domain. Local-part comparison rules are mailbox-provider-specific, and Unicode local parts introduce additional normalization concerns. Treat a non-ASCII local part as an EAI address, not as a Punycode candidate.

Protect users from homograph confusion

A domain can be technically valid and still be a poor choice for transactional email if recipients cannot reliably recognize it. Mixed-script domains, ambiguous characters, and lookalikes can reduce trust, increase phishing suspicion, and create support burden.

Before using an IDN as the visible sender identity, ask:

• Will customers recognize it in their mail client’s sender view?
• Does it look confusingly similar to another well-known domain?
• Does the sender display name clearly identify the organization?
• Does the same A-label appear consistently in authentication results and raw headers?
• Can your support team explain the Punycode form when a recipient sees it?

A localized domain can be appropriate for a local market. It is not automatically the best choice for system notices, password resets, receipts, or high-risk security mail where instant recognition is more valuable than brand localization.

Test the DNS, authentication, and actual inbox result

IDN mail configuration needs more than a DNS lookup. A domain can resolve correctly and still fail sender verification, DKIM signing, DMARC alignment, or recipient display.

DNS checks

Use a DNS tool such as MXToolbox, dig, nslookup, or your DNS provider’s authoritative record viewer to inspect the A-label version of every record.

Examples:

dig TXT xn--bcher-kva.example +short
dig TXT s1._domainkey.xn--bcher-kva.example +short
dig TXT _dmarc.xn--bcher-kva.example +short
dig MX xn--bcher-kva.example +short

Check the result against the exact expected value. DNS caching means changes can take time to become visible, but a mismatch in the authoritative zone will not be fixed by waiting.

Authentication and content checks

Send a real message to a mailbox you control and inspect the full source. Look for:

spf=pass
dkim=pass
dmarc=pass

Also verify which domain each authentication result reports. A DKIM pass for an unrelated provider-owned domain might not align with the visible From domain for DMARC purposes.

Mail-tester.com can be useful for a practical message review, including common authentication and content signals. It is a diagnostic aid, not a guarantee that every recipient will place mail in the inbox. Test across several destinations, especially if you send password resets, receipts, or other mail where delivery reliability is critical.

Test cases worth running

At minimum, create a test matrix with these cases:

1. ASCII local part + A-label sender domain.
2. Unicode display name + ASCII local part + A-label sender domain.
3. Unicode subject and message body.
4. Recipient addresses at several major mailbox providers.
5. A Unicode local-part sender, only if your business truly requires EAI.
6. A Unicode local-part recipient, only if your sending system and test mailbox explicitly support SMTPUTF8.
7. Forwarding scenarios, because a forwarder can expose compatibility and alignment problems that direct delivery does not.

Keep the raw SMTP/API response, final message headers, and authentication results for each test. This is much more useful than a screenshot of a provider dashboard when troubleshooting a production issue.

Choose between an IDN domain, a subdomain, or an ASCII sender domain

There is no universal answer. The right choice depends on the audience, the type of email, and your tolerance for interoperability risk.

Use an IDN sender domain when

• the domain is central to your public brand in a specific language or market;
• users already recognize the localized spelling;
• you can configure and monitor SPF, DKIM, and DMARC correctly on the A-label;
• your sender local parts can remain ASCII;
• your support and security teams are prepared to explain the Punycode form.

Prefer an ASCII sender domain when

• you send security-sensitive mail such as account recovery or payment alerts;
• recipients span many regions and scripts;
• a visually unfamiliar Punycode representation could create distrust;
• older enterprise systems, allowlists, or integrations are important;
• you cannot fully test the path from submission to recipient inbox.

Consider a dedicated transactional subdomain

A dedicated subdomain can separate operational mail from marketing and other streams. For an IDN parent domain, that subdomain still uses the A-label in DNS:

notify.xn--bcher-kva.example

This makes reputation management, DMARC reporting, and stream separation easier. It also limits the blast radius if a third-party service is misconfigured. The trade-off is that customers may see a sender domain different from the main website domain, so use a clear display name and consistent brand language.

If you are evaluating volume, authentication features, and cost before separating streams, review transactional email pricing alongside the technical requirements.

Operational checklist for reliable sending

Before production rollout, verify all of the following:

• Your visible U-label has been converted with an IDNA2008-capable implementation.
• The canonical A-label is stored and used for DNS and infrastructure configuration.
• SPF is published once at the correct A-label domain.
• DKIM selector records resolve below _domainkey on the A-label domain.
• DKIM signatures use the intended aligned domain.
• DMARC is published at _dmarc on the A-label domain.
• The visible From domain aligns with SPF and/or DKIM under your DMARC policy.
• Your envelope sender uses an ASCII local part unless SMTPUTF8 is intentionally required.
• Your application does not Punycode the local part of an email address.
• API and SMTP logs preserve the original input and canonicalized domain separately.
• You have tested message headers at real recipient mailboxes.
• You have a fallback ASCII sender address for workflows that cannot tolerate EAI failures.

The practical conclusion

Sending from a domain containing UTF-8 or non-ASCII characters is primarily an IDNA and DNS-normalization task, not automatically an SMTPUTF8 task. Convert the domain from its human-readable U-label to its A-label/Punycode form, publish and query DNS authentication records using that canonical ASCII representation, and use it consistently in your sending configuration.

The complexity increases sharply when the local part contains non-ASCII characters. A sender such as márta@… cannot be made ASCII through Punycode and requires SMTPUTF8 support from the submitting system and every relevant delivery hop. Unless that capability is a product requirement, use an ASCII local part, a localized display name, and the A-label version of the internationalized domain for the most reliable transactional-email setup.

FAQ

Can I send from support@bücher.example?

Usually, yes—but configure the actual sending domain as support@xn--bcher-kva.example unless your email provider explicitly accepts and correctly normalizes the U-label. Publish SPF, DKIM, and DMARC records under xn--bcher-kva.example.

Do I need SMTPUTF8 for a Punycode domain?

No. If the local part is ASCII and the domain is converted to an A-label, the envelope address is ASCII. SMTPUTF8 is needed for non-ASCII local parts or other SMTPUTF8-specific internationalized message requirements.

Can I Punycode the part before the @?

No. Punycode/IDNA applies to domain labels, not email local parts. márta@xn--bcher-kva.example remains an internationalized email address and requires SMTPUTF8 support.

Why does the recipient see xn--... instead of my Unicode domain?

Some mail clients, security tools, and gateways intentionally display the ASCII A-label to reduce phishing and homograph risk. This is normal behavior and a reason to use a recognizable display name and test real recipient experiences.

Which DNS records need the A-label form?

Use the A-label for SPF, DKIM, DMARC, MX, custom return-path, CNAME, and other DNS-related records or hostnames. Treat the U-label as the human-facing form and the A-label as the infrastructure-facing form.