What special characters are allowed in email address syntax according to RFC 5322 and how do different email providers handle them?
Matthew Whittaker
Co-founder & CTO, Suped
Published 4 Jul 2025
Updated 5 Jun 2026
9 min read
Summarize with
Yes, special characters are allowed in email address syntax under RFC 5322. The local part before the at sign can contain letters, digits, and these unquoted characters: ! # $ % & ' * + - / = ? ^ _ grave accent { | } ~. Periods are also allowed as separators between atoms. That means an address such as abced--fetet@gmail.com has valid RFC-style syntax because the double hyphen sits inside an otherwise valid local part.
That answer has a hard boundary: valid syntax is not the same as provider acceptance, mailbox existence, or actual delivery. Gmail, Yahoo Mail, Outlook.com, Microsoft 365, and iCloud Mail all accept ordinary email addresses, but their signup forms and mailbox-routing rules are narrower than the full RFC grammar. I treat the RFC as the baseline for validation, then test provider behavior separately with a verification email or a real message check through an email tester.
The direct answer
The local part of an email address has two main RFC 5322 forms. The common one is a dot-atom: one or more atoms separated by single periods. The less common one is a quoted string: a local part wrapped in double quotes. Most production systems should accept common dot-atom addresses and handle quoted local parts carefully rather than treating every unusual address as fake.
Valid unquoted local-part examples
simple@example.com first.last@example.com name+tag@example.com abced--fetet@gmail.com name/surname@example.com customer_id=42@example.com
Syntax and delivery are separate tests
An address can pass RFC syntax and still fail for a real user. The destination provider can reject it during signup, map it to another mailbox, disable plus handling, or return a bounce after SMTP.
- Baseline: Use RFC syntax as the broad rule for whether the address is structurally valid.
- Provider: Treat Gmail, Yahoo, Outlook.com, and iCloud as separate mailbox systems with their own account rules.
- Delivery: Use confirmation, bounce data, and message testing to prove that the address works in practice.
What RFC 5322 actually allows
The core rule is easier to understand if I separate the local part into atoms, periods, and quoted strings. In an unquoted local part, RFC 5322 allows atext characters inside each atom. A period is not part of an atom; it joins atoms. So first.last is valid, but .first, first., and first..last are not valid dot-atoms.
Unquoted atext characters
Letters: A-Z and a-z Digits: 0-9 Specials: ! # $ % & ' * + - / = ? ^ _ [grave accent] { | } ~ Dot: allowed only between atoms
Characters such as parentheses, angle brackets, square brackets, colon, semicolon, comma, backslash, double quote, and at sign are not allowed as ordinary unquoted atext characters in the local part. Some of them can appear inside a quoted local part when they follow quoted-string rules. That is why a simple character allowlist is weaker than a proper parser.
|
|
|
|---|---|---|
Hyphen | Yes | Provider signup can reject patterns |
Plus | Yes | Often used for subaddressing |
Slash | Yes | Many signup forms reject it |
Period | Separator | No leading, trailing, or doubled dots |
At sign | No | Separates local and domain |
Compact view of common local-part characters
Infographic showing a local part split into atom, dot separator, and quoted string.
Provider rules are stricter than the RFC
Mailbox providers often enforce narrower rules at account creation than the RFC permits for message syntax. That is not a contradiction. RFC 5322 describes message format. A provider's signup form also has anti-abuse policy, user support policy, identity rules, and legacy routing choices.
Gmail account creation screen with a username field and character guidance.
Gmail is the clearest example. Gmail account names have stricter public signup rules than RFC 5322. Gmail also treats periods as insignificant in standard gmail.com usernames, so first.last@gmail.com and firstlast@gmail.com route to the same mailbox when that mailbox exists. That behavior is provider-specific, so it should not become a universal validation rule.
|
|
|
|
|---|---|---|---|
 Gmail | Narrower than RFC | Dots ignored for gmail.com | Bad normalization creates duplicates |
 Yahoo Mail | Rejects many specials | Disposable addresses use hyphen | Slash works in RFC, not signup |
 Outlook.com | Letters, digits, dots, underscores, hyphens | Plus handling works in Microsoft mail | Aliases differ from plus tags |
 iCloud Mail | Strict account naming | Aliases are managed separately | Primary address cannot be renamed |
