When can you encode email addresses using RFC 2047?
Published 2 Jun 2025
Updated 21 Oct 2026
11 min read
Summarize with
Updated on 21 Oct 2026: We clarified RFC 2047 display-name rules and corrected the header testing advice.
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. A receiver that decodes or repairs the value before parsing can accept it, but acceptance does not make it valid. Gmail rejects messages without a valid From address, so keep the mailbox outside the encoded-word.
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.
Where RFC 2047 encoded-words are allowed
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 where the field grammar permits one.
- Allowed: The display name before an address in From, To, or Cc.
- Allowed: Text fields such as Subject and Comments.
- Allowed: A parenthesized comment where the structured field permits it, except in Received.
- Not allowed: Any part of the mailbox, a quoted-string, or a whole structured field value.
|
|
|
|---|---|---|
Subject | Allowed | Header text |
Display name | Allowed | Friendly name outside a quoted-string |
Comment | Allowed with exceptions | Where comments are permitted, except in Received |
Mailbox | Not allowed | Address syntax |
Received | Not allowed | Trace and routing information |
Common header locations for RFC 2047 encoded-words.
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>
Do not wrap an encoded-word in double quotes. RFC 2047 Section 5 forbids encoded-words inside a quoted-string, including a quoted display name. A plain ASCII name such as "Doe, Jane" can use quotes; an encoded-word must sit outside them.
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: Decoded display text can resemble an address different from the actual mailbox.
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:_caf=C3=A9?= Comments: =?UTF-8?Q?R=C3=A9sum=C3=A9_review?= From: =?UTF-8?Q?=C3=89quipe_support?= <support@example.com> To: =?UTF-8?Q?=C3=89quipe_finance?= <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. It differs from quoted-printable body encoding.
- Length: The entire encoded-word, including charset and delimiters, must not exceed 75 characters.
In a Q-encoded display name, use =5F for a literal underscore, =3F for a question mark, and =3D for an equals sign. Encode commas as =2C; punctuation allowed literally in Subject is not always allowed in a display phrase. These context-specific restrictions are in RFC 2047 Section 5.
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. Plain ASCII display names usually need no encoded-word.
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. RFC 2047 Section 2 also limits each header line containing an encoded-word to 76 characters, excluding CRLF.
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: Use CRLF followed by space or tab 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 for a non-ASCII display name is an encoded display phrase followed by a visible mailbox. Use a mail library with structured address support to handle encoding and folding.
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.
For messages using RFC 6532, header values can contain UTF-8 directly. Section 3.6 recommends direct UTF-8 instead of encoded-words for that format. SMTP transport still requires SMTPUTF8, even if the mailbox itself is ASCII. Use RFC 2047 for non-ASCII display text when keeping headers compatible with ASCII-only transport.
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 leaves the structured field without a valid mailbox; decoding the display text does not repair that syntax.
If Gmail reports a malformed sender, check RFC 5322 formatting before reviewing reputation. A good reputation does not repair invalid address syntax.
RFC 2047 versus URL encoding
An email address passed as an HTTP query parameter needs URL encoding for that context. Use a query-parameter serializer rather than RFC 2047 or an encoder for an entire URI. A literal percent sign becomes %25; encode a plus sign as %2B so form-style query decoding preserves it. Percent-encoding is defined in RFC 3986.
The same address in a header and query parametertext
To: <sales+eu%ops@example.com> HTTP query parameter: email=sales%2Beu%25ops%40example.com
Decode the query parameter before using its value as a mailbox. The address in the email header retains its literal plus and percent characters; URL escapes are for the HTTP request. The API must decode the parameter according to its own request format.
How to test before sending
Send the exact MIME message through the same system that sends production mail. Inspect the raw message source or downloaded .eml file, not only the sender name rendered by the mail client. Preserve the SMTP response and submitted message when investigating a rejection.
Suped's email tester is part of Suped's email authentication product. Send a real message to its unique test address through your normal sending system, then review authentication results and message checks. Compare the original From header with the examples above. A successful test delivery to Suped does not establish Gmail acceptance.
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 monitoring shows authentication results reported by receiving providers. Use it to investigate sending sources and authentication failures after fixing header syntax. DMARC reports do not contain the complete raw From header and cannot establish whether its RFC 2047 encoding is valid.
If the message never reaches the tester, inspect the sending system's SMTP logs or bounce response. Fix malformed header syntax before investigating separate authentication failures. Gmail's SMTP error documentation lists 550 5.7.1 responses for invalid From addresses and encoded-words in disallowed header locations; the full response identifies the failure.
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 blocklist (blacklist) 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; do not put an encoded-word inside double quotes.
- 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.
Acceptance by one mailbox provider does not make a fully encoded From value valid. Keep the display name separate and the mailbox directly parseable, then retest the corrected message.
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 acceptance by one provider proves compliance can cause later Gmail delivery failures.
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 view
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 view
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
A valid From header for production
For an ASCII-compatible message with a non-ASCII display name, encode the display name once, then append the mailbox outside the encoded-word with a separating space.
From header with a Base64-encoded display nametext
From: =?UTF-8?B?UmVuw6kgRHVwb250?= <rene@example.com>
