Are Email Addresses Case Sensitive? The 2026 Answer

TL;DR

• The domain part of an email address (everything after the @) is never case sensitive — Gmail.com and gmail.com are identical by DNS rules.
• The local part (before the @) can be case sensitive under the RFC, but in practice virtually no mail provider treats it that way.
• Gmail, Outlook, Yahoo, and almost every business mail server fold the local part to be case-insensitive, so John.Doe@acme.com and john.doe@acme.com reach the same inbox.
• For storage, comparison, and deduplication you should normalize to lowercase — relying on case to make addresses unique is a bug waiting to happen.
• When you verify or enrich a list, case differences should collapse to one canonical record; a good email verifier does this for you.

What does "case sensitive" actually mean for an email?#

Short answer: an email address has two halves, and only one of them is even theoretically case sensitive — and that half is treated as case-insensitive by essentially every mailbox you will ever send to.

Think of an email address like a street address on an envelope. The city and country (the domain) are standardized by a global directory, so "NEW YORK" and "new york" route to the same place. The apartment number and resident name (the local part) are interpreted by the local post office — and almost every post office decided long ago to stop caring about capitalization. So while the rulebook permits a building to treat "Apt 4b" and "Apt 4B" as different units, no real building does.

An address splits at the @:

john.doe @ example.com
└ local ┘  └─ domain ─┘

• Local part — the mailbox name. The standard says this may be case sensitive.
• Domain — the host. Domain names are case-insensitive everywhere, full stop.

That single split is the whole story. Everything below is just the difference between what the specification allows and what mail servers actually do.

Are email addresses case sensitive according to the RFC?#

Technically, the local part can be case sensitive — but the standard itself tells you not to rely on it.

The governing document is RFC 5321, the SMTP specification. It draws the line exactly where you'd expect:

The local-part of a mailbox MUST BE treated as case sensitive... However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged.

Read that twice. The RFC grants mail servers permission to distinguish Bob from bob in the local part — and then, in the same breath, says doing so is a bad idea that breaks interoperability. The domain part gets no such allowance: per the DNS specifications it is always case-insensitive.

So the precise, pedantic answer to "are email addresses case sensitive" is:

• Domain: never case sensitive.
• Local part: allowed to be, but discouraged from being, and almost never is.

That gap between "allowed" and "actually done" is where most confusion lives. Engineers read "MUST BE treated as case sensitive," panic, and start storing John@x.com and john@x.com as two separate users. Then real mailboxes — which fold case — deliver both messages to one person, and the data model falls apart.

Do Gmail, Outlook, and Yahoo treat email as case sensitive?#

No. Every major consumer and business provider treats the local part as case-insensitive, so capitalization changes nothing about delivery.

You can test this yourself in thirty seconds: email YOURNAME@gmail.com and yourname@gmail.com — both land in the same inbox. Here's how the big providers actually behave:

Two takeaways from that table:

1. Case never matters across any mainstream provider. That column is uniformly "No."
2. Other normalization rules differ. Gmail famously ignores dots in the local part, so john.doe@gmail.com and johndoe@gmail.com are the same mailbox — but that's a Gmail-specific rule, not a universal one. Don't confuse "case-insensitive" (true everywhere) with "dots don't matter" (true only at Gmail). Google's own documentation spells this out.

The practical upshot: if your app rejects a login because the user typed Jane@Company.com instead of jane@company.com, that's your bug, not theirs.

Why does the domain part ignore case but the local part doesn't have to?#

Because two different standards bodies own the two halves, and they made different rules.

The domain is governed by DNS, and DNS resolution is case-insensitive by design — EXAMPLE.COM, Example.com, and example.com all resolve to the same nameservers. There is no universe in which changing the case of the domain changes where mail goes. This is the same reason you can type a website URL in any case and still land on the page; the domain name system folds case before lookup.

