Email Anatomy: Local Part and Domain

An email address has exactly one required structural element: the @ symbol that separates the local part from the domain. Everything before @ is the local part; everything after is the domain.

user.name+tag@mail.example.co.uk
│───────────│ │─────────────────│
  local part           domain

The two parts are governed by different rules and common validators often get one or both wrong.

The Local Part

The local part identifies a mailbox on the destination mail server. It is the part the mail server on the other side of @ uses to route the message.

Who controls the local part? The domain owner. The rules in RFC 5322 define what syntax is valid in a message header, but the domain can have its own rules for what mailboxes it accepts. postmaster is a required mailbox at every domain per RFC 5321. Beyond that, the domain decides.

What the RFC says is valid:

The unquoted (dot-atom) form allows:

Alphanumeric characters: a-z, A-Z, 0-9
These special characters: ! # $ % & ' * + - / = ? ^ _ \ { | } ~`
Dots, as long as they don't appear at the start, end, or consecutively

The quoted (quoted-string) form allows:

Any printable ASCII character
Spaces
The characters ( ) [ ] \ , ; : < > @ (which are not allowed unquoted)

What is specifically NOT valid (unquoted):

Starting or ending with a dot
Two or more consecutive dots
The characters ( ) [ ] , ; : @ < > \ without quoting
Spaces without quoting

The Domain Part

The domain identifies the mail server that should receive the message. It follows the DNS domain name rules: labels separated by dots, each label 1-63 characters of letters, digits, and hyphens, no label starting or ending with a hyphen, total length not exceeding 253 characters.

What is valid:

example.com
mail.example.co.uk
subdomain.example.com
[192.168.1.1] (IP address literal — valid per RFC, rarely accepted by web validators)
[IPv6:2001:db8::1] (IPv6 literal)

What is not valid:

.example.com (leading dot)
example.com. (trailing dot — technically valid in DNS, often rejected by validators)
example (no dot — valid syntactically but not routable on public internet)
-example.com (label starting with hyphen)
example-.com (label ending with hyphen)

The @ Symbol

There is exactly one @ in a valid email address. This seems obvious until you consider:

The local part cannot contain @ unless it is quoted: "user@alias"@example.com
Multiple @ symbols without quoting is always invalid
Missing @ is always invalid

Most validators handle this correctly. The edge case is quoted local parts: "user@extra"@example.com is valid per RFC 5322 and most validators reject it.

Length Limits (from RFC 5321)

RFC 5322 defines the syntax. RFC 5321 defines the SMTP transport constraints, which apply when email addresses are used in actual mail delivery:

Part	Maximum
Local part	64 characters
Domain	255 characters
Full address	320 characters (64 + 1 + 255)
Domain label	63 characters

Web application validators should enforce these if they want to guarantee deliverability. Many don't, accepting arbitrarily long addresses.

Testing the length limits:

Submit a local part with exactly 64 characters — should be accepted
Submit a local part with 65 characters — should be rejected
Submit a full address with exactly 320 characters — should be accepted
Submit a full address with 321 characters — should be rejected

Case Sensitivity in Email Addresses

Per RFC 5321: the domain part is case-insensitive (DNS is case-insensitive). The local part is technically case-sensitive: the mail server on the receiving end can distinguish User@example.com from user@example.com.

In practice: virtually all mail servers treat the local part as case-insensitive. Gmail, Outlook, Yahoo all normalize local parts to lowercase. But the RFC does not require this — a server could treat them as case-sensitive.