Why is MIME encoding headers in emails invalid and what are the consequences?
Published 20 Apr 2025
Updated 4 Aug 2026
10 min read
Summarize with
Updated on 4 Aug 2026: We clarified RFC 2047 placement and length rules, then corrected the one-click unsubscribe and DKIM guidance.
RFC 2047 MIME encoded-words are invalid when applied to structured email header fields that expect machine-readable syntax. A field like List-Unsubscribe is not free text. It contains angle-bracketed URLs, mailto addresses, commas, and folding positions that parsers need to read exactly. Encoded words such as =?us-ascii?Q?...?= belong only in specific human-readable parts of certain fields, such as Subject text or a display name.
The receiving system does not have to decode an encoded-word where RFC 2047 forbids it before parsing the field. It can ignore the header, fail to recognize one-click unsubscribe, reject a malformed message, or behave differently across Gmail, Yahoo, Microsoft, and filtering gateways. This is a sending platform bug, not a cosmetic warning.
Short answer
If a platform emits List-Unsubscribe, DKIM-Signature, Content-Type, Message-ID, or address syntax as MIME encoded-words, ask the platform to serialize each field according to its grammar. Tolerant receivers do not make the output valid, and a parser change can turn a warning into a delivery or compliance problem.
The direct answer
The invalid part is not header folding. Folding is allowed when each continuation line begins with whitespace and the field grammar permits a break there. The invalid part is replacing the structured value with encoded-word chunks. A parser looking for a URL inside angle brackets sees an encoded-word instead of the required structure.
Invalid List-Unsubscribe headertext
List-Unsubscribe: =?us-ascii?Q?=3Chttps=3A=2F=2Fexample=2Eorg=2Funsub=3Fid=3Dabc?= =?us-ascii?Q?=3E=2C_=3Cmailto=3Aunsubscribe=40example=2Eorg=3E?=
The corrected version keeps the syntax visible to a structured header parser. Long lines can still be folded at a permitted boundary, but the field value remains a normal List-Unsubscribe value.
Valid folded List-Unsubscribe headertext
List-Unsubscribe: <https://example.org/unsub?id=abc>, <mailto:unsubscribe@example.org>
The 78-character line recommendation in RFC 5322 is not an instruction to MIME-encode any header that grows longer. Fold at grammar-allowed whitespace, keep every line within the 998-character hard limit, and remember that an RFC 2047 encoded-word has its own 75-character limit.
- Allowed: Use encoded-words for non-ASCII human text where the field grammar permits them, such as Subject text or a personal display name.
- Invalid: Do not MIME-encode angle brackets, URLs, email addresses, commas, message IDs, DKIM data, MIME boundaries, or other structured tokens.
- Fix: Serialize each header according to its own grammar, then encode only the exact human-readable phrase that is allowed to be encoded.
Why encoded-words do not belong there
MIME was created to carry non-ASCII content and multipart message bodies through email systems that historically expected 7-bit text. RFC 1341 is part of that history, but RFC 2047 defines the narrower encoded-word rules for header fields. Encoded-words are not a general escaping or line-wrapping mechanism.
The important distinction is between human-readable text and protocol syntax. A display name is text. A Subject line is text. A URL inside List-Unsubscribe is syntax. The local part and domain in an address are syntax. A DKIM-Signature header is syntax. Those structured parts must remain visible to the parser.
This is also why RFC 2047 address encoding has to be handled carefully. Encoding the display name in From can be valid. Encoding the address itself as an encoded-word is not.
|
|
|
|---|---|---|
Subject | Encoded text | Malformed word or fold |
From | Display-name phrase | Address syntax |
List-Unsubscribe | Visible URL syntax | Encoded URL |
DKIM-Signature | Raw tag values | Encoded chunks |
Content-Type | Token or quoted value | Encoded-word parameter |
Common header encoding outcomes
Decision flowchart for MIME encoded-words and structured email header syntax.
RFC 2047 rules that matter
RFC 2047 limits encoded-words by both location and length. They can carry non-ASCII text in an unstructured field such as Subject and within a phrase or comment where the field grammar permits it. They cannot appear in an addr-spec, a Received field, a MIME Content-Type or Content-Disposition parameter, or another structured field body outside an allowed phrase or comment.
Each encoded-word, including its delimiters, character set, encoding marker, and encoded text, is limited to 75 printable characters. Longer human-readable text can use multiple self-contained encoded-words separated at legal whitespace. That rule does not authorize a serializer to convert a long ASCII URL or structured field into encoded-word chunks.
SMTPUTF8 is a separate mechanism. RFC 6531 and RFC 6532 permit direct UTF-8 in supported envelope addresses and header field values when SMTP transport negotiates SMTPUTF8. They replaced the experimental RFC 5335 approach. SMTPUTF8 does not make an RFC 2047 encoded-word legal inside a structured token.
Check the encoding layer
- Header display text: Use RFC 2047 encoded-words only where the field grammar permits text, phrases, or comments.
- Structured field: Keep addresses, URLs, identifiers, signature tags, and MIME parameters in their defined syntax.
- Message body: Declare the body charset and content-transfer encoding instead of inserting header encoded-words into body text.
- Internationalized address: Use SMTPUTF8 only when the transport path supports it, not as a repair for malformed RFC 2047 output.
What can break in practice
The most common breakage is that receivers do not recognize the header for its intended purpose. With List-Unsubscribe, an encoded URL can make the mailbox ignore the field. RFC 8058 one-click unsubscribe also requires List-Unsubscribe-Post with the exact value List-Unsubscribe=One-Click, at least one HTTPS URI in List-Unsubscribe, and a valid DKIM signature covering both fields. If the URI is hidden inside encoded-words, the complete one-click setup no longer parses as required.
The mail can still be delivered, which makes the bug easy to dismiss, but the unsubscribe control can disappear and the sender can miss a provider requirement. Receiver behavior is also inconsistent. One provider can decode and accept the field, another can ignore it, and a gateway can make a different decision.
Tolerant receiver
- Decode first: The receiver decodes encoded-words before it tries to parse the structured value.
- Delivery continues: The message reaches the inbox, so the sender assumes the header is fine.
- Risk remains: The behavior is tolerance, not a standards guarantee.
Strict receiver
- Parse first: The receiver expects visible structured syntax in the field value.
- Header ignored: The field fails to match the grammar and loses its intended effect.
- Sender impact: The malformed message becomes an operational delivery or compliance issue.
|
|
|
|---|---|---|
Unsubscribe | Header ignored | Requirement missed |
Filtering | Warning raised | Placement change |
DKIM | Can still pass | False confidence |
Debugging | UI decodes value | Invalid source hidden |
Likely effects of structured header encoding
How to prove the issue
Do not prove this with a rendered inbox view. Webmail interfaces can display a decoded version that hides the invalid wire format. Prove it with the raw message source, the exact header before any UI changes it, and a corrected version that shows the same value without encoded-words.
A practical test is to send the same campaign or transactional message to a controlled inbox and inspect the raw headers. Suped's email tester supports this workflow by checking a real message's header, authentication, and content signals together.
- Raw source: Capture the full message source before any mailbox UI decodes or rewrites display values.
- Header parse: Show that the field body begins with encoded-words instead of the required visible syntax.
- Receiver result: Check whether unsubscribe, filtering, bounce, or placement behavior changes across providers.
- Vendor ticket: Attach the malformed header, the corrected header, and the business risk in one concise request.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
This is also a good moment to check the sending domain, not just the single message. A domain health checker helps separate a header-format bug from broader SPF, DKIM, DMARC, DNS, and reputation problems.
Evidence package
- Original source: Include the full raw header block, not a screenshot of a decoded inbox view.
- Correct sample: Show the same List-Unsubscribe value as normal structured ASCII syntax.
- Receiver notes: Record whether the unsubscribe UI, bounce result, or filtering warning changes.
- Priority: Escalate immediately if the bug affects one-click unsubscribe, authentication, or bulk sender compliance.
What to ask the sending platform to change
The fix is usually in the platform's header serializer. The platform should stop running a generic encoded-word function over every header and instead serialize each field according to that field's grammar. This is not a DNS fix, and changing the DMARC policy does not repair it.
For platform owners, field-specific tests are the safest pattern. A test should fail if List-Unsubscribe contains encoded-word syntax, if List-Unsubscribe-Post differs from its exact RFC 8058 value, if a Message-ID is encoded, if Content-Type parameters are hidden, or if the address part of From is encoded. For broader message-format triage, use a repeatable process for RFC compliance errors so fixes do not depend on one mailbox provider's current tolerance.
Serializer requirements for structured headerstext
Do not encoded-word encode structured fields. Preserve URLs, mailto addresses, commas, semicolons, and brackets. Keep List-Unsubscribe-Post as List-Unsubscribe=One-Click. Fold long lines only at grammar-allowed whitespace positions. Encode only human-readable phrases where the grammar allows it. Run tests against the raw source, not the rendered mailbox view.
- Stop blanket encoding: A universal header-encoding step creates invalid output for structured fields.
- Keep tokens raw: URLs, addresses, message IDs, MIME parameters, and DKIM fields must remain parseable.
- Sign last: Apply DKIM after the final header form is built, then avoid later header rewriting.
- Regression test: Test long unsubscribe URLs, folded headers, display names, and non-ASCII subject lines separately.
Where Suped fits
Suped cannot rewrite a vendor's malformed outbound headers after the message has been sent. Suped's product supports the surrounding workflow with raw-message testing, DMARC reporting, SPF and DKIM checks, issue detection, alerts, and evidence that separates a serializer bug from authentication or reputation trouble.
Email tester sample report showing total score, email preview, issue summary, and per-section results
Suped's product includes DMARC monitoring, SPF and DKIM visibility, hosted SPF, hosted DMARC, hosted MTA-STS, alerts, MSP multi-tenancy, and blocklist monitoring (blacklist monitoring). A team can compare the malformed-header sample with authentication results and provider-specific delivery changes without treating DMARC as a repair for the header.
Practical Suped workflow
- Test message: Send the real email and inspect the raw header output.
- Check auth: Confirm SPF, DKIM, and DMARC results around the same send.
- Watch trends: Use alerts and reports to see whether failures cluster by source, provider, or domain.
- Escalate cleanly: Give the vendor a reproducible example and a corrected header.
Views from the trenches
Best practices
Keep structured headers unencoded, then test the raw source before sending production mail.
Ask vendors for header-specific serialization tests, not a generic encode-all safety layer.
Track delivery, bounce, authentication, and unsubscribe signals after any header change.
Common pitfalls
Trusting webmail display can hide the invalid wire format that receivers parse during filtering.
Encoding List-Unsubscribe often makes one-click unsubscribe invisible to strict parsers.
Fixing only the subject line leaves broken structured headers in the same mail stream.
Expert tips
Store before-and-after message source so the vendor can reproduce the exact parser failure.
Treat tolerant delivery as temporary, because receiver parsing can change after software updates.
Add tests for long headers, folded headers, encoded display names, and structured fields.
Expert from Email Geeks says structured headers that use encoded-words violate the grammar, even when a tolerant mailbox currently accepts the message.
2025-01-21 - Email Geeks
Marketer from Email Geeks says removing an encoded List-Unsubscribe header is safer than shipping a malformed unsubscribe field.
2025-01-21 - Email Geeks
How urgently to fix invalid headers
MIME encoded structured headers are invalid because they hide protocol syntax inside a text-encoding mechanism. The receiver needs visible syntax to parse the field. If the receiver accepts the message anyway, that is tolerance, not proof that the message is correct.
For a low-volume sender with no visible delivery impact, put the serializer defect in the vendor backlog and schedule a fix. Senders that depend on one-click unsubscribe or send marketing mail in bulk should escalate it now. The implementation change is usually small, but the affected fields control automated handling by mailbox providers and filters.
- Minimum action: Collect raw source and ask the platform to stop encoding structured headers.
- Urgent action: Escalate immediately when the affected header controls unsubscribe, authentication, or routing.
- Long-term action: Add raw-message regression tests so the same bug does not return later.
