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 17 Aug 2025
7 min read
Email addresses appear deceptively simple, but their underlying structure and the rules governing them are surprisingly intricate. We often assume that an address follows a straightforward alphanumeric pattern, yet the reality is far more complex, especially when considering special characters.
The authoritative source for email address syntax is RFC 5322, the Internet Message Format standard. It defines precisely which characters are permitted in different parts of an email address. However, merely adhering to this standard doesn't guarantee your emails will always reach their destination.
There's a significant difference between what the RFC allows and what major email providers like Google, Yahoo, or Microsoft actually accept or process consistently. This article will break down the RFC 5322 rules and then explore how real-world email services interpret and often restrict these rules, impacting email deliverability.
Understanding RFC 5322: The foundational rules
An email address is fundamentally divided into two parts separated by the "@" symbol: the local part and the domain part. The domain part must conform to DNS naming conventions, primarily allowing alphanumeric characters and hyphens. The local part, however, is where the rules become more nuanced, permitting a wider array of characters.
RFC 5322 defines a set of characters known as "atext" which are allowed in the local part of an email address without needing special treatment. These include uppercase and lowercase Latin letters (A-Z, a-z), digits (0-9), and a specific list of printable special characters. These characters form the basis for most common email addresses.
RFC 5322 allowed 'atext' special characterstext
! # $ % & ' * + - / = ? ^ _ ` { | } ~
Beyond the `atext` characters, RFC 5322 also allows for a "quoted-string" mechanism in the local part. This means that if a local part needs to include characters that are not part of `atext` (such as spaces, commas, or parentheses), they can be enclosed within double quotes. For example, "John Doe"@example.com is a technically valid email address according to the RFC.
It's also important to note the rules surrounding periods (dots) in the local part. A period can be used to separate "atoms" within the local part (e.g., first.last), but it cannot be the first or last character, nor can two periods appear consecutively. Understanding these dot placement rules is key to avoiding issues, as explored in our guide on email addresses with multiple or misplaced periods.
The divergence: RFC compliance versus provider policies
While RFC 5322 provides the blueprint, the real world of email deliverability is often shaped by the practical policies of major email service providers (ESPs) and mailbox providers (MBPs). These providers, such as Google, Yahoo, and Microsoft, often implement stricter rules to combat spam, improve usability, and maintain compatibility with legacy systems.
RFC 5322 syntax
Character allowance: Permits a broad range of alphanumeric and special `atext` characters (`!#$%&'*+-/=?^_`{|}~`).
Quoted strings: Allows nearly any character (including spaces) if enclosed in double quotes (e.g., "name with spaces"@example.com).
Dot rules: Periods cannot be at the start or end of the local part, nor can they be consecutive.
Common provider restrictions
Stricter local part: Many providers limit the local part to alphanumeric characters, hyphens, and single periods (dots), often excluding many RFC-allowed special characters like ! or %. Quoted strings are rarely supported in practice.
Case sensitivity: While RFC 5322 technically allows case sensitivity in the local part, most providers treat email addresses as case-insensitive for convenience.
Dot handling:Gmail, for example, ignores dots in the local part, meaning john.doe@gmail.com and johndoe@gmail.com are treated as the same address. You can learn more about how Gmail handles dots in email addresses in our dedicated guide.
This discrepancy means that an email address considered syntactically valid by RFC 5322 might still be rejected by a mailbox provider during sign-up or bounce when sending, due to their internal policies. For instance, while RFC 5322 permits the "/" character in the local part, many providers, like Yahoo, might not allow it for new account registrations. Understanding how to validate the structure of an email account is critical.
Such inconsistencies can lead to frustrating deliverability issues, where emails that appear perfectly valid according to the standard fail to reach the inbox. This often necessitates troubleshooting efforts to identify the specific RFC compliance errors or provider-specific rejections. You can find more information on troubleshooting email delivery issues related to RFC compliance in our knowledge base.
Internationalized email addresses and deliverability
While RFC 5322 primarily deals with ASCII characters, the internet's global nature led to the development of Internationalized Email Addresses (EAI), specified by RFC 6530. EAI allows for the use of non-ASCII characters, such as accented letters (e.g., in French or German) or characters from other scripts (e.g., Cyrillic, Arabic, Chinese) in both the local and domain parts of an email address. The goal is to make email truly global and accessible in native languages.
EAI adoption and its challenges
Despite the existence of standards for internationalized email addresses, their adoption across all email systems and providers is not yet universal. This creates a significant challenge for deliverability. If you send an email to an address with unicode characters and the receiving mail server doesn't fully support EAI, the email may be rejected, lost, or land in the spam folder.
Some providers, like Gmail, are actively working towards broader EAI support, but many legacy systems or smaller providers may still struggle. This can also lead to errors like "sender's email address uses abnormal characters," which we've covered in our article what causes Gmail's 'sender's email address uses abnormal characters' error.
For email marketers and senders, this means exercising caution when dealing with internationalized email addresses. While technically valid, their practical deliverability can be unpredictable across the vast email ecosystem, sometimes leading to your emails being blocked if they contain unicode characters or emojis in the from address. It highlights the critical need for robust validation processes.
Practical validation and deliverability strategy
Given the disparity between RFC 5322 and real-world provider behavior, a practical approach to email address validation is essential for maintaining strong deliverability. Simply checking against the RFC standard is a good starting point, but it's not sufficient if your goal is to ensure messages reach their recipients consistently.
Validation Level
Description
Focus
RFC 5322 Syntax Check
Verifies adherence to the core standard for character sets and structure.
Basic format compliance
Provider-Specific Rules
Checks for compatibility with common provider restrictions and conventions.
Practical deliverability
Real-Time Validation
Utilizes external services to confirm email existence and mailbox status.
Enhanced deliverability & list hygiene
Relying solely on a strict RFC 5322 regex for validation can be problematic because it might accept addresses that major email providers will later reject. This can lead to high bounce rates, which negatively impact your sender reputation and overall deliverability. Instead, consider adopting a more pragmatic validation strategy, often involving email validation tools and practices.
Sending emails to addresses with unsupported special characters or those that don't align with provider-specific rules can result in emails being marked as spam or your domain ending up on a blocklist (or blacklist). This directly harms your sender reputation. Understanding what happens when your domain is on an email blacklist emphasizes the importance of thorough email list hygiene and proper validation.
Views from the trenches
Best practices
Validate against RFC 5322 as a minimum baseline for email address syntax.
Consider practical provider-specific limitations, especially for user sign-ups.
Do not over-validate email addresses, as it can exclude legitimate users.
Periodically review your email validation rules to adapt to industry changes.
Common pitfalls
Assuming RFC 5322 compliance guarantees deliverability to all providers.
Implementing overly strict regex that rejects valid email addresses.
Failing to account for how major providers handle special characters.
Not considering internationalized email addresses when dealing with global users.
Expert tips
Always test email addresses with complex characters on major providers.
Use email validation APIs to maintain clean and deliverable lists.
Monitor DMARC reports to identify email delivery issues related to character parsing.
Educate your team on the difference between RFC compliance and actual deliverability.
Expert view
Expert from Email Geeks says: RFC 5322, particularly section 3.2.3 and 3.4.1, defines the allowed characters, and the syntax allows for many special characters.
March 19, 2024 - Email Geeks
Marketer view
Marketer from Email Geeks says: A valid RFC syntax does not mean an email provider will allow that email address, especially during sign-up flows.
March 19, 2024 - Email Geeks
Balancing standards and real-world delivery
Navigating the landscape of email address syntax requires understanding both the broad definitions set by RFC 5322 and the specific, often stricter, interpretations by major email providers like Google and Microsoft. While the RFC permits a wide array of special characters, including those within quoted strings, real-world systems frequently impose tighter constraints for practical reasons, impacting deliverability.
Ignoring these provider-specific nuances can lead to legitimate emails bouncing or being directed to spam folders, ultimately damaging your sender reputation. This highlights the critical distinction between an email address being technically RFC-compliant and it being truly deliverable across the diverse email ecosystem.
For optimal email deliverability, it's crucial to implement robust validation strategies that account for both the RFC standard and the common behaviors of major mailbox providers. Prioritizing deliverability means understanding these character limitations and adapting your processes to ensure your messages consistently reach their intended inboxes.
Google, 
Yahoo, and 
Microsoft, often implement stricter rules to combat spam, improve usability, and maintain compatibility with legacy systems.
Gmail, for example, ignores dots in the local part, meaning john.doe@gmail.com and johndoe@gmail.com are treated as the same address. You can learn more about how Gmail handles dots in email addresses in our dedicated guide.
Microsoft. While the RFC permits a wide array of special characters, including those within quoted strings, real-world systems frequently impose tighter constraints for practical reasons, impacting deliverability.
