Can punycode-encoded email addresses clash with "real" addresses?

Non-ASCII characters are not allowed in the local part of email addresses. Period. Punycode is ONLY FOR DOMAINS, not for local parts of email addresses.

However, it is very likely that the IETF adopts a standard that makes internationalized local parts possible. This standard, however, will probably not be based on punycode.

You can encode sections of mail header fields into different character encodings using a format like the following: =?UTF-8?B?w6HDq8O0?= This allows you to embed things like umlauts but I'm pretty sure it doesn't work for the actual address part.

There's not reason why you cannot use these characters to form your address. RFC5322 defines the characters that may appear in the address part in Section 3.4 and all the characters you use above are valid. However as the other comment added it's all a little fruitless if the mail clients that you are sending to cannot parse this format.

Some SMTP servers might 'accidentally' allow umlauts but since they're not within the supported character ranges I wouldn't risk it.

I got bored and was researching this tonight, and apparently this is now codified in the Extended SMTP standard, specifically SMTPUTF8 as per RFC 6531. See http://en.wikipedia.org/wiki/Extended_SMTP#SMTPUTF8

My brief experiment using emoji mailbox names returned the following error when sending via Gmail:

local-part of envelope contains utf8 but remote server did not offer SMTPUTF8

This is the same regardless whether I used the emoji or punycode version of the address.

The only standard way to send non us-ascii characters in the local-part of a email address is through rfc6532 (Internationalized email headers) and rfc6531 (SMTP Extension for SMTPUTF8).

As far as I know there is no standard way to encode non us-ascii chars in a local part of a email address notably:

• Puny code is for domain names only, not the local part. But you can have a local part which happens to look like the puny encoding of some string but it should be displayed in it's puny encoded form. If a mail program decides to display it after puny decoding it it's non standard behavior.

• The encoded word encoding mechanism mentioned in one of the answers (the =?utf-8?Q?foobar?= thing) is not applicable to the local part of a mail address, only to the display name of a mailbox (which is something different, but related i.e. the thing your mail program might display instead of the mail address).

In the end this means that mü[email protected] and [email protected] are two completely unrelated email addresses which just would have the same meaning if they would have been domains (but they are not so they can collide).

Theoretically you could hope that by now (2019) all mail servers support SMTPUTF8 and all client support internationalized mails, but sadly I would not count on it if it's important.

Btw. it happens that the local part of a email address is the only thing in the mail standard(s) where you might want to have non us-ascii chars and there is no way to encode it (as far as I know). All other parts either have encoded word, puny, percent, base64, quoted-printable or some other form of encoding mechanism.