When can you encode email addresses using RFC 2047?

Email marketer from Email Marketing Forum responds that if you want to encode a name with special characters in the from field, use RFC 2047 encoding for the name portion, leaving the email address itself in ASCII.

Email marketer from Campaign Monitor shares that encode the header fields, particularly the display name, according to RFC 2047 to ensure international characters display correctly in different email clients. However, the actual email address component should remain in standard ASCII.

Email marketer from Reddit shares that RFC 2047 encoding is used for the display name/friendly name portion of the from and to headers, allowing for special characters. The actual email address cannot be encoded this way.

Email marketer from SuperOffice shares that if you need to send an email with international characters, focus on encoding the display name correctly using RFC 2047. The actual email address part must remain as standard ASCII.

Email marketer from GMass supports that you can use special characters in the Display From Name, but the email address itself should be a valid ASCII email address.

Email marketer from Email Marketing Tips Blog states that RFC 2047 encoding is primarily for encoding the 'display name' part of an email address, not the actual email address itself. The address part must remain in US-ASCII.

Email marketer from Litmus responds that it's crucial to encode the appropriate parts of the email header when dealing with special characters. Specifically, the display name in the From and To fields, should be encoded using RFC 2047 methods to ensure proper rendering across email clients; the actual email address must remain in ASCII.

Email marketer from Email Geeks shares that encoded email addresses are pretty widely seen as a security risk because it lets you hide malicious addresses that look like legitimate ones.

Email marketer from Mailjet responds that when using special characters, encode the header (especially the display name), using RFC 2047 methods for handling non-ASCII characters. The email address itself must remain in ASCII format.

Email marketer from Stack Overflow responds that RFC 2047 encoding should only be applied to the display name (the text part) of the email address, not the actual address itself. They provide an example of how the encoded display name should look.

Expert from Word to the Wise mentions that RFC 2047 encoding in List-Unsubscribe headers is invalid. RFC 2047 encoding is allowed in the display name part of the From, To, and CC headers, and in the Subject and Comments headers.

Expert from Email Geeks shares RFC 2047 #5, specifying what may be replaced by an encoded word, which is a short list of places you’re allowed to do that - Subject, Comments headers, any parenthesised comment or the phrase preceding an address in From, To, Cc.

Expert from Email Geeks explains that you can only encode the human readable text with RFC 2047, such as the Subject line, and friendly comments in From: and To: headers, but you can’t encode the actual email address. Although it might sometimes work, it’s never valid.

Documentation from Microsoft explains that to display international characters in email headers, you must use MIME encoding (RFC 2047). This encoding is applied to header fields like Subject, From, To, etc. but is primarily intended for the descriptive text, not the email address itself.

Documentation from Word to the Wise explains that RFC 2047 allows encoding of the text part of headers such as Subject, Comments, and certain parts of address fields (From, To, CC), such as the display name, but not the email address itself. It refers to Section 5 of RFC 2047.

Documentation from RFC 5322 (which obsoletes RFC 2822) specifies the Internet Message Format. Within address fields (like From, To), the 'display-name' can be encoded using RFC 2047 to support non-ASCII characters, but the 'addr-spec' (the actual email address) must conform to the ABNF syntax which primarily uses ASCII characters.

Documentation from RFC 2047 specifies that an 'encoded-word' is a technique to represent character data in non-US-ASCII character sets within message header fields. It can be used in specific parts of the message header, such as 'Subject', 'Comments', or in structured header fields like 'From', 'To', and 'Cc', within the comment and phrase portions.