The local part, by contrast, is owned by the receiving mail server, not by any global directory. The SMTP authors couldn't guarantee what every mail server on earth would do with Bob vs bob, so they played it safe and said "treat it as significant" — while strongly hinting that no sane operator should. In effect, the RFC delegated the decision, and the entire industry independently chose case-insensitivity.

Should you store email addresses in lowercase?#

Yes — normalize to lowercase on input, and treat that normalized form as the unique key. This is the single most important practical decision in this whole topic.

Here's the trap. Because real mailboxes fold case, these three strings all deliver to the same person:

John.Doe@Acme.com
john.doe@acme.com
JOHN.DOE@ACME.COM

If your database stores them verbatim and uses a case-sensitive unique index, you'll happily create three "different" accounts, three CRM contacts, and three newsletter subscribers for one human. Then you'll email them three times, trip spam filters, and pollute every downstream report.

A defensible normalization policy looks like this:

The nuance: deliver using the address as captured, but compare, deduplicate, and index on the lowercase form. You lose nothing — because the receiving server is going to fold case anyway — and you gain a clean, collision-free data model. If you maintain a B2B database or run outbound at scale, this one rule prevents a mountain of duplicate-contact cleanup later.

How does case sensitivity affect email verification and deduplication?#

Case shouldn't change a verification result — and if it does in your pipeline, your normalization is happening in the wrong place.

When you run an address through verification, the checks that matter are syntax validity, domain MX records, mailbox existence (via SMTP probing), and whether the domain is a catch-all. None of those depend on the case of the local part, because the mail server you're probing folds case before it answers. So Sales@Stripe.com and sales@stripe.com should always return the same verdict.

Where case does bite you is deduplication before verification. If you feed a bulk verify job a list where the same address appears in five capitalizations, a naive system burns five credits checking one mailbox. Normalize first, then verify once.

A clean list-hygiene flow:

1. Lowercase everything — both halves of every address.
2. Remove exact duplicates on the normalized form. (A remove duplicates pass handles this.)
3. Verify the survivors with an email verifier to drop invalid, risky, and catch-all addresses.
4. Store the canonical lowercase form as your unique key.

If you're finding addresses rather than cleaning them — say, pulling contacts from a company domain — the same logic applies on the way in. Whether you use the email finder or a domain search, normalize the returned address to lowercase before it touches your CRM so you never create a case-variant duplicate.

What about "plus addressing" and dots — are those case sensitive too?#

No, and it's worth separating these features from case because people lump them together.

• Case: universally insensitive in practice. A@x.com = a@x.com.
• Plus-addressing (user+anything@domain.com): a subaddressing feature. The +tag is usually stripped or ignored for routing, so you+news@gmail.com reaches you@gmail.com. Great for filtering, but the tag itself is case-preserving as a literal string in many systems.
• Dots (j.o.h.n@gmail.com): Gmail-only quirk. Ignored at Gmail, significant nearly everywhere else.

The reason this matters: if you're deduplicating aggressively, you might be tempted to strip +tags and dots to find the "real" mailbox. That's safe for Gmail but wrong for Outlook, Yahoo, and most corporate servers, where john.doe@ and johndoe@ can be two different people. Case folding is the only normalization that's safe across every provider. Everything else is provider-specific — verify, don't assume.

Quick reference: the rules in one place#

The bottom line#

Are email addresses case sensitive? For every practical purpose in 2026: no. The domain half is case-insensitive by the laws of DNS, and the local half — while the RFC technically permits case sensitivity — is folded to case-insensitive by every mailbox provider that matters. The only safe engineering move is to normalize addresses to lowercase, use that form as your unique key, and stop worrying about capitalization.

The bigger risk isn't case — it's the duplicate, mistyped, and dead addresses hiding in your list once you collapse case. That's where verification earns its keep. Run your contacts through the Tomba Email Finder to source clean, correctly formatted addresses, then validate them with Tomba's verifier before they hit your sequences. Start on the free tier (25 searches a month), and see full Tomba pricing when you're ready to scale to bulk lists. Normalize once, verify once, and never email the same person three times because someone hit the shift key.