What special characters are allowed in email address syntax according to RFC 5322 and how do different email providers handle them?
Published 4 Jul 2025
Updated 21 Oct 2026
13 min read
Summarize with
Updated on 21 Oct 2026: We clarified provider character rules, quoted-address escaping and browser validation, and corrected the missing-MX delivery advice.
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: ! # $ % & ' * + - / = ? ^ _ ` { | } ~. Periods are also allowed as separators between atoms. That means abced--fetet@gmail.com has valid RFC-style syntax because the double hyphen sits inside an otherwise valid local part. Gmail's public username rules do not allow hyphens, so RFC-valid syntax does not make this a registrable Gmail username.
Valid syntax is separate from provider acceptance, mailbox existence, and actual delivery. Gmail, Yahoo Mail, Outlook.com, Microsoft 365, and iCloud Mail apply their own account and routing rules. Use a confirmation email to check access to a recipient address. A sending-side email tester checks a test message and its authentication results; it does not verify that an arbitrary recipient mailbox exists.
Unquoted and quoted local parts
For new addresses, the local part has two practical RFC 5322 forms. The common form is a dot-atom: one or more atoms separated by single periods. The less common form is a quoted string: a local part wrapped in double quotes. Production systems should accept common dot-atom addresses and handle quoted local parts carefully instead of 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 account creation, map it to another mailbox, disable plus handling, or reject delivery during SMTP.
- Use RFC syntax as the broad rule for whether the address is structurally valid.
- Treat Gmail, Yahoo Mail, Outlook.com, and iCloud Mail as separate mailbox systems with their own account rules.
- Require a confirmation link or code to check mailbox access; use bounce data to investigate delivery failures.
What RFC 5322 actually allows
The core rule is easier to understand when the local part is separated into dot-atoms 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: ! # $ % & ' * + - / = ? ^ _ ` { | } ~ Dot: allowed only between atoms
Characters such as parentheses, angle brackets, square brackets, colon, semicolon, comma, backslash, double quote, and at sign are not ordinary unquoted atext characters in the local part. Some can appear inside a quoted local part when they follow quoted-string rules. This is why a simple character allowlist is weaker than a proper parser.
|
|
|
|---|---|---|
Hyphen (-) | Yes | Provider signup can reject it |
Plus (+) | Yes | Often used for subaddressing |
Slash (/) | Yes | Many signup forms reject it |
Underscore (_) | Yes | Valid locally, not in an SMTP domain label |
Apostrophe (') | Yes | Does not need double quotes in a dot-atom |
Period (.) | Separator | No leading, trailing, or doubled dots |
At sign (@) | No | Separates local part and domain; also allowed inside quotes |
Compact view of common local-part characters
Display names and comments follow separate RFC 5322 header rules. In Jane Smith <jane@example.com>, the mailbox is jane@example.com. The name and angle brackets are not local-part characters. Parenthesized comments in permitted header positions are also metadata; a single-address signup field should store the parsed mailbox rather than the whole header value.
RFC 5322 email address structure showing local-part atoms, dot separators and quoted strings.
Length limits and domain syntax
RFC 5322 defines address syntax inside messages, while RFC 5321 defines the mailbox carried by SMTP. Its limits are measured in octets, not visible characters. The local part can use up to 64 octets, and an SMTP forward-path or reverse-path can use up to 256 octets including angle brackets. That path limit leaves 254 octets for a normal mailbox address.
|
|
|
|---|---|---|
Local part | 64 octets | Count encoded bytes, not characters |
SMTP path | 256 octets | Includes < and > |
Mailbox address | 254 octets | Practical result of the path limit |
DNS label | 63 octets | No empty labels in a host name |
SMTP and DNS length limits
Normal Internet mail domains use DNS host-name labels containing ASCII letters, digits and hyphens, separated by periods. A label cannot start or end with a hyphen; underscores and spaces are not allowed. RFC syntax also permits address literals such as user@[192.0.2.1] and user@[IPv6:2001:db8::1], although web forms often reject them. Internationalized domain names (IDNs) use IDNA processing and Punycode for DNS lookup. Punycode does not encode a non-ASCII local part, which requires SMTPUTF8 support.
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, while a provider's signup form also applies abuse controls, support requirements, identity rules, and legacy routing choices.
Gmail account creation with a hyphenated username and special-character validation guidance.
Gmail is the clearest example. Gmail's username rules allow 6-30 characters using letters, digits and periods for new public usernames. Plus signs are not registration characters, but name+tag@gmail.com can receive mail for an existing name@gmail.com account. 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. Google Workspace custom domains do not inherit this dot rule.
|
|
|
|
|---|---|---|---|
New usernames: 6-30 letters, digits or periods | Dots ignored for gmail.com | Hyphens cannot be registered | |
Signup names and disposable aliases have separate rules | Configured disposable addresses use nickname-keyword@yahoo.com | Availability depends on account and locale; do not invent hyphen aliases | |
New aliases: letters, digits, periods, underscores or hyphens | Configured aliases share the account inbox | Consumer alias rules are separate from Microsoft 365 tenant rules | |
Exchange Online | Mailbox and identity rules depend on administration settings | Plus addressing is enabled by default for receiving | Administrators can disable plus tags; tags are not configured aliases |
iCloud.com email aliases: 3-20 characters | Configured aliases can send and receive through the same account | Alias limits do not define the full RFC character set | |
Custom domain | Set by mail admin | Depends on mailbox platform | Rules vary by tenant |
Provider behavior examples
These are separate provider policies: Outlook.com alias rules, Exchange Online plus addressing, Yahoo's disposable address rules, and iCloud alias rules. A provider hosting mail for a custom domain does not necessarily apply its consumer signup rules to that domain.
Avoid maintaining a large provider-specific character blocklist (blacklist) in signup code. A slash can be RFC-valid and still fail account creation at a consumer provider. A plus tag can route correctly at Gmail or Exchange Online but fail in a third-party form that blocks plus signs. A Gmail dot variant can deliver to the same inbox while a custom domain treats dots normally. For the broader standard-versus-practice split, see RFC versus reality.
Why browser email validation differs from RFC 5322
An HTML input type="email" uses the HTML Standard email-field grammar rather than a complete RFC 5322 parser. It allows the unquoted atext symbols, including plus signs and apostrophes, but excludes quoted local parts. Its local-part grammar also permits period placement that RFC dot-atoms reject.
|
|
|
|---|---|---|
first..last@example.com | Invalid dot-atom | Allowed by the grammar |
"first last"@example.com | Valid quoted string | Rejected |
Browser-field acceptance and RFC syntax are different checks
Browser acceptance does not establish RFC validity or mailbox existence. Validate again on the server. If quoted local parts or internationalized addresses are supported, ensure the form and downstream mail system can preserve them rather than relying on native email-field validation alone.
How to validate addresses in forms
For signup forms and list imports, use a layered approach. First, parse the address with a sensible RFC-compatible rule set. Next, reject structural errors such as a missing at sign, a missing domain, invalid domain labels, or misplaced periods. Send a verification message and require the user to complete a confirmation link or code before treating the address as verified.
- Do not block an RFC-valid address only because the local part looks unusual.
- Store the exact address entered, except for safe trimming around the full value.
- Require the recipient to complete a confirmation link or code instead of guessing which provider-specific patterns work.
- Track bounces and complaints after import, because syntax does not prove inbox ownership.
Suped's domain health checker helps inspect domain DNS and authentication configuration. For sending domains, DMARC monitoring shows authentication results reported by receiving providers. Neither check proves that an individual recipient mailbox exists.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
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 a 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.
Use Suped's email tester to inspect a test message's authentication results. Compare those results with the sending system's SMTP response or bounce message to separate sender-authentication problems from recipient-address errors.
Email tester sample report showing total score, email preview, issue summary, and per-section results
Email validation rules to implement
Accept valid syntax, reject broken structure, then confirm mailbox access. This keeps a form compatible with legitimate addresses while still stopping obvious input errors.
Accept or allow through
- Letters, digits, and RFC 5322 atext specials inside unquoted atoms.
- Single separators between atoms, not the first or last local-part character.
- Valid syntax and common for mailbox filtering or signup tracking.
- Valid in the local part, including repeated hyphens such as abced--fetet.
Reject or review
- Reject leading, trailing, or doubled periods outside quoted strings.
- Reject unquoted spaces in the local part or domain.
- Reject invalid domain labels, empty labels, and labels with bad hyphen placement.
- Accept only when the complete mail and support flow can preserve 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 accepted into the confirmation flow.
Verify
Confirm
RFC-valid unusual local part that needs compatible application handling and confirmation.
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 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.
Quoted strings and other validation edge cases
Plus addressing is valid syntax and is supported by Gmail and Exchange Online. It is still provider behavior, not a universal routing rule. Some recipient systems route plus tags to the base mailbox, while business-domain administrators can disable or change the behavior. A third-party web form that blocks plus signs is stricter than the RFC and blocks real users. Exchange Online plus addresses are receive-only extensions rather than configured sending aliases.
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, CRM imports, exports, and support tools break when they see this pattern. If a product accepts quoted local parts, the complete pipeline needs to preserve them without stripping quotes or splitting on spaces. Inside a quoted local part, a literal double quote or backslash needs a preceding backslash. An at sign or comma inside those quotes is data, so splitting blindly on every at sign or comma breaks valid addresses.
Quoted local parts with reserved characters
"first..last"@example.com "first@last"@example.com "first,last"@example.com "first\"last"@example.com "first\\last"@example.com
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. RFC 5321 requires preserving local-part case: User@example.com and user@example.com are not guaranteed to identify the same mailbox.
- Apply Gmail dot logic only to standard gmail.com addresses, not every domain.
- Preserve plus tags in the delivery address. A separate deduplication key must not rewrite the stored destination.
- Treat local-part case carefully and keep the user's original value.
Internationalized email adds another layer. RFC 5322's base syntax is ASCII. Internationalized domains use IDNA and Punycode, while non-ASCII local parts require the SMTPUTF8 extension defined by RFC 6531. Punycode applies to the domain, not the local part. The application database and every SMTP hop carrying the internationalized address must support it. Test the complete route instead of relying on the input regex. For a broader structural checklist, use this guide to validate an email address.
Troubleshooting delivery after syntax validation
When a message fails after an address passes validation, inspect the delivery path. The problem can be a nonexistent mailbox, a mistyped domain, unusable mail routing, a provider-side policy block, an authentication failure, or sender reputation.
A missing MX record alone does not prove that a domain cannot receive mail. RFC 5321 specifies an implicit MX fallback to the domain itself when no MX records exist; delivery then depends on usable A or AAAA records and an SMTP server at that host.
Suped's DMARC reporting product helps review sending sources and SPF and DKIM authentication results. Compare those reports with SMTP bounce codes when delivery fails. Aggregate DMARC reports do not prove that a particular message reached an inbox or that a recipient address is valid.
For sender reputation checks, Suped's blocklist monitoring helps identify listed sending IPs or domains. A blocklist (blacklist) listing can contribute to rejection when the receiving provider uses that list, even if the recipient address has valid syntax.
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 require a confirmation link or code to verify access.
Keep provider-specific rules small, documented, and separate from syntax validation.
Store the address exactly as entered so replies and exports retain the original value.
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.
SMTP acceptance proves server acceptance, not inbox placement or access to the mailbox.
Expert tips
Flag unusual RFC-valid addresses for verification instead of blocking them at entry.
Test quoted local parts across web forms, exports, CRM syncs, and support tooling.
Separate syntax failures, provider refusals, authentication issues, and reputation hits.
Expert view
Expert from Email Geeks says RFC 5322 allows the double hyphen example because hyphen is an atext character.
2024-03-19 - Email Geeks
Expert view
Expert from Email Geeks says provider acceptance is a second question after RFC syntax is established.
2024-03-19 - Email Geeks
