Valid Characters for an Email Address

What are the requirements?

An email address has a local part and a domain

RFC 5322 defines addr-spec as a local part, an @ sign, and a domain. The local part identifies the mailbox within the domain's rules. The domain identifies the system responsible for that namespace.

local-part@domain

Do not validate both sides with one character class. A punctuation mark allowed before @ can be invalid in a domain label.

An unquoted local part allows letters, digits, and selected punctuation

RFC 5322 defines the atext character set. An unquoted local part can use ASCII letters, digits, and these printable characters:

Letters:       A-Z a-z
Digits:        0-9
Other ASCII:   ! # $ % & ' * + - / = ? ^ _ ` { | } ~
Separator:     .  only between non-dot elements

That makes addresses such as o'connor@example.com, sales+ca@example.com, and first_last@example.com syntactically possible. It does not require a provider to create or accept those mailboxes.

Dots have placement rules

The unquoted dot-atom form permits a dot only between other atext runs. An unquoted local part cannot start with a dot, end with a dot, or contain two adjacent dots.

Valid dot shape:     first.last@example.com
Invalid dot shapes:  .first@example.com
                     first.@example.com
                     first..last@example.com

Provider-specific behavior can be narrower or different after syntax is accepted. For example, the separate guide on dots in Gmail addresses explains how personal Gmail delivery treats dot variants.

Quoted local parts permit a wider ASCII range

RFC 5322 also allows a quoted-string local part. Quoting can represent spaces and characters that are not valid in an unquoted dot-atom, with escapes where the grammar requires them.

"customer support"@example.com

This is a syntax example, not a claim that every signup form or provider accepts quoted mailbox names. A production sender should test the systems that create, store, transport, and receive the address before relying on this form.

The domain follows domain-label rules

RFC 5321's mailbox grammar uses domain labels made from letters, digits, and hyphens, separated by dots. A label cannot begin or end with a hyphen. An underscore is therefore not valid in an ordinary mailbox domain label, even though underscores appear in other DNS names such as _dmarc.example.com.

SMTPUTF8 extends mailbox syntax beyond ASCII

RFC 6531 defines the SMTPUTF8 extension, which permits UTF-8 in mailbox addresses when the SMTP systems involved support the extension. A Unicode address is not safe to downgrade by deleting or replacing characters. Preserve it exactly and confirm support on the intended delivery path.

When does the requirement take effect?

RFC 5321 and RFC 5322 define the modern baseline SMTP and message-format syntax. RFC 6531 adds internationalized mailbox support through SMTPUTF8. There is no single provider effective date that makes every syntactically valid address usable everywhere.

An application can adopt narrower product rules, but it should describe those as application limits instead of declaring an RFC-valid address universally invalid. Review the rule whenever an identity provider, mailing platform, or mailbox system changes.

How do I implement the requirement?

1. Preserve the address exactly as entered

Trim only surrounding input whitespace that is not part of the address field. Do not remove punctuation, change Unicode characters, or lowercase the stored local part as an automatic repair.

2. Parse the local part and domain separately

Split at the structural @ boundary with a parser that supports the address forms your product accepts. Avoid a short regular expression that silently rejects apostrophes, plus signs, or internationalized addresses without a documented product reason.

3. Apply a documented product policy

Decide whether the product supports quoted local parts and SMTPUTF8 addresses. Return a precise error when the product accepts less than the RFC grammar. Do not call a valid but unsupported address malformed.

4. Verify control and test delivery separately

Send a verification message through the actual production path. Syntax validation cannot prove that the domain resolves, the mailbox exists, or the person controls it. For public domain evidence, a DNS lookup can show the domain's current records without validating the mailbox.

How do I validate compliance?

Build tests from each supported class rather than one list of familiar addresses. Include ordinary letters and digits, apostrophes, plus signs, underscores in the local part, legal dot placement, illegal dot placement, a quoted local part if supported, and a UTF-8 address if SMTPUTF8 is supported.

Record three outcomes for each case: parser acceptance, account-verification behavior, and actual message delivery. A parser pass is syntax evidence. A verification click is control evidence. SMTP acceptance is delivery evidence. None of those alone proves future inbox placement.

Keep this work within the broader email infrastructure hub, where DNS, SMTP, message headers, and transport rules are treated as separate evidence layers.