SMTP error 5.6.7 Non-ASCII addresses not permitted for that sender/recipient

What SMTP error 5.6.7 means

An address in the transaction contains characters outside plain ASCII and the receiving server does not support internationalised email. The command is refused at the MAIL FROM or RCPT TO stage, before the message body is ever offered, as 553 5.6.7 or 550 5.6.7. In UK business mail this is uncommon, and when it does appear it is usually a European or Asian correspondent whose address uses accented or non-Latin characters.

Message content or media status
Sent by The receiving server, refusing a MAIL or RCPT command that carried a non-ASCII address
Rare

What SMTP error 5.6.7 Non-ASCII addresses not permitted for that sender/recipient actually means

SMTPUTF8, defined in RFC 6531, allows both halves of an address to be written in UTF-8 so that people can have addresses in their own script. Support across the internet remains patchy. A sending system that supports the extension will not hand such an address to a server that has not advertised it, and a receiving server that does not support it refuses the command outright, which is what this code reports. Domains written in non-Latin scripts have a workaround in punycode, which encodes the domain part into ASCII, but there is no equivalent trick for the local part before the at sign. That is where this normally bites. It is registered in the permanent form only, so the transaction ends there.

This indicates the reception of a MAIL or RCPT command that non-ASCII addresses are not permitted
— RFC 6531

How 5.6.7 appears in a bounce

A server reporting this condition sends it alongside a three-digit reply code, and a bounce prints the two together. The registry lists these pairings for this status: 553 5.6.7, 550 5.6.7. Which one you get depends on the point in the conversation at which the server refused.

The leading 5 is the server's verdict rather than part of the code's identity: it marks this as a permanent failure, which means the sending server has given up and returned the message.

What causes SMTP error 5.6.7 on a business phone system

A correspondent whose local part uses accentsCommon in France, Germany, Spain and the Nordics where a surname is used as the mailbox name. The address is entirely valid at their end and unusable by any hop in your path that predates the extension.
An older on-premise server or appliance in the chainOne hop without SMTPUTF8 is enough to stop the whole transaction. A legacy relay, an archiving bridge or an ageing security appliance is the usual culprit, not the mail platform at either end.
An internationalised domain entered in its native scriptThe domain half has an ASCII representation and something in the path has to perform the conversion. Where an address is typed or pasted in native characters and no conversion happens, the command goes out as UTF-8 and is refused.
An application building addresses out of a name fieldLine-of-business software that assembles an address from customer records will happily carry an accented character straight through from the name into the local part. The record looks correct on screen and cannot be delivered to.
A gateway that accepts UTF-8 inbound and cannot relay itSupporting the extension on the way in is not the same as supporting it on the way out. A gateway can take the message from you and then find it has nowhere compliant to pass it to.

How to fix SMTP error 5.6.7

Ask the contact for an ASCII form of their addressNearly everyone with an internationalised address also holds a plain one, because they have run into this before. One question resolves it faster than any amount of infrastructure work.
Convert the domain half to punycodeAn internationalised domain has an equivalent form beginning xn-- that every mail server understands. This fixes addresses where only the domain is non-ASCII and does nothing for the local part.
Test each hop rather than the endpointsConnect to your outbound relay and check whether SMTPUTF8 appears in the extensions it advertises, then do the same for anything downstream you control. The weakest link decides the outcome.
Normalise addresses generated by applicationsStrip or transliterate accents when an address is derived from a name field, and validate before sending. An address is not a display name and should not inherit the characters of one.
Route regular international correspondence through a platform that supports itThe major hosted platforms handle SMTPUTF8. If you trade with countries where these addresses are common, removing the legacy relay from the outbound path is a better answer than working around each contact.

Fixing the underlying problem

This page explains the code. These guides walk through the fix in detail.

Questions about SMTP error 5.6.7

Our contact has an accent in their display name. Is that the same problem?

No, and the distinction matters. Display names have been able to carry any character for decades through MIME encoding, so a name shown as Müller is perfectly safe. This code concerns the address itself, the part that actually travels in the SMTP commands.

Will punycode solve an accented mailbox name?

Only the domain half. Punycode is defined for domain names, so it converts everything to the right of the at sign and leaves the local part untouched. If the accent is in the mailbox name, you need SMTPUTF8 support end to end or a different address.

Is this worth doing anything about?

Only if you trade with countries where these addresses are in regular use. For a business corresponding entirely within the UK it will appear once every few years and can be handled case by case rather than by changing infrastructure.

Related SMTP status codes

Source. SMTP error 5.6.7 Non-ASCII addresses not permitted for that sender/recipient is defined in RFC 6531 and registered in the IANA SMTP Enhanced Status Codes registry. The causes and fixes above are drawn from our own experience supporting UK business email systems.

All Email delivery & SMTP codes