Allowed Characters in Email Address: What’s Permitted in Username and Server Parts?

TutorialPedia Team

Date Updated

Email addresses are the backbone of digital communication, but have you ever wondered why some characters work in an email address while others don’t? Can you use a hyphen in your username? Are dots allowed? What about non-English characters like “ñ” or “ü” in the domain?

The rules governing email addresses are defined by international standards, but they’re often misunderstood. While many assume only letters, numbers, and basic symbols are permitted, the reality is far more nuanced. This blog will demystify the allowed characters in both the local part (the “username” before the @ symbol) and the domain part (the “server” after the @ symbol), break down restrictions, and clarify common misconceptions.

Table of Contents#

  1. Email Address Structure Basics
  2. Allowed Characters in the Local Part (Username)
  3. Allowed Characters in the Domain Part (Server)
  4. Special Cases and Restrictions
  5. Common Misconceptions
  6. Practical Implications for Users and Developers
  7. Conclusion
  8. References

Email Address Structure Basics#

An email address is divided into two main parts by the “@” symbol:

  • Local Part (Username): The segment before the @ (e.g., “john.doe” in “[email protected]”).
  • Domain Part (Server): The segment after the @ (e.g., “example.com” in “[email protected]”).

Both parts have distinct rules for allowed characters, defined by Internet Engineering Task Force (IETF) standards (RFCs). While the standards are flexible, many email providers (e.g., Gmail, Outlook) enforce stricter rules than the official specs.

Allowed Characters in the Local Part (Username)#

The local part (username) is the most flexible segment, but it’s also the most misunderstood. According to RFC 5322 (the primary standard for Internet Message Format), the local part can include a wide range of characters, with some restrictions.

Alphanumeric Characters#

The simplest and most universally allowed characters are letters (A-Z, a-z) and numbers (0-9). These are always safe to use.

Special Characters#

Beyond alphanumerics, RFC 5322 permits several special characters in the local part, including:

  • ! # $ % & ' * + - / = ? ^ _ { | } ~` (exclamation mark, hash, dollar sign, etc.)

These are allowed in “unquoted” form (i.e., without surrounding quotes).

Restrictions on Special Characters#

While special characters are permitted, they come with caveats:

1. Dots (.)#

Dots are allowed but with two key restrictions:

Note: Some providers (e.g., Gmail) ignore dots in the local part entirely. For example, [email protected] and [email protected] deliver to the same inbox. This is a provider-specific rule, not an RFC requirement.

2. Quoted Strings#

For characters not in the list above (e.g., spaces, commas, semicolons), the local part can be enclosed in double quotes ("). However, quoted local parts are rare in practice and often rejected by email providers.

  • Example: "john doe"@example.com (valid per RFC, but unlikely to work with most providers).

3. Forbidden Characters#

Even in quoted form, certain characters are always forbidden in the local part, including:

  • Control characters (e.g., tabs, newlines).
  • Backslashes (\), unless escaped (e.g., "john\doe"@example.com—but this is highly non-standard).

Case Sensitivity#

Officially, the local part is case-sensitive (e.g., [email protected] and [email protected] are technically different). However, most email providers treat the local part as case-insensitive for simplicity. For example, Gmail and Outlook ignore case in usernames.

Allowed Characters in the Domain Part (Server)#

The domain part (e.g., example.com) is stricter than the local part because it must comply with DNS (Domain Name System) standards. Rules are defined in RFC 1035 (Domain Names) and extended by RFC 6531 (Internationalized Email).

Alphanumeric and Hyphens#

The domain part allows:

  • Letters (A-Z, a-z), numbers (0-9), and hyphens (-).

Hyphens have restrictions:

  • They cannot start or end a domain label (a segment between dots, e.g., “example” in “example.com”).
  • They cannot appear consecutively (e.g., ex--ample.com is invalid).
  • Example: my-domain123.com (valid), -mydomain.com (invalid), mydomain-.com (invalid).

Dots as Separators#

Dots (.) are used to separate domain labels (e.g., co.uk, blog.example.com). They cannot be used consecutively (e.g., example..com is invalid).

Internationalized Domain Names (IDNs) and Non-ASCII Characters#

Originally, domains were limited to ASCII characters. Today, RFC 6531 allows non-ASCII characters (e.g., accented letters, Cyrillic, Chinese) via Punycode encoding.

  • Example: The German domain müller.de is encoded as xn--mller-kva.de (Punycode) for DNS purposes. Email clients and providers automatically handle this conversion, so users can enter user@müller.de directly.

Length Limits#

Domains have strict length limits:

  • Total domain length: ≤ 253 characters.
  • Each domain label (e.g., “example”, “com”): ≤ 63 characters.

Special Cases and Restrictions#

Forbidden Characters in All Parts#

The following characters are never allowed in any part of an email address (per RFC 5322 and DNS rules):

  • Spaces, tabs, or control characters.
  • Slashes (/), colons (:), brackets ([ ]), or angle brackets (< >).
  • Semicolons (;), commas (,), or exclamation points in unquoted local parts (wait—no, exclamation points are allowed! Earlier list included !).

Wait, to clarify: Only the characters explicitly listed in the “allowed” sections are permitted. For example, a space in an unquoted local part is invalid, but allowed in a quoted local part (though rarely used).

Provider-Specific Rules#

Many email providers enforce stricter rules than the RFCs. For example:

  • Gmail: Disallows special characters like ! # $ % in the local part, despite RFC approval. It also ignores dots and case in the local part.
  • Outlook: May reject quoted local parts or certain special characters (e.g., + was once restricted but now allowed).
  • Corporate Email Systems: Often ban special characters entirely for simplicity.

Common Misconceptions#

  1. “Dots are not allowed in usernames.”
    False: Dots are allowed, provided they don’t start/end the local part or appear consecutively.

  2. “Hyphens can’t be used in domains.”
    False: Hyphens are allowed in domains, just not at the start/end of labels.

  3. “Email addresses are case-insensitive.”
    Partially false: The domain part is case-insensitive (DNS ignores case), but the local part is technically case-sensitive (though providers rarely enforce this).

  4. “Special characters like _ or + are forbidden.”
    False: Underscores (_), plus signs (+), and hyphens (-) are explicitly allowed in the local part.

Practical Implications for Users and Developers#

For Users:#

  • When creating an email address, stick to alphanumerics, dots, hyphens, and underscores for widest compatibility.
  • Avoid special characters like ! or $ unless your provider explicitly allows them.
  • Test edge cases (e.g., dots, hyphens) with your provider—don’t assume RFC rules apply.

For Developers:#

  • Validate email addresses against both RFC standards and common provider restrictions.
  • Use libraries like email-validator (Python) or validator.js (JavaScript) instead of writing custom regex, as RFC-compliant regex is notoriously complex.
  • Account for IDNs: If supporting non-ASCII domains, use Punycode conversion libraries (e.g., punycode.js).

Conclusion#

Email address rules are more flexible than most people realize, thanks to RFC standards that permit alphanumerics, special characters, and even internationalized domains. However, practical use is constrained by provider-specific policies and common sense (e.g., avoiding rare quoted strings).

Whether you’re a user choosing a username or a developer building email validation, understanding these rules ensures your email addresses work reliably across platforms. Always test with your provider, and when in doubt, keep it simple: alphanumerics, dots, hyphens, and underscores are universally safe.

References#

2026-01