4

I recently tried to send an email to a colleague, and received the following error:

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

Many posts suggest that you avoid the UTF8 option in Gmail. This option, however, seems no longer to exist in either the Inbox interface or the "old" Gmail interface.

Furthermore, using the plain-text option, doesn't seem to change anything either. This post has tried to raise the same issue in the past but got closed.

Further details - the mail itself contains no attachments, "special" characters or anything that should require out of the way encoding.

Edit: Based on @pnuts comment, it is important to note that the address contains a - symbol. It seems like sometimes this is a problem, but there must be a way around it. I mean, it is this guy's email.

0

4 Answers 4

1
+50

Short answer

If you need to send your message now, try a different email service to send it.

Explanation

Here is a thread from 2017 on the Official Gmail Help Forum UTF-8 Message not delivered. Unfortunately, it doesn't include a workaround, just several replies from Nina - Community Specialist, who have the Expert - Google Products badge, saying:

Hi ______

Welcome to the Gmail Help Forum!

I'm continuing to work with my team on this issue. Shall keep you posted on the update.

I'd appreciate your patience.

Best, Nina

The last reply has the above text and was sent on 11/20/17

3

I just found this question after having a similar issue. It turns out the issue was on my side, as the - I copied in the e-mail address wasn't actually a dash, but a (a unicode hyphen, \u2010)

If anyone is having a similar issue I suggest trying to re-type the e-mail address instead of copying it.

2

Gmail will happily accept recipient addresses containing UTF8 characters and try to send mails to the recipients, but the receiving mailserver may not support recipient addresses containing UTF8 'special characters' such as 'æøåüäèá' (and many more).

There is a surprisingly high number of receiving mailservers 'out there' that does not accept recipient addresses containing UTF8 characters. The administrators of those outdated mailservers really should try to do a better job.

Many mail-clients will automatically convert from UTF8 to 'something else' without even letting the user know about the conversion, so most people will not encounter these widespread mailserver inadequacies. As a consequence this type of challenge will probably take 20 more years to fix entirely (in addition to the already elapsed ~20 or so years that UTF8 has already been in use).

I blame the mail clients that automatically convert from UTF8 to 'something else', thereby hiding the mailserver-inadequacies. I do not blame Google/Gmail who, in my opinion, is actually doing the right thing!

If everyone would make the effort to follow the latest/current standards, this type of challenge would have been extinguished completely several decades ago - without the need for silly semi-permanent backward compatibility workarounds!

Just saying ;-)

0

I found our hybrid 365 remote domain was defaulted to iso-8859-1. Changing it to UTF-8 under Mail Flow / Remote Domains resolved the issue we were having:

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

1

Not the answer you're looking for? Browse other questions tagged or ask your own question.