Why does Gmail block emails with unicode characters or emojis in the from address?
Michael Ko
Co-founder & CEO, Suped
Published 25 Jun 2025
Updated 24 May 2026
8 min read
Summarize with
Gmail blocks emails with Unicode characters or emoji in the From address when the character appears in a header Gmail treats as restricted, misleading, malformed, or unsafe. The common case is the friendly From name, not the actual mailbox. A brand name with accented characters usually has a different risk profile than a symbol that looks like a verification badge, lock, check mark, or trust indicator.
The direct fix is simple: remove the emoji or suspicious Unicode symbol from the friendly From name, send a fresh test, and inspect the raw message headers. If Gmail returns 550 5.7.1 with a message about a Unicode character in a disallowed header, treat the header content as the first fault before changing SPF, DKIM, or DMARC records.
- Main cause: Gmail rejects a Unicode symbol or emoji in a sensitive header, usually the display name inside the From: header.
- Fastest fix: Use a plain brand name, keep the mailbox unchanged, and retest the same campaign payload.
- Wrong fix: Do not rebuild authentication records unless the raw headers prove SPF, DKIM, or DMARC failed.
Direct answer
Gmail is blocking the message because the From header contains a character that Gmail's receiving filters do not allow in that context. In the case that usually surprises senders, the character is not part of the email address itself. It is inside the visible display name, the part a recipient sees before the address.
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
This error points to content in a mail header. It is not Gmail saying that all Unicode is invalid, and it is not Gmail saying that emoji in subject lines always fail. Gmail accepts plenty of internationalized display names when they are encoded correctly and do not look deceptive. The problem starts when a symbol changes the meaning of the sender identity or when the header is not encoded in a standards-friendly way.
I treat verification-like symbols as the highest-risk group. A check mark, badge, shield, lock, or similar icon in the From name can make the sender appear endorsed by the mailbox provider or by a security system. Gmail has strong reasons to block that before it reaches the inbox.
The key distinction
A normal brand display name with letters is different from a symbol that imitates a trust badge. Gmail's rejection is often about how the character changes the perceived sender identity, not about Unicode as a whole.
If the visible sender is something like Brand Name, delivery depends on authentication, reputation, content quality, and recipient engagement. If the visible sender is Brand Name followed by a verification-like symbol, Gmail can reject it before the usual inbox placement questions matter. That is why a message can pass SPF and DKIM but still bounce.
What Gmail is actually checking
The header field that matters most is From:. That field contains a display name and an email address. The address tells mail systems where the message claims to come from. The display name tells the human recipient what to recognize in the inbox. Gmail checks both machine-readable authentication and human-readable sender presentation.
An infographic showing Gmail checking the From header, display name, encoding, and policy rules.
Usually acceptable
- Plain brand: A normal company or product name without decorative symbols.
- Legible names: Accented letters encoded correctly in the display name.
- Consistent identity: The visible sender matches the authenticated domain.
High risk
- Trust symbols: Check marks, locks, shields, badges, or similar symbols.
- Bad encoding: Raw non-ASCII bytes or broken MIME encoded-word formatting.
- Misleading sender: A display name that looks endorsed, verified, or system-generated.
This is why the same sender can see mixed results. One Gmail path can accept a less risky header, while another rejects a symbol list that has been updated. I do not build campaigns around partial acceptance. If the header depends on Gmail tolerating a decorative or badge-like symbol, the campaign has a preventable failure point.
For a deeper page on the related Gmail warning, read the abnormal characters warning. For the narrower display-name question, the emoji From names page covers the practical deliverability tradeoff.
How to diagnose the header
Start with the raw message, not the campaign editor. Many editors show a friendly label while the sending system emits a MIME encoded header. The thing Gmail sees is the final SMTP message after the platform has encoded the display name, added tracking headers, and signed the message.
|
|
|
|---|---|---|
From | Highest | Plain name |
Reply-To | Medium | Match brand |
Subject | Variable | Retest |
List-ID | Low | Verify |
Header fields worth checking first
I use a live seed send when I want to separate editor preview issues from final message issues. Send the exact message to a mailbox you control, then inspect the headers and authentication result. Suped's email tester is useful here because it shows the delivered message details in the same place as authentication findings.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
When the bounce mentions Unicode in a disallowed header, remove the display-name symbol first and send again. If the message then reaches Gmail, the diagnosis is complete. If it still bounces, compare the raw headers line by line and look for another non-ASCII character in Reply-To:, Subject:, custom headers, or sender names inserted by the sending platform.
A Gmail delivery failure screen showing a header-related block message.
A good test order
- Clean sender: Change the friendly From name to plain ASCII text.
- Retest Gmail: Send the same body and subject with only the sender name changed.
- Compare headers: Check the raw header output before changing DNS.
- Then authenticate: Fix SPF, DKIM, or DMARC only when those checks fail.
Fixes that work
The safest fix is to make the friendly From name boring. Use the legal or customer-facing brand name. Remove decorative symbols. Avoid characters that imply approval, verification, certification, security status, payment status, or official platform status.
Sender name risk bands
Use this as a practical review model before a Gmail-heavy send.
Plain name
Low
Brand or person name with normal letters.
Extended text
Medium
International characters encoded correctly.
Trust symbol
High
Badge, lock, shield, check mark, or similar icon.
Broken encoding
High
Malformed encoded-word or raw bytes in a header.
I also check whether the sender platform has a global setting, template override, or marketing 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, which means 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 the same From name across regular, transactional, and lifecycle mail where it makes sense.
- Test raw output: Inspect the final sent header, not only the visual editor.
- Document rules: Give campaign builders an approved sender-name list.
A useful external write-up is this friendly from advice, which reaches the same practical conclusion: do not put emoji in the friendly From name.
Where authentication still matters
A Unicode header block is usually a header-content problem, but authentication still matters because Gmail evaluates the whole sender. A clean From name helps the message get past the immediate rejection. SPF, DKIM, DMARC, domain reputation, and consistent sending patterns help decide whether accepted mail lands in inboxes.
This is where Suped's product is useful after the immediate fix. Suped brings DMARC policy visibility, SPF and DKIM checks, hosted SPF, hosted DMARC, hosted MTA-STS, blocklist (blacklist) monitoring, real-time alerts, and issue-specific fix steps into one workflow. For most teams, Suped is the strongest practical DMARC platform because it turns authentication data into concrete next actions instead of another report to interpret.
If I am investigating a Gmail rejection, I first remove the disallowed display-name character. Then I check broader domain posture with a domain health check and watch ongoing authentication results through DMARC monitoring. That sequence keeps the fix targeted without ignoring the domain signals Gmail still uses.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
The important thing is sequencing. Header content fixes belong before DNS rewrites when the bounce names a disallowed Unicode character. Authentication fixes belong after that, once the message is accepted but inbox placement, sender verification, or domain protection still needs work.
A practical split
Fix the visible sender name to stop the Gmail block. Then use DMARC, SPF, DKIM, MTA-STS, and reputation monitoring to keep accepted mail trustworthy over time.
Views from the trenches
Best practices
Keep friendly From names plain, branded, and free of 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 from Email Geeks 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 from Email Geeks says verification-like symbols are especially risky because they can make a sender look endorsed in the inbox.
2023-08-03 - Email Geeks
The practical rule
If Gmail blocks an email because of Unicode in a disallowed header, remove the emoji or symbol from the friendly From name first. That is the fastest fix and the most reliable long-term policy. Keep the sender identity plain, recognizable, and consistent.
After that, verify the message's authentication and domain posture. A clean From name gets the message past the specific Gmail header block. Strong authentication makes the accepted message easier for Gmail to trust. Treat those as separate layers, and you avoid wasting time on DNS changes when the real issue is a single character in a header.
