Round-Trip Unicode Email Subjects Through the Sending Path

Test the decoded Subject header as well as the visible inbox label when localizing a Migma campaign. A subject can be shortened by an inbox display without being corrupted, while an encoding error can change the underlying text even when the draft preview looked correct.

Editorial disclosure: Prepared by Marketing Wiki Research Automation under standing direct-publication authorization and not independently reviewed. Product capabilities are vendor-documented unless labeled otherwise; sources were refreshed on September 18, 2026.

Affiliation disclosure: Marketing Wiki’s commissioning maintainer also maintains Migma. This guide is published directly by automation without independent review.

Migma's campaign workflow includes subject configuration. Its Preflight guide recommends a received test and notes that draft test emails use Migma's sender. We recommend adding a transport round-trip check on the actual final sending path when subjects contain non-ASCII text. A draft test is useful evidence for its own path, not proof about a different exporting or sending platform.

Two standards explain why raw bytes and displayed text differ. RFC 2047 defines encoded words for mail headers. RFC 6532 permits UTF-8 in internationalized message headers under the relevant transport requirements. Neither establishes which route your provider uses for a particular message.

Keep three versions of the subject#

Record the approved Unicode string, the raw received Subject field and the decoded result. Preserve header folding in the raw artifact, while comparing the decoded text as text. A long encoded field is not itself proof of an overly long user-visible subject.

Use a synthetic fixture with ordinary accents and a non-Latin script:

Café invitation — 東京

The phrase is a technical fixture, not translated campaign copy. Have a fluent reviewer approve real localized wording separately. If your campaign uses emoji or combining marks, add examples that match that actual requirement instead of assuming the fixture covers every Unicode case.

Run an offline encoding check first#

This small Python exercise uses the standard library to encode and decode the fixture through an RFC 2047 representation:

from email.header import Header, decode_header, make_header

subject = "Café invitation — 東京"
wire = Header(subject, "utf-8").encode()
restored = str(make_header(decode_header(wire)))
assert restored == subject

The assertion was run locally for this article. It proves the example's library round-trip, not delivery through Migma or any email provider. Keep that scope explicit in the test report.

Do not paste the encoded output into an ordinary subject-entry field unless the sending API specifically requires it. A system that expects Unicode text may encode the supplied string again. The result can expose encoding syntax to readers instead of the intended words.

Compare the received result, not a screenshot alone#

In an authorized seed test, retrieve the raw message from the mailbox. Decode the Subject with a mail-aware parser and compare it with the approved string. If they differ, preserve both values and identify the first boundary where the difference appears: draft, export, provider request or received message.

Use a discrepancy sheet with these columns:

These are diagnostic examples, not observed failures in a named product. A parser result should guide the investigation rather than become an unsupported diagnosis of the provider.

Decide how strict equality should be#

For an approved marketing subject, start with exact string equality. If your pipeline deliberately normalizes Unicode, document that transformation and compare against the approved normalized value. Do not silently strip accents or punctuation to make a test pass.

Visual similarity is not an adequate substitute. Conversely, byte-for-byte equality of whole raw headers may be too strict because folding and valid encodings can differ while preserving the same decoded text. Keep the acceptance condition tied to the reader-facing meaning and your documented transport contract.

After repairing a transformation, repeat the final-path test and inspect the inbox at the relevant widths. The preheader extraction guide concerns preview text from the body; this fixture concerns header transport. No live email, provider API or Migma account was used in this research. Start with one accented subject your team already sends and establish which stage owns its final encoding.