Preserve creator names and original email addresses as Unicode text, use UTF-8 when moving files, and test an import-export round trip before uploading a full list. Treat the display name, email domain and mailbox name as separate fields with different rules. A CRM displaying a name correctly does not prove its email sender supports an internationalized address.
Modash's market-expansion guide recommends adapting language and using local expertise when entering unfamiliar markets. Contact records need the same care. Removing accents to satisfy an import screen can lose a person's chosen name; changing characters inside an email address can change the destination.
Identify which field contains the characters
Start with the original contact record. Keep a source URL and the date you collected it alongside the name and address. Use the contact-source record guide to make later corrections traceable.
These hypothetical records illustrate three different cases. They are test data, not real contacts or delivery targets.
| Display name | Email as recorded | What to check |
|---|---|---|
| Zoë Martin | partnerships@example.com | Name survives storage and personalization |
| Mina | hello@bücher.example | Domain receives valid IDNA processing |
| 李明 | 合作@example.com | Sender supports a non-ASCII local part |
The display name belongs in a name field. Preserve spelling, accents, spacing and script. If colleagues need a romanized search alias, store it separately and label who supplied it. Do not replace the original or infer a person's preferred greeting from your alias.
The domain follows the address separator. Internationalized domain names use IDNA rules. Software may show a Unicode form to people and use an ASCII A-label form for technical operations. RFC 6531, section 3.2 requires IDNA processing for domain lookups. Use an IDNA-aware library or provider function; hand-removing accents is not a conversion method.
The local part precedes the separator. Non-ASCII characters here require email infrastructure that supports internationalized mail, including SMTPUTF8 where the protocol requires it. RFC 6531 extends mailbox syntax for those characters. A rule that rejects every non-ASCII local part describes a tool's limitation, rather than the full email standard.
Keep the original address unchanged. Store any derived technical representation separately, together with the conversion method. Do not apply domain conversion to the entire address.
Import a small UTF-8 file first
Use a test destination with sending and automated outreach disabled. The following is a hypothetical UTF-8 CSV import file. Every address is illustrative and must stay out of live campaigns.
record_id,display_name,email_original,review_status
B043-01,Zoë Martin,partnerships@example.com,import_test_only
B043-02,Mina,hello@bücher.example,domain_support_review
B043-03,李明,合作@example.com,smtputf8_support_review
B043-04,"García, Ana",ana@example.com,import_test_onlyThe last row tests a comma inside a quoted name. A successful import should produce four records and four fields per record. It should keep García, Ana in one name field.
Recommended import procedure:
- Save the source file as UTF-8. Keep an untouched copy for comparison.
- Use the destination's import dialog. Select UTF-8 explicitly when it offers an encoding choice.
- Set the delimiter to comma for this example and inspect the preview before importing.
- Map the identifier, name, original email and review status to separate text fields. Do not map the name into the email field.
- Import the test records without enabling sends. Export them again as UTF-8.
- Compare the parsed field values with the original, matching records by
record_id.
For Excel, Microsoft documents two relevant paths. A UTF-8 CSV saved with a byte order mark, or BOM, can open normally. Otherwise, use the documented Text/CSV import or Text Import Wizard route. Menu availability can vary by Excel version. Check the import preview rather than assuming a double-click selected the right encoding.
A BOM is an encoding marker, not part of the first field's name. Include a check that the receiving tool recognizes record_id without an extra character. Confirm the destination's BOM requirements before choosing an export setting for the team.
Verify the sending provider separately
Ask the person responsible for email delivery which provider and API your outreach tool uses. Check that provider's current documentation for internationalized domains and non-ASCII local parts separately.
For example, the Amazon SES SendEmail reference says SES does not support SMTPUTF8. It requires ASCII email-address strings and permits Punycode conversion of the domain. It does not permit that conversion for the local part. The same documentation treats a Unicode friendly sender name as a separate encoding concern.
That gives an operator different actions for the hypothetical rows:
- For Zoë, check name storage and the rendered greeting. The address itself contains only ASCII characters.
- For Mina, confirm the provider accepts the IDNA-derived domain representation while retaining the original record.
- For 李明, hold sending if the configured provider lacks the required support. Preserve the record and label the limitation.
Do not invent an ASCII spelling of a mailbox to get past an error. Use an alternative address only when the creator has supplied or published it for the relevant business purpose. A technically usable address also needs a separate contact-permission decision.
An import pass should never set a mailbox to "verified." Character preservation, supported syntax, mailbox existence and permission to contact are different questions. Read what an email finder can and cannot verify before choosing labels for those results.
Round-trip validation checklist
Use this checklist whenever the CRM, spreadsheet export settings or sending integration changes. These are recommended acceptance checks, not guarantees supplied by an email standard.
| Check | Pass condition | Action on failure |
|---|---|---|
| Row count | All test records return | Check delimiter, quoting and rejected-row report |
| Original values | Names and original addresses return unchanged | Locate the first step that changed the text |
| Accents and scripts | Zoë, García and 李明 survive | Stop the full import and review encoding |
| Field mapping | Names, addresses and review status stay separate | Correct the mapping and repeat |
| Export fidelity | Parsed values match the saved originals | Inspect transformations before approving |
| Personalization | Preview uses the preserved display name | Repair the template or name-field mapping |
| Address support | Provider documentation covers each address class | Keep unsupported classes on hold |
| Send controls | Test records cannot enter a live campaign | Remove them from the sending queue |
Compare field values, rather than demanding identical CSV bytes: an exporter may change quoting or line endings without changing the data. Where values look identical but fail comparison, ask a technical owner to inspect the Unicode code points. Do not overwrite originals to make the comparison pass.
Keep matching rules separate from preservation rules. An accent-free alias may help a colleague search, but it should not cause two creators to merge automatically. The creator-contact deduplication guide covers the identity decision.
Before your next full import, run the four hypothetical rows through the complete file path. Record which step, if any, changes a field. Approve the bulk import only after the original values survive and unsupported sending cases remain on hold.
