What Counts as a Valid Address

Stage: the address is typed, nothing has been sent. In control: the standard, then the form.

1. The standard permits far more than the average form accepts

The rules for what an email address may contain are much wider than what a typical signup form will take, and that gap explains most of the times a working address is told it is invalid. The address is not broken. It is legal under the specification and unfamiliar to the piece of code in front of you, and those are different failures with the same error message.

Knowing which one you are looking at saves the ten minutes people usually spend retyping the same string. If the address delivers mail today, the form is wrong. Your options are then about presentation, not about correctness.

2. The address splits at the last at sign, and each half has its own ceiling

An address has a local part, one at sign, and a domain. The split happens at the last at sign in the string, not the first, which is why an at sign can legally appear inside a quoted local part without confusing anything.

The limits are specific. The local part may be up to 64 characters. The domain may be up to 255. The practical ceiling on the whole address as it travels between mail servers is 254 characters, and that is the number worth storing and worth designing around. You will see 320 quoted in vendor articles; it is the two part limits added together plus the at sign, and no mail path actually carries it. Anything you build or validate against 320 is validating against arithmetic rather than against reality.

3. A whole set of legal characters is refused nearly everywhere

Letters, digits, dot, hyphen and underscore travel fine. Beyond them the specification also permits a collection of punctuation in the local part, among them !#$%&'*+-/=?^_{|}~, and it permits the entire local part to be wrapped in quotes so that spaces and other awkward characters can appear inside.

In practice most forms accept a fraction of that. An apostrophe is the one that bites real people rather than test suites, because plenty of surnames contain one. The plus sign is legal and widely refused. Quoted local parts are legal and refused almost universally. None of this makes those addresses wrong; it makes them unlucky, and the people who own them learn to carry a second, blander address for hostile forms.

4. Case survives in the standard and vanishes in practice

By the letter of the specification the local part is case sensitive, so Sam@example.com and sam@example.com are two different addresses and the receiving server decides whether to treat them alike. Every large provider treats them alike, which is why nobody has ever noticed.

Two consequences follow. Write your address in lowercase and stop thinking about it: you will never be worse off. And if you are on the other side of this, building the form rather than filling it, the same ambiguity is what makes two accounts appear on what the user believes is one address, which is the reason storing and comparing addresses needs a normalised copy.

5. The domain half outgrew the rules most forms were written against

A great many validators still assume the part after the final dot is two or three letters. That assumption expired years ago. Long suffixes are ordinary now, and a domain can be written in a non-Latin script entirely, which a check built around plain ASCII will reject without hesitation.

The result is a class of address that is perfectly deliverable and structurally unable to get through certain forms. There is no trick that helps here. The domain is not something you can rephrase.

6. Forms end up stricter than the standard because strictness is cheaper

Fully implementing the specification is difficult, and almost nobody needs it. A short pattern that matches the addresses the author has personally seen takes five minutes, passes the test cases the author thought of, and ships. The bill is paid entirely by users whose addresses are unusual, and those users are rare enough that nobody in the room notices them.

That is not carelessness so much as a rational trade made by someone who will never meet the people it costs. It is also why the refusal you are staring at is rarely a decision about you. It is a decision about pattern maintenance, made before your address existed.

7. A refused address is usually fixed by changing its shape, not the service

When a live address is called invalid, four adjustments cover most cases. Drop the plus sign and anything after it. Remove dots from the local part. Type the address by hand rather than pasting it, because a copied string can carry a trailing space or an invisible character that survives the paste and breaks the match. And if the domain is the problem, use a different one, which on a disposable service means generating a new address rather than negotiating.

If the form responds to a refused address by demanding a phone number instead, that is a separate decision with its own trade-offs, and it is worth reading why the form wants a number at all before you supply one.

The handover

Control at this stage is split unusually. The standard decides what is legal and never changes its mind; the form decides what it will accept and never tells you why. You control only the shape of what you type, and once you type it the next thing to inspect the address is the check that runs inside your own browser, which is stricter than the standard and softer than the server. The name you put in front of the at sign is still yours to pick, and what that choice actually buys is a shorter question than this one. A fresh address in a form the standard likes is always one click away.