Are Email Addresses Case-Sensitive? What It Means for Your Contact List

The technical answer and the practical answer to this question point in different directions, and getting it wrong costs you clean list hygiene before a single email goes out. Here's what the email spec actually says, what Gmail, Outlook, and every major provider actually do, and how to normalize and deduplicate a B2B contact list so you're not treating John.Smith@acme.com and john.smith@acme.com as two different people — or worse, sending the same prospect two emails from two different sequences.

What the spec actually says

RFC 5321, the technical standard that defines how email addresses work, splits an address into two parts with different rules. The domain part — everything after the @ — is explicitly case-insensitive, because domain names themselves are case-insensitive by DNS design; ACME.com and acme.com always resolve to the same place. The local part — everything before the @ — is technically left case-sensitive by the spec, meaning John.Smith and john.smith are permitted to be treated as different mailboxes by a receiving server.

That technical permission is almost never exercised. The spec's own guidance recommends against relying on case sensitivity precisely because it causes confusion, and in the decades since, mail providers converged on a single practical behavior: ignore case in the local part too. The result is a gap between what's technically allowed and what actually happens in the wild — a gap that trips up a lot of list-hygiene logic built by someone who read the spec literally.

What mail providers actually do

Gmail, Outlook/Microsoft 365, Yahoo, and the vast majority of corporate mail systems running on standard mail transfer software all treat the local part as case-insensitive for delivery purposes. john.smith@company.com, John.Smith@company.com, and JOHN.SMITH@company.com all land in the identical mailbox on every mainstream provider. This is true regardless of how the address holder originally typed or shared their own address — the mailbox itself doesn't distinguish.

This matters for two reasons in B2B outreach. First, delivery works either way — you won't get a bounce or misroute from sending to a differently-cased version of a correct address, so case mismatches aren't a deliverability risk in the technical sense. Second, and more relevant to list hygiene, treating case-different addresses as separate contacts creates false duplicates in your CRM, which leads to the same person receiving two different sequences, being counted twice in list-size or coverage metrics, and showing up as two separate records when you're trying to check for existing relationship history before a new campaign.

Normalizing addresses before they enter your list

The safe, standard practice for B2B contact data is to lowercase the entire email address — both local part and domain — at the point of ingestion, before storage or deduplication logic runs. This single normalization step eliminates the most common source of case-based duplicate records without any risk, because it aligns your data model with how every mainstream mail provider already treats the address.

Normalize at ingestion, not just at send time. If case-mixed variants are already sitting in your CRM from imports, scraped lists, or manual entry, a differently-cased duplicate can silently coexist with the canonical record for months, with the two versions independently accumulating different activity history — one shows a reply, the other doesn't, and neither view is complete. Run a one-time normalization and merge pass across the existing database, then enforce lowercase-on-write going forward so the problem doesn't recur.

Case normalization should happen before any duplicate-detection logic runs, not as a special case inside it. If your matching logic checks "is this the same address" using an exact string comparison on raw input, two correct records for the same person will pass as distinct every time a source capitalizes differently — which happens constantly across imports from different tools, manual entry, and scraped sources.

Case is one trap among several — don't stop there

Case normalization solves one dedup problem but leaves several others that behave differently and need separate handling. Gmail specifically ignores dots in the local part of its addresses, so john.smith@gmail.com and johnsmith@gmail.com route to the same inbox — but this is a Gmail-specific behavior, not a general email standard, and applying dot-stripping to a non-Gmail address will incorrectly merge two genuinely different people.

Plus-addressing (john+newsletter@company.com) is another provider-side convention, supported by Gmail and several other providers, where everything after a plus sign up to the @ is ignored for routing but preserved for filtering on the recipient's end. Treating john+sales@company.com and john@company.com as different contacts is usually wrong for CRM purposes, but stripping plus tags requires deliberate logic, not the same lowercase pass used for case.

Typo domains are the trap in the opposite direction: gmial.com, gmai.com, and similar near-misses of common providers are not duplicates of anything — they're either dead addresses from a typo at data-entry time or, occasionally, evidence of a deliberately fake address. These need typo-correction or validation logic, not merge logic, and merging them into a real Gmail record would corrupt otherwise-clean data.

• Lowercase the full address (local part and domain) at ingestion — safe, universal.
• Gmail dot-insensitivity — only apply dot-stripping to @gmail.com and @googlemail.com addresses specifically.
• Plus-tag stripping (+anything before @) — provider-dependent; strip for dedup, but keep the original for delivery.
• Typo domains (gmial.com, yaho.com) — flag for correction or removal, never auto-merge into a real domain.
• Trailing whitespace and invisible characters from copy-paste imports — trim before any comparison runs.

Why this matters more for cold outreach than for a newsletter

A newsletter with a duplicate subscriber record mostly just means one person receives two copies of the same email — annoying, rarely damaging. In targeted B2B cold outreach, the stakes are different: a duplicate contact record from a case mismatch can enroll the same real person in two different sequences with two different angles, arriving days apart from what looks, to them, like the same company contacting them twice with unrelated pitches. That reads as sloppy at best and as a genuine spam pattern at worst, and it's a self-inflicted version of exactly the perception LDM's approach to address-based outreach is built to avoid.

It also corrupts your own metrics. If a prospect who replied under one cased variant of their address shows as "no reply" under the duplicate record, your reply-rate reporting understates performance and your suppression logic can fail to catch them — meaning a contact who explicitly asked to be removed under one record variant can still get contacted under the other. Clean normalization isn't just tidiness; it's what makes suppression, consent tracking, and performance metrics trustworthy at all, which matters directly for staying inside GDPR consent-handling expectations for any EU contacts on the list.

Build the normalization and merge pass as a standing step in your list-import pipeline, not a one-off cleanup project. Every new import — a scraped list, a conference badge scan, a manual CSV upload — is a fresh opportunity to reintroduce case-variant duplicates if the check isn't automatic.

FAQ