Why does Gmail block emails with unicode characters or emojis in the from address?
Updated on 2 Oct 2026: We clarified how to distinguish a Gmail Unicode-header rejection from a display-name policy issue and an internationalized address problem.
Gmail can reject email when a message header contains Unicode in a place it disallows. An emoji or unusual symbol in the friendly From name is one possible cause, especially if it imitates a verification badge or inbox control. A correctly encoded accented or non-Latin sender name has a different risk profile. The bounce text alone does not identify the offending header.
Start by removing any decorative symbol from the friendly From name, then send the same message again and compare the final headers. If Gmail returns 550 5.7.1 with the specific message about a Unicode character in a disallowed header, investigate header content before changing SPF, DKIM, or DMARC records.
- Common cause: The display name contains a graphic-like emoji or symbol, or a header has invalid encoding.
- Fastest test: Use a plain sender name, keep the mailbox and message unchanged, and retest.
- Wrong first step: Do not rebuild authentication records solely because the SMTP status is 550 5.7.1.
Why Gmail rejects a Unicode header
Gmail's Unicode-in-a-disallowed-header bounce identifies a header problem but does not specify which field contains it. Inspect the visible From name first when it contains an emoji or unusual symbol, then check the rest of the final message headers if that test does not resolve the rejection.
Typical Gmail bouncetext
smtp;550 5.7.1 The message contains a unicode character in a disallowed header. Please review our message and header content guidelines. - gsmtp
The full diagnostic text matters: Gmail uses 550 5.7.1 for several unrelated header and delivery failures. The Unicode message does not mean every Unicode character is invalid, nor does it prove that the display-name rule caused the bounce. Gmail separately advises senders to avoid emojis and non-standard characters that imitate graphic elements. Message syntax and encoding must also be valid.
Verification-like symbols are a particular risk. A check mark, badge, shield, lock, unread-count marker, or similar icon in the From name can make the sender appear endorsed by the mailbox provider or a security system. Gmail advises against this presentation.
The key distinction
A correctly encoded personal or brand name is different from a symbol that imitates a graphic element. Inspect the exact bounce and final header before assigning the cause to Gmail's display-name policy.
If the visible sender is a plain brand name, delivery still depends on authentication, reputation, message quality, and recipient response. Passing SPF or DKIM on another test does not make a rejected header acceptable.
Display name versus email address
The From header combines two separate values: a human-readable display name and a mailbox address. In the example below, the encoded text is the display name, while news@example.com is the mailbox.
Encoded international display nametext
From: =?UTF-8?Q?Jos=C3=A9_Acme?= <news@example.com>
A non-ASCII display name can use MIME encoded-word syntax. Direct UTF-8 in header values is also permitted when the sending path supports SMTPUTF8. Neither method overrides Gmail's guidance against graphic-like sender names; switching between Base64 and quoted-printable will not fix a misleading symbol.
Unicode inside the mailbox itself is a different issue. A non-ASCII local part, the text before the @ symbol, requires SMTPUTF8 support across the sending path. An unsupported mailbox can produce an address or syntax error instead of Gmail's Unicode-in-a-disallowed-header response.
Do not encode around the policy
Use encoding to preserve a legitimate international name. Do not change the encoding to disguise the same badge-like emoji or graphical symbol.
Unicode in the mailbox domain
The domain after the @ sign is another place Unicode can appear in a From address. Internationalized domain names use IDNA; an ASCII form often begins with xn--. Check that the visible domain and its ASCII form refer to the domain your organization actually controls. The display name and the mailbox domain need separate checks.
Gmail's sender guidance calls for internationalized sender, reply-to, envelope, authentication, and linked domains to follow Unicode Technical Standard #39. Review lookalike letters and mixed scripts that can make a domain resemble another organization. A correctly formatted internationalized domain is not automatically the cause of a Unicode-header bounce.
When the domain is internationalized, compare the final From: domain with the sending domain and DKIM signing domain. If Gmail reports a non-compliant From domain or an authentication error, use that specific diagnostic rather than treating it as the same 550 5.7.1 Unicode-header case.
Which headers to inspect
The From: header is the first place to check because it contains the display name and mailbox address. Gmail also checks message syntax and sender presentation in other headers. The exact Unicode-header bounce does not name the field at fault.
An infographic showing Gmail checking the From header, display name, encoding, and policy rules.
Lower risk
- Plain brand: A company or product name without decorative symbols.
- International name: Accented or non-Latin letters transmitted with valid header encoding.
- Consistent identity: A visible sender that accurately identifies the person or organization.
Higher risk
- Trust symbols: Check marks, locks, shields, badges, or similar symbols.
- Interface mimicry: Unread counts, reply markers, or icons that look like Gmail controls.
- Invalid header syntax: Broken MIME encoded words or raw UTF-8 without the required SMTPUTF8 support.
The same sender can see mixed results when message variants or receiving paths differ. Compare the exact raw headers and bounce text for accepted and rejected messages. Campaigns should not depend on Gmail tolerating a decorative or badge-like symbol.
For a deeper page on the related Gmail warning, read the abnormal characters warning. The emoji subject lines page covers the separate deliverability tradeoff in the Subject header.
How to diagnose the header
Start with the final message source or sending logs, not the campaign editor. Many editors show a friendly label while the sending system emits a MIME-encoded header. A rejected Gmail message will not appear in the recipient inbox, so capture the original message at the sender or inspect a copy accepted by a mailbox you control. The bounce does not identify the offending header by name.
|
|
|
|---|---|---|
From | Common source | Inspect display name and mailbox |
Reply-To | Secondary identity | Check name and encoding |
Subject | Separate content field | Compare if rejection continues |
Custom headers | Possible hidden source | Check field names, syntax, and UTF-8 support |
Header fields worth checking first
Use a live seed send to separate editor preview issues from final message issues. Send the exact message to an account you control and inspect the headers if it is accepted. Within Suped's product, the email tester shows delivered message details with authentication findings. For a Gmail rejection, retain the bounce and sender-side message source as well.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
When the bounce explicitly mentions Unicode in a disallowed header, remove the display-name symbol first and send again with the body and subject unchanged. If that version is accepted, the change supports the diagnosis. If it still bounces, compare the final headers line by line for another unusual character or encoding issue in Reply-To:, Subject:, custom headers, or sender names inserted by the sending system.
A Gmail delivery failure screen showing a header-related block message.
A good test order
- Clean sender: Change the friendly From name to a plain, accurate sender name.
- Retest Gmail: Send the same body and subject with only the sender name changed.
- Compare headers: Check the final header output and full bounce before changing DNS.
- Then authenticate: Fix SPF, DKIM, or DMARC when their checks fail.
How to fix a Gmail Unicode header rejection
The safest first fix is to make the friendly From name plain and accurate. Use the customer-facing brand or person name. Remove decorative symbols and characters that imply approval, verification, security status, payment status, or official platform status.
Sender name risk bands
Relative risk for this specific header issue before a Gmail send.
Plain name
Low
Brand or person name with standard letters.
International name
Low
Accented or non-Latin letters sent with valid header encoding.
Graphic-like symbol
High
Badge, lock, shield, check mark, or interface-like icon.
Broken encoding
High
Malformed encoded word or unsupported raw UTF-8 in a header.
Also check whether the sending system has a global setting, template override, or automation token that inserts the display name late in the send process. Teams often clean the campaign title but leave the account-level sender identity unchanged, so the same Gmail bounce returns on the next campaign.
A flowchart for diagnosing a Gmail Unicode header bounce.
- Remove symbols: Replace the display name with plain text before the next send.
- Keep identity stable: Use a consistent From name across messages from the same sending stream.
- Test raw output: Inspect the final sent header, not only the visual editor.
- Document rules: Give campaign builders an approved sender-name list.
When to check SPF, DKIM, and DMARC
A Unicode-header bounce points to header content, but authentication still matters for accepted mail. Gmail requires senders to personal Gmail accounts to use SPF or DKIM. Senders who deliver more than 5,000 messages per day to personal Gmail accounts must use SPF, DKIM, and DMARC, with the From domain aligned with the domain authenticated by SPF or DKIM. These requirements do not override the display-name guidance.
Suped's product can collect DMARC aggregate reports and surface SPF and DKIM alignment results. Use those findings after the header fix to identify separate authentication failures. DMARC reports do not identify the character that caused a Gmail header rejection.
First remove the suspect display-name character. Then check broader domain posture with a domain health check and review ongoing authentication results through DMARC monitoring. That sequence keeps the fix targeted without ignoring other domain issues.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Check the exact bounce before changing DNS. A Unicode-header diagnostic calls for header inspection. A separate authentication diagnostic calls for SPF, DKIM, or DMARC troubleshooting.
A practical split
Fix the visible sender name to address the suspected Gmail header block. Then use DMARC, SPF, and DKIM results to check authentication of accepted mail.
Views from the trenches
Best practices
Keep friendly From names plain and branded, without symbols that look like trust badges.
Test the exact sent header, not the editor preview, before a large Gmail campaign send.
Keep a version-controlled list of approved sender names for every sending system.
Common pitfalls
Do not assume one accepted test means every Gmail server will accept the same header.
Do not put check marks, badges, locks, or certificate-like symbols in the From name.
Do not treat this as a DMARC failure until the raw headers prove authentication broke.
Expert tips
Strip emoji and unusual symbols first, then retest before changing authentication records.
Audit the complete From header after your ESP encodes it, not the label in the editor.
Separate display-name testing from SPF, DKIM, and DMARC testing to avoid false fixes.
Marketer view
An Email Geeks discussion says a Gmail Unicode header bounce often points to bad header encoding or a restricted symbol in the friendly From name.
2023-08-03 - Email Geeks
Marketer view
An Email Geeks discussion says verification-like symbols are especially risky because they can make a sender look endorsed in the inbox.
2023-08-03 - Email Geeks
These field reports are anecdotal. Use the exact SMTP diagnostic and final headers to confirm the cause for a specific message.
