When can you encode email addresses using RFC 2047?
Published 2 Jun 2025
Updated 12 Aug 2026
10 min read
Summarize with
Updated on 12 Aug 2026: We updated this guide with exact encoded-word limits, MIME parameter guidance, and current SMTPUTF8 distinctions.
You can use RFC 2047 to encode the human-readable text around an email address, not the email address itself. In a From, To, or Cc header, the display name can be encoded. The actual mailbox, the addr-spec, must remain parseable as normal address syntax.
That means a fully encoded From value that decodes to a display name plus angle-bracket address is invalid for real delivery. Some receivers accept it because they decode too early or repair the header. Gmail rejects it because it parses the header as a structured address field and does not find a valid mailbox.
A simple rule works: RFC 2047 is for text a person reads. It is not for syntax the mail system must route, authenticate, or compare. When the parser needs punctuation such as @, <, >, commas, or header-specific delimiters, do not hide those characters inside an encoded-word.
The direct rule
The exact answer is short: encode the display phrase, comments, and unstructured header text. Do not encode the mailbox address. RFC 2047 Section 5 lists the only places an encoded-word is allowed, then says it must not appear in any portion of an addr-spec. RFC 2047 applies to message header field bodies, not the SMTP envelope commands MAIL FROM and RCPT TO.
If a header has to be parsed as a mailbox, keep the mailbox in normal address syntax. Encode only the words that form the friendly name or a parenthesized comment.
- Allowed: The display name before an address in From, To, or Cc.
- Allowed: Text fields such as Subject and Comments.
- Allowed: A parenthesized comment inside a structured header.
- Not allowed: The local part, domain, angle brackets, or the whole mailbox.
|
|
|
|---|---|---|
Subject | Allowed | Header text |
Display name | Allowed | Friendly From |
Comment | Allowed | Human note |
Mailbox | Not allowed | Address syntax |
Trace fields | Not allowed | Routing data |
Compact view of common header locations.
Why the whole From header fails
A From header is not one flat text string. It is a structured field. RFC 5322 address syntax separates the display phrase from the mailbox. The phrase is human-readable. The mailbox is operational syntax. RFC 2047 can replace words inside the phrase, but it cannot replace the mailbox grammar.
Invalid full-header encodingtext
From: =?UTF-8?Q?Dmytro_Homoniuk_=3Cdmytro@example.com=3E?=
That line looks attractive because a decoder can render it as a familiar display name plus angle-bracket address. The problem is that the structured-field parser does not receive a syntactic mailbox. It receives one encoded-word in a phrase position. RFC 2047 decoding happens for display after the field has been parsed, so the decoded angle brackets do not become address grammar.
Valid display-name encodingtext
From: =?UTF-8?Q?Dmytro_Homoniuk?= <dmytro@example.com>
Invalid pattern
- Hidden address: The mailbox exists only after RFC 2047 decoding.
- Parser risk: The header has no visible addr-spec for strict receivers.
- Security risk: Encoded text can hide lookalike characters in the address.
Valid pattern
- Visible address: The mailbox remains plain and parseable.
- Encoded name: Only the friendly display phrase uses encoded-words.
- Valid structure: Strict mailbox providers can parse the sender cleanly.
Where RFC 2047 works
RFC 2047 works when the field location accepts human-readable text. Subject, Comments, a display name, Content-Description, and certain extension fields can carry non-ASCII text through ASCII-only mail paths by converting it to encoded-words.
Flowchart of RFC 2047 encoded-word placement in email headers.
The same rule explains why encoded List-Unsubscribe headers break. List-Unsubscribe is structured. It expects mailto and web URI values inside angle brackets, not a single decoded text blob. If the URI is hidden inside an encoded-word, the unsubscribe mechanism can fail even when a mail client shows a readable value.
Valid RFC 2047 placementstext
Subject: =?UTF-8?Q?Shipping_update?= Comments: =?UTF-8?Q?Internal_note?= From: =?UTF-8?Q?Support_team?= <support@example.com> To: =?UTF-8?Q?Finance_team?= <finance@example.com>
Invalid List-Unsubscribe encodingtext
List-Unsubscribe: =?UTF-8?Q?<mailto:unsubscribe@example.com>?=
Valid List-Unsubscribe syntaxtext
List-Unsubscribe: <mailto:unsubscribe@example.com>, <https://example.com/unsubscribe/abc123>
RFC 2047 also does not belong in Content-Type or Content-Disposition parameter values. Use RFC 2231 parameter encoding for a non-ASCII filename or name value, keeping the structured parameter syntax visible.
Valid non-ASCII filename parametertext
Content-Disposition: attachment; filename*=UTF-8''R%C3%A9sum%C3%A9.pdf
How an encoded-word is built
An encoded-word has four parts inside an ASCII wrapper: the charset, encoding marker, encoded text, and delimiters. The complete token must be recognizable before a mail client decodes it.
Encoded-word structuretext
=?charset?encoding?encoded-text?= From: =?UTF-8?Q?Ren=C3=A9_Dupont?= <rene@example.com>
- Charset: Use UTF-8 for new output unless a required legacy system dictates another registered charset.
- B encoding: Base64 is compact when the source text contains many non-ASCII bytes.
- Q encoding: This header-specific variant uses hexadecimal escapes and an underscore for a displayed space.
- Length: The entire encoded-word, including charset and delimiters, must not exceed 75 characters.
B and Q change only how display text becomes ASCII-safe. Neither encoding makes a mailbox, URI, MIME parameter, or other structured token valid inside an encoded-word. Encode source text once to avoid double-encoded output.
Length, folding, and spacing rules
Placement comes first, then token construction. Each encoded-word has a 75-character maximum. Longer display text must be split into complete encoded-words, and a split must never divide one encoded-word, encoded octet, or multibyte character. When adjacent encoded-words are separated only by linear white space, a decoder ignores that white space when displaying the result.
The formatting rules matter because receivers parse these headers before they render them for a person.
- Placement first: Decide whether the token is display text or structured syntax.
- 75-character limit: Count the charset, encoding marker, payload, and delimiters.
- Folding: Fold between complete encoded-words, never inside one token or character.
- Spacing: Separate encoded-words and adjacent text with linear white space.
Folded display nametext
From: =?UTF-8?Q?Long_display_name_part_one?= =?UTF-8?Q?_part_two?= <sender@example.com>
Avoid mixing encoded and unencoded display-name fragments unless there is a clear requirement. It is valid when separated correctly, but the simpler production pattern is a fully encoded display phrase followed by a plain mailbox.
Non-ASCII mailboxes are different
There is a separate question that gets mixed into this one: can the actual email address contain non-ASCII characters? Yes, but RFC 2047 is still the wrong mechanism. RFC 6531 and RFC 6532 allow internationalized mailbox and header syntax when the SMTP path supports SMTPUTF8. 8BITMIME alone is not enough. When the local part stays ASCII, an internationalized domain can use its IDNA A-label form to keep the addr-spec ASCII.
Address encoding decision points
Use this to decide whether RFC 2047 belongs in the header.
Display text
RFC 2047 OK
Names, comments, and unstructured text fields.
ASCII mailbox
Plain syntax
The normal local part and domain used for routing.
International mailbox
Separate path
A non-ASCII local part needs SMTPUTF8 support.
Encoded mailbox
Invalid
An addr-spec hidden inside an encoded-word.
This distinction matters for Gmail bounces and authentication reviews. A syntactically visible From address gives the receiver a stable identifier to parse, compare, and authenticate. A hidden address forces the receiver to guess whether decoding should happen before address parsing, and strict systems reject that ambiguity.
If Gmail reports a malformed sender, check RFC 5322 formatting before reviewing reputation. Syntax failures happen before normal deliverability scoring has much room to help.
How to test before sending
Send the exact MIME message through the same system that sends production mail. Do not rely only on what a mail client displays after decoding. View-source displays can normalize, decode, or hide the problem that the receiving server saw during SMTP acceptance.
Suped's email tester is part of Suped's email authentication product. It accepts a real message and shows authentication and message-quality checks in one place, which helps catch malformed From headers and related header or body issues before a campaign reaches recipients.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
For ongoing sending, Suped's DMARC and email authentication product connects message testing with DMARC monitoring, SPF and DKIM visibility, hosted policy controls, real-time alerts, and blocklist (blacklist) monitoring. The product does not rewrite RFC 2047 headers. It keeps message-quality findings beside the authentication and reputation data used during an investigation.
That workflow keeps acceptance errors separate from authentication errors. If the message is rejected during SMTP because the From header is malformed, fix syntax first. If syntax passes, then review SPF, DKIM, DMARC policy, bounce patterns, and reputation signals.
Email tester sample report showing total score, email preview, issue summary, and per-section results
Check the sending domain with a broader domain health checker when a header fix is part of a wider deliverability review. A malformed From header can sit beside SPF lookup problems, missing DKIM records, DMARC reporting gaps, or blacklist and blocklist entries. Treat those as separate findings, then fix them in order of delivery impact.
A practical debugging checklist
When Gmail accepts the display-name version and rejects the fully encoded version, the fix is not to tune Base64 or switch to Q encoding. Move the mailbox out of the encoded-word and keep it visible to the address parser.
- Check From: Confirm the display phrase and mailbox are separate tokens.
- Check addr-spec: Keep the local part, at sign, and domain outside RFC 2047.
- Check folding: Fold long encoded display names between complete encoded-words.
- Check structured fields: Do not RFC 2047 encode List-Unsubscribe, Received, or MIME parameters.
- Check Gmail: Test with the same source message that the sender submits.
A mailbox provider that accepts a fully encoded From value is being forgiving. The header should still be changed. Once a major receiver rejects a malformed header, the operational answer is to make the header unambiguously valid.
This also connects to Gmail abnormal characters problems. If the visible sender identity contains unusual Unicode, validate whether the character is in the display name, the actual address, or both. The display name has more room for encoded text. The address has stricter rules.
Views from the trenches
Best practices
Keep the mailbox as plain addr-spec and encode only the display phrase in address headers.
Decode for display only; parse headers against RFC 5322 before rendering friendly names.
Test Gmail acceptance with the exact MIME source, not the decoded view shown by a client.
Common pitfalls
Encoding the whole From value hides angle brackets inside an encoded-word and breaks parsing.
Encoding List-Unsubscribe creates a header that can look readable yet fail structured syntax.
Assuming one provider acceptance proves compliance can cause later Gmail bounces.
Expert tips
Use Q encoding for mostly ASCII names and B encoding for names with many non-ASCII bytes.
Fold long encoded display names between encoded-words, keeping each encoded-word complete.
Separate each encoded-word from adjacent text with linear white space in the header.
Expert from Email Geeks says RFC 2047 is only for human-readable parts such as Subject, comments, and the phrase before a mailbox.
2024-03-08 - Email Geeks
Expert from Email Geeks says the actual email address cannot be encoded, even when some software accepts it after early decoding.
2024-03-08 - Email Geeks
The production rule
Treat RFC 2047 as a display-text encoder. It belongs in a Subject, a friendly From name, a friendly To name, or a comment. It does not belong inside the actual address, a List-Unsubscribe URI, a Received field, or a MIME parameter.
For the original pattern, Gmail is rejecting the message for a valid reason. The compliant version encodes the friendly name and leaves the mailbox plain. That is the form to ship, document, and test across mailbox providers.
Production-safe From patterntext
From: =?UTF-8?B?RG15dHJvIEhvbW9uaXVr?= <dmytro@example.com>