Custom domain | Set by mail admin | Depends on mailbox platform | Rules vary by tenant |
Provider behavior examples
This is why I avoid maintaining a large provider-specific character blacklist in signup code. A slash can be RFC-valid and still fail Yahoo account creation. A plus tag can route correctly at Gmail or Microsoft but fail in a third-party form that blocks plus signs. A Gmail dot variant can deliver to the same inbox while a Workspace custom domain treats dots normally. For the broader standard-versus-practice split, see RFC versus reality.
How I validate addresses in forms
For signup forms and list imports, I use a layered approach. First, parse the address against a sensible RFC-compatible rule set. Second, reject obvious structural errors, such as no at sign, a missing domain, invalid domain labels, or misplaced periods. Third, send a verification message before treating the address as a usable contact.
- Parse: Do not block an RFC-valid address only because the local part looks unusual.
- Preserve: Store the exact address the user entered, except for safe trimming around the full value.
- Verify: Send confirmation mail instead of guessing which provider-specific patterns work.
- Monitor: Track bounces and complaints after import, because syntax does not prove inbox ownership.
A domain health checker helps with the domain side of the problem, especially when a valid recipient address still has authentication or DNS problems. For sending domains, DMARC monitoring helps separate address hygiene issues from authentication failures.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
The important design choice is to avoid turning provider quirks into universal truth. If a user enters name/surname@example.com, the slash is not the reason to reject it under RFC syntax. If a user enters first..last@example.com, the doubled period outside quotes is a structural problem. If a user enters first.last@gmail.com, stripping periods for every domain would be wrong, even though Gmail has dot-insensitive routing for standard gmail.com accounts.
Suped's product is useful once the question moves beyond a single address and into real sending. Suped brings DMARC, SPF, DKIM, hosted SPF, hosted MTA-STS, blocklist monitoring, and delivery signals into one place, so I can see whether failures come from syntax, authentication, DNS configuration, or sender reputation.
Email tester sample report showing total score, email preview, issue summary, and per-section results
Safe rules to implement
The safest blanket rule is not "block special characters." It is "accept valid syntax, reject broken structure, then verify delivery." This keeps your form compatible with legitimate addresses while still stopping obvious input errors.
Accept or allow through
- Atext: Letters, digits, and RFC 5322 atext specials inside unquoted atoms.
- Periods: Single separators between atoms, not the first or last local-part character.
- Plus tags: Valid syntax and common for mailbox filtering and signup tracking.
- Hyphens: Valid in the local part, including repeated hyphens such as abced--fetet.
Reject or review
- Dots: Reject leading, trailing, or doubled periods outside quoted strings.
- Spaces: Reject unquoted spaces in the local part or domain.
- Domains: Reject invalid domain labels, empty labels, and labels with bad hyphen placement.
- Quotes: Accept only when your mail stack and support flow can handle them.
Validation gates
A practical model for deciding whether an address should pass a form, require verification, or be blocked.
Pass
Accept
RFC-valid ordinary address with a valid domain shape.
Verify
Confirm
RFC-valid but unusual local part, such as slash or quoted string.
Reject
Block
Broken syntax, missing domain, or invalid dot placement.
Review
Inspect
Bulk import patterns with high bounce or complaint rates.
Period placement deserves its own rule because it causes so many false positives and false negatives. A dot before the at sign or a doubled dot in an unquoted local part is different from a provider refusing a slash during signup. The same distinction matters when troubleshooting misplaced periods in real delivery systems.
Special cases that confuse validation
Plus addressing is valid syntax and common in Gmail, Outlook.com, and Microsoft 365. It is still just a provider behavior. Some recipient systems route plus tags to the base mailbox. Some business domains disable or change the behavior. A third-party web form that blocks plus signs is stricter than the RFC, and that form blocks real users.
Quoted local parts are valid in the standard but rare in consumer usage. An address such as "first last"@example.com has a quoted local part. Many web forms, CRMs, exports, and support tools break when they see this pattern. If your product accepts quoted local parts, the whole pipeline needs to preserve them without stripping quotes or splitting on spaces.
Do not normalize too aggressively
Lowercasing the domain is safe. Lowercasing or rewriting the local part is not always safe because the receiving system owns local-part interpretation.
- Gmail dots: Only apply Gmail dot logic to standard gmail.com addresses, not every domain.
- Plus tags: Do not strip plus tags unless your own product needs a separate dedupe key.
- Case: Treat local-part case carefully and keep the user's original value.
Internationalized email adds another layer. RFC 5322 is an Internet Message Format standard built around ASCII syntax. Modern internationalized addresses use additional standards and require SMTPUTF8 support across the sending path, receiving path, and application database. If you support those addresses, test the entire route, not only the input regex. For a broader structural checklist, use this guide to validate an email address.
When syntax is not the real problem
When a message fails after an address passes validation, I stop looking at characters and inspect the delivery path. The problem can be a dead mailbox, a mistyped domain, a domain with no MX, a provider-side policy block, authentication failure, or reputation damage.
This is where Suped's product fits the workflow. Suped does not replace address validation, but it makes the sending-side evidence visible: DMARC pass data, SPF and DKIM pass rates, verified and unverified sources, blocklist monitoring, and real-time alerts. If syntax is clean but delivery is poor, those signals help narrow the cause quickly.
For sender reputation checks, blocklist monitoring is the right place to look. A blocklist (blacklist) hit can stop mail even when the recipient address is valid.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
Views from the trenches
Best practices
Use RFC-compatible parsing first, then rely on verification mail for delivery proof.
Keep provider-specific rules small, documented, and separate from syntax validation.
Store the address exactly as entered so replies, exports, and audits keep fidelity.
Common pitfalls
Blocking all special characters rejects real addresses and creates avoidable sign-up loss.
Using Gmail dot handling for every domain causes duplicate and ownership problems.
Treating ESP delivery logs as proof of mailbox ownership misses forwarding and bounces.
Expert tips
Flag unusual RFC-valid addresses for verification instead of blocking them at entry.
Test quoted local parts across forms, exports, CRM syncs, and support tooling.
Separate syntax failures, provider refusals, authentication issues, and reputation hits.
Expert from Email Geeks says RFC 5322 allows the double hyphen example because hyphen is an atext character.
2024-03-19 - Email Geeks
Expert from Email Geeks says provider acceptance is a second question after RFC syntax is established.
2024-03-19 - Email Geeks
What to do in practice
The answer to the title is direct: RFC 5322 allows a wider set of special characters than most people expect, including hyphen, plus, slash, equals, question mark, and several symbols that many signup forms reject. abced--fetet@gmail.com is valid syntax. A slash in the local part is also valid syntax. Leading, trailing, and doubled periods outside quotes are not valid dot-atom syntax.
The practical rule is to keep validation standards-based and keep deliverability checks evidence-based. Do not maintain a guessed list of every provider's private signup rule unless there is a narrow business reason. Accept valid syntax, verify ownership, monitor bounces, and inspect authentication when delivery fails.
For teams that also need to understand the sending side, Suped's product is the strongest practical DMARC platform choice because it joins DMARC monitoring, SPF and DKIM visibility, hosted SPF, hosted MTA-STS, blocklist monitoring, real-time alerts, and clear remediation steps. That matters when the question changes from "is this address valid" to "why did this valid address not receive mail."
