Are Email Addresses Case Sensitive? A Practical Guide

Overview

Email addresses are only partly case-insensitive. The domain after the at sign is case-insensitive, so example.com and EXAMPLE.COM identify the same domain. The local part before the at sign is different: RFC 5321 says it must be treated as case sensitive, even though many large mailbox systems choose to deliver differently cased versions to the same mailbox.

The safe application rule is therefore not 'lowercase every email.' Preserve the address the user supplied, normalize the domain for lookup, and compare or canonicalize the local part only under a documented policy. A login system may deliberately offer case-insensitive account lookup, but that product decision should not silently rewrite outbound addresses or claim that every receiving provider treats local-part variants as identical.

Separate the protocol rule from provider behavior

RFC 5321 defines SMTP mailbox semantics. It states that the local part must be treated as case sensitive and gives smith, Smith, and SMITH as values that could identify different mailboxes. The same section discourages exploiting local-part case sensitivity because doing so impedes interoperability. For the domain, normal DNS and SMTP rules make letter case irrelevant.

Those two statements are not contradictory. The transport rule protects a receiving system's authority to distinguish local parts; the interoperability advice recognizes that surprising distinctions are operationally painful. A mailbox provider can decide that Alice and alice are equivalent for its own domain. An unrelated SaaS application cannot safely extend that decision to every domain on the internet.

• Do not use one blanket rule to describe both sides of the at sign
• Do not infer universal behavior from tests against one mailbox provider
• Preserve enough data to reverse a normalization-policy mistake
• Treat provider-specific canonicalization as versioned business logic

Store the original address and a deliberate comparison key

A robust data model separates presentation from lookup. Keep email_original as the address the user confirmed, parsed local_part and domain fields when useful, and an email_lookup_key derived by a documented function. At minimum, the lookup key can preserve the local part while lowercasing the domain. If your product intentionally makes account sign-in case-insensitive, use a separate account lookup key rather than mutating the delivery address.

This separation matters during migrations. If a historical system lowercased everything, the original distinction may already be lost. Do not pretend it can be reconstructed. Mark the provenance of imported values, identify collisions before adding a unique index, and require confirmation when two records collapse under a new comparison policy.

• Parse with a maintained address parser instead of splitting arbitrary header text
• Keep display names separate from mailbox addresses
• Version the function used to derive comparison keys
• Never rewrite an address merely to make a database uniqueness constraint convenient

Choose comparison semantics for each workflow

Different workflows answer different identity questions. Sending asks which mailbox string should be submitted to the provider. Login asks which internal account the claimant is trying to access. Contact deduplication asks whether two records should merge. Suppression asks whether an address should be blocked from another send. These decisions may share a parser, but they should not inherit one accidental lowercase operation.

For sending, preserve the confirmed delivery address. For sign-in, many products deliberately use a case-insensitive key to reduce lockouts, then prove control through a password, passkey, or magic link. For suppression and deduplication, start conservatively: normalize the domain, preserve the local part, and merge only when provider-specific evidence or user confirmation justifies a broader equivalence.

• Use an immutable contact or account ID as the primary identity
• Record why a merge or suppression match occurred
• Make address changes a verified workflow rather than an in-place typo fix
• Keep authentication comparison rules separate from SMTP delivery claims

Do not confuse case handling with alias normalization

Case folding is only one possible mailbox-provider behavior. Some providers also interpret dots, plus tags, aliases, or domain variants in provider-specific ways. Those are not general SMTP equivalence rules. Removing dots or plus suffixes across an entire contact database can combine unrelated mailboxes at providers where those characters are significant.

If a narrow product needs provider-aware canonicalization, scope each rule to domains the provider explicitly controls, document the source and purpose, preserve the submitted address, and test for changes. Even then, use the canonical form as a hint or abuse-control signal unless you can tolerate false matches. A marketing CRM, identity system, and fraud engine may appropriately make different decisions from the same hint.

• A plus tag is not universally disposable
• Dots can be meaningful in a local part
• Similar-looking domain names are not aliases without evidence
• A canonicalization hint is not proof that two users are the same person

1. Apply syntax parsing and domain case normalization universally.
2. Preserve the original local part and complete confirmed address.
3. Identify the responsible mailbox provider from controlled configuration, not display text.
4. Apply only that provider's documented alias rule for the specific workflow.
5. Retain the rule name and version alongside any derived canonical value.
6. Review collisions before merging records or transferring account access.

Migrate and test without creating identity collisions

Before changing a production normalization rule, compute proposed keys without writing them. Group collisions, count the workflows affected, and classify each group: duplicate record, provider alias, shared mailbox, distinct local-part case, malformed import, or unresolved. Resolve account and consent collisions manually when an automatic merge could transfer access or erase evidence.

Your test matrix should include same-domain case variants, domain-only case variants, plus and dot variants, ASCII and SMTPUTF8 local parts, malformed input, and addresses at a controlled test domain where you can deliberately configure case behavior. Exercise signup, login, magic links, imports, sends, bounces, replies, unsubscribes, suppressions, exports, and address changes.

1. Document the current parser, storage form, indexes, and comparison sites.
2. Implement one pure function for each intended comparison policy.
3. Backfill proposed keys into a temporary field or offline report.
4. Review every unique-key collision before enforcing a constraint.
5. Dual-read or shadow-compare during rollout and log policy disagreements safely.
6. Verify high-risk flows, then migrate writes and retain a rollback path.

Publish one operational policy that engineering and support can use

Write down what is preserved, what is normalized, which workflows use which key, how provider-specific rules are approved, and what happens on collision. Expose safe diagnostics to support: original address, normalized domain, policy version, confirmation state, and immutable contact or account ID. Avoid exposing full addresses in broad logs when a redacted value and stable ID will do.

Mailbase's relevant role is the workflow layer around contact, campaign, suppression, event, and reply records. Operators should preserve provider recipient IDs and the address associated with each send attempt instead of expecting a global lowercase rule to reconcile history. If upstream imports or identity systems canonicalize addresses, document that boundary before contacts enter campaigns or suppression workflows.

• Prefer immutable IDs over email strings as relational keys
• Audit normalization changes like schema migrations
• Preserve consent and suppression evidence through merges
• Escalate ambiguous collisions instead of guessing mailbox equivalence

Common Mistakes

• Choosing a tool before deciding who owns deliverability.
• Treating DNS authentication as a one-time checkbox instead of an operating baseline.
• Mixing product-critical transactional email with experimental marketing sends, with no clear boundary.
• Trusting headline metrics (like open rate) that privacy proxies now inflate.

Sources & Further Reading

Official docs for current setup details, pricing, and API behavior — verify specifics there, since they change.

Related guides

More on are email addresses case sensitive and the surrounding email infrastructure workflow:

FAQ

Related reading