Are Email Addresses Case Sensitive? The Short and Long Answer

No in practice, and yes on paper. The part after the @ is never case sensitive: Example.com and example.com are the same domain, because the DNS does not distinguish them. The part before the @ is where the real answer lives. The SMTP standard says a receiving server is allowed to treat Ash and ash as two different mailboxes, and that every server relaying the message must preserve the case it was given. But almost nobody has exercised that right in decades. Gmail, Outlook, iCloud, Proton, Fastmail and our own mail server all fold the local part to one case before deciding which mailbox it belongs to. So if you typed your address with a capital letter, that is not why a message failed to arrive. And if you are writing code, the rule follows directly: compare addresses case-insensitively, keep one canonical form for lookups, and never let two accounts exist that differ only by case.

Are email addresses case sensitive?

An email address has two halves, and they get two different answers.

The domain, everything after the @, is not case sensitive. Domain names are resolved through the DNS, which has compared names case-insensitively since it was specified. Mail.Example.Com and mail.example.com are the same place, and every mail server on the internet agrees. There is no edge case here.

The local part, everything before the @, is technically case sensitive. RFC 5321, the document that defines how mail moves between servers, is unusually direct about it. Section 2.3.11 says the local part “MUST BE treated as case sensitive”, that implementations “MUST take care to preserve the case of mailbox local-parts”, and gives the example that on some hosts the user smith is a different person from the user Smith. Then, in the next sentence, it says that “exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged”.

Those two sentences are the whole situation. The standard permits case sensitivity, forbids intermediate servers from erasing it, and advises everyone not to depend on it. The server at the far end decides, and the servers at the far end have all decided the same way.

Is the part before the @ case sensitive?

Technically yes, and the reason is worth knowing before you dismiss it.

The local part is opaque to everyone except the destination: RFC 5321 says it is interpreted only by the host named in the domain. On the early internet a mailbox was very often a login on a Unix machine, and Unix logins are case sensitive, so smith and Smith could genuinely be two people. The standard could not declare the local part case-insensitive without breaking real systems, and it still does not.

Practically no. Every large consumer and business provider folds case when it looks up a mailbox. John.Smith@gmail.com and john.smith@gmail.com are one Gmail account, and the same holds at Outlook, iCloud, Proton, Fastmail and the default configuration of every common mail server. A case-sensitive mailbox loses mail whenever someone types the address on a phone, reads it aloud or copies it from a business card, and nobody who runs mail at scale wants that. The standard itself makes one exception in the same direction: postmaster must be accepted however it is capitalised, because a problem report that bounced on a capital P would defeat its purpose.

Why do the standard and real servers disagree?

Because they are solving different problems.

The standard is a contract between arbitrary systems, some of which map mailboxes onto case-sensitive accounts, so it has to permit case sensitivity. Providers run a service for people, and people do not think of Ash and ash as different words. They capitalise the first letter because a form or a mobile keyboard did it for them, or because it looked tidier. A server that honoured the distinction would bounce or lose every one of those messages.

So every provider reached the same resolution: preserve case on the wire, as the standard demands, and fold it when resolving the mailbox, which the standard allows. The division matters if you run a mail system. A server in the middle must not rewrite Ash@ to ash@, because the rare destination that cares would deliver to the wrong person; your own lookup, on your own server, should fold case, because that is what every user expects.

What does our own mail server do with capital letters?

We run a mail server that receives real messages from the public internet, so we have to make this decision rather than describe it.

When a message arrives, the recipient address in the delivery command is lowercased before the server works out which inbox it belongs to, and the sender’s address is lowercased on the way in as well. Every key the server uses to find, store and list mail is built from that lowercased form. Ash@, ash@ and ASH@ are one inbox; there is no path through the system where capitalisation could separate them.

The reason is the one above, with a twist: our addresses are generated rather than chosen, and people copy them by hand into forms they do not control, some of which capitalise the first letter automatically. Folding case on receipt is the only behaviour that makes the message arrive regardless. Pokemail generates the local part for you at random and lowercases it on receipt, so there is no way to end up with two addresses that differ only by case.

Does Gmail ignore dots in an email address?

Yes, for addresses ending in @gmail.com. Google does not treat a full stop as a character in a Gmail username, so j.smith@gmail.com, js.mith@gmail.com and jsmith@gmail.com are the same account and mail to any of them lands in the same inbox. Capitalisation is ignored in the same way, and @googlemail.com is interchangeable with @gmail.com.

Two things about this are regularly misunderstood. It is a Gmail policy, not a rule of email: most providers treat dots as significant, and Proton goes the other way and ignores dots, hyphens and underscores in its own addresses, so there is no general rule you can apply to an address you did not issue. And Google documents the behaviour for consumer @gmail.com accounts; on Google Workspace addresses at a company’s own domain, dots are part of the address, so a validator that strips dots from anything Google-hosted will merge people who should stay distinct.

One side effect: any dotted spelling of your address that someone else types delivers to you, which is why Gmail users occasionally receive mail meant for a person with a similar name. Nothing has been breached; it is the same inbox under another spelling. Dots are one of two address features Gmail treats this way, and the other one, the +tag suffix, has quite different consequences for privacy; both are covered in the Gmail dot trick and plus addressing.

What characters can an email address contain?

More than most signup forms accept, and fewer than most people assume.

In the local part, the standard permits letters, digits and this punctuation: ! # $ % & ' * + - / = ? ^ _ \ { | } ~, plus the full stop, provided it is not first, last or doubled. All of that is legal in a plain local part with no quoting. A second, quoted form written inside double quotes permits still more, including spaces and @`, but it is so rarely used that many systems mishandle it and no major provider will issue you such an address.

Providers restrict the set for their own accounts: Gmail usernames may contain only letters, digits and full stops and must be six to thirty characters long. What you can register is always a subset of what the standard allows, which is why a validator written to one provider’s rules wrongly rejects addresses from everywhere else.

In the domain, each label may contain letters, digits and hyphens, may not begin or end with a hyphen, and may be at most sixty-three characters; internationalised names are encoded into that alphabet first. Non-ASCII local parts are permitted by a later extension, RFC 6531, but support is uneven and an address that depends on it will not work everywhere.

Can an email address contain a space?

Only inside a quoted local part. "john smith"@example.com is a valid address under RFC 5322, because the quotes turn the space into an ordinary character. In practice no consumer provider issues one, most forms reject it and plenty of mail software mishandles it. If a user types a space into an address field, assume a typo rather than a quoted string, and strip it or ask them to check.

How long can an email address be?

Two hundred and fifty-four characters in total. The standard limits the local part to 64 characters and the domain to 255, which is where the widely quoted figure of 320 comes from, but it also limits the whole address as written in the delivery command to 256 characters including the angle brackets around it. Remove the brackets and 254 is the most an address can be and still be deliverable everywhere. Real addresses are far shorter, and providers cap their own usernames well below the standard, so rejecting anything over 254 is generous rather than strict.

Should I lowercase email addresses in my database?

Yes, for comparison. The precise rule is worth stating in full, because the details are where accounts get duplicated and mail gets lost.

Lowercase the domain unconditionally. No system anywhere treats it as case sensitive, so there is nothing to preserve.

For the local part, compare case-insensitively but keep what the user gave you. Store the address as entered, for display and sending, and build your uniqueness check and login lookup on a lowercased copy: in PostgreSQL, a unique index on lower(email) or a citext column. Never let two accounts exist that differ only by case. If Ash@example.com registers and ash@example.com later tries to, they are the same person until proven otherwise, and letting the second through creates a duplicate nobody finds until a password reset goes to the wrong one.

Do not strip dots or plus tags by default. That is Gmail’s behaviour on Gmail’s domain; applied to other providers, or to Google Workspace addresses, it merges distinct users. If you want to detect duplicate Gmail accounts specifically, make it a deliberate product decision with an explicit provider check, not a normalisation step.

The same rule applies inside a test suite. If you generate addresses programmatically and later assert that your application stored the right one, fold both sides before comparing, or a capitalised local part will fail a test that is actually passing. Our temp mail API guide covers the generate-and-read loop that kind of test is built on.

When you send, send the address as entered. Relays are required to preserve case, and the rare destination that treats the local part as case sensitive does exist. Folding on your side for lookup costs nothing; folding on the wire can misdeliver.

Keep validation loose and let delivery be the real test. One @ with something on either side, surrounding whitespace trimmed, nothing over 254 characters: that accepts every valid address. Anything stricter, especially a regular expression that excludes + or insists on a particular top-level domain, turns away real people. The only validator that proves an address works is sending a message to it and watching it arrive.