What characters are allowed in an email address?

According to RFC 5322 (the official spec), the local part (everything before the @) can technically include almost any character you can think of: letters, numbers, periods, plus signs, underscores, hyphens, exclamation points, hashtags, dollar signs, percent signs, ampersands, asterisks, equal signs, question marks, carets, backticks, pipes, tildes, and more. If you quote the local part, you can even use spaces. So "this works"@example.com is technically valid. (Though no real system would accept it.)

The domain side (everything after the @) is stricter because it follows DNS rules: letters, numbers, hyphens, and periods only. No special characters, no underscores, no spaces.

Here's what matters in practice: just because RFC 5322 says something's valid doesn't mean real inboxes will accept it. Most modern ESPs and webmail providers stick to a much narrower set of allowed characters. They'll accept letters, numbers, periods, plus signs, underscores, and hyphens in the local part, and that's about it. Anything more exotic (hashtags, pipes, backticks, quoted strings) will either get rejected at signup or flag your validation logic as broken.

If you're building a signup form, keep your validation loose enough to accept the common special characters (periods, plus signs, hyphens, underscores) but don't stress about supporting the full RFC 5322 spec. Nobody's out there using "user name"@example.com or user!tag#test@example.com in real life. You're safe sticking to the basics. If someone tries to sign up with a weird address and it fails validation, they'll just use a different one.

One character worth knowing about: the plus sign (+). It's used for plus-addressing, which lets users create variations of their address (user+newsletters@example.com, user+receipts@example.com) that all route to the same inbox. It's a common tactic for tracking which lists sell addresses or leak them to spammers. If your form blocks plus signs, you'll frustrate savvy users and look like you're trying to stop them from tracking you.

The safest approach: allow letters, numbers, periods, hyphens, underscores, and plus signs in your validation. That covers 99.9% of real email addresses without opening the door to weird edge cases that'll break your system downstream. And don't overthink it. Most of the exotic RFC-valid characters exist because the spec was written to be technically complete, not because anyone actually uses them.