---
title: "Are email addresses case sensitive? Storage rules | Emvero"
description: "Email domains ignore letter case, but the part before @ can differ. Learn what to preserve when storing, checking and comparing email addresses."
url: https://emvero.io/blog/are-email-addresses-case-sensitive/
language: en
updated: 2026-10-18
---

Blog

# Are email addresses case sensitive?

Preserve the recipient's spelling, normalise the domain and choose account-matching rules separately.

Published 2026-10-18

Email addresses have two different rules for letter case. The domain after `@` is case insensitive. The local part before `@` can be case sensitive, depending on the receiving mail system. For an address you do not control, preserve that local part exactly and normalise only the domain.

For example, `Alex.Smith+orders@EXAMPLE.COM` can become `Alex.Smith+orders@example.com` without changing the domain’s meaning. Rewriting it as `alex.smith+orders@example.com` also changes the local part, so you cannot assume it still identifies the same recipient.

## The domain and local part follow different rules

[RFC 5321, section 2.4](https://www.rfc-editor.org/rfc/rfc5321.html#section-2.4) requires SMTP implementations to preserve local-part case and states that mailbox domains are case insensitive. It also discourages receiving systems from distinguishing mailboxes only by letter case because that makes interoperability harder.

A receiver may therefore deliver both `Alex@example.com` and `alex@example.com` to one mailbox. Another receiver may interpret them differently. The standard gives your application no universal rule that makes these two local parts equivalent.

Capital letters alone are not a format error. If a form rejects a mixed-case address, inspect the validator before asking the person to change it. The [email syntax guide](https://emvero.io/glossary/email-syntax/) explains the wider format constraints.

The examples below use synthetic ASCII addresses with DNS domains. They illustrate handling rules, not working mailboxes. Internationalised addresses and quoted local parts need a parser with explicit support; these examples are not a general email-parsing algorithm.

## Preserve the contact address when you store it

After validating the input, retain the local part for messages, verification requests and display. If you store a normalised address, use a parser that handles the domain separately. Lowercasing the whole string discards the original local-part spelling.

| Submitted address | Address with domain normalised | What remains unchanged |
| --- | --- | --- |
| `Alex@EXAMPLE.COM` | `Alex@example.com` | Local-part case |
| `Alex.Smith@example.com` | `Alex.Smith@example.com` | Case and dot |
| `Alex.Smith+orders@EXAMPLE.COM` | `Alex.Smith+orders@example.com` | Case, dot and plus tag |

Dots and plus tags have their own meaning at the receiving system. Keep them intact too. The [plus-addressing guide](https://emvero.io/blog/email-address-with-plus-sign/) covers validation and transmission of tagged addresses.

Emvero’s current address parser follows this distinction: it retains the local part and normalises the domain. That transformation alone says nothing about whether the mailbox exists.

## Store a contact address and a comparison value separately

An application can choose to match account identifiers without regard to case. That is an account policy with consequences for registration, sign-in and recovery. It does not establish how an external mail server interprets the address.

For case-insensitive account matching, store a comparison value alongside the contact address. A lowercase comparison value can help find a possible existing account while the contact field still contains `Alex.Smith+orders@example.com`. Check the database’s comparison rules as well as the application code; both must implement the policy you chose.

A comparison match must not automatically merge two existing accounts or grant access to either one. Resolve a collision through the product’s authenticated recovery or account-linking process. When sending a recovery message for an existing account, use its established contact address rather than replacing it with a new spelling from a lookup request.

Use the same matching policy across registration and sign-in. Otherwise a form may accept an address that the next step cannot find. Document what happens when an address differs only in local-part case. If your application permits only one account for those variants, explain that restriction when a second registration is attempted.

## If your records are already lowercase

Lowercasing is not reversible: a stored `alex@example.com` does not reveal whether the person originally entered `Alex@example.com`. Do not guess capitalisation from a person’s name or overwrite contact records in bulk.

Keep the current value until you have a reason to correct it. If the person reports a problem, let them provide the intended address through your normal contact-change process and confirm control where required. Successful delivery to the lowercase value does not reconstruct the spelling that was lost.

Before introducing a new comparison rule, inspect records that would collide under it. Plan how each collision will be resolved without silently combining contact history or account access.

## Test the paths that use the address

Use synthetic records to check these scenarios in your application:

- Changing `EXAMPLE.COM` to `example.com` keeps the local part intact through storage and retrieval.
- `Alex@example.com` and `alex@example.com` follow the account-matching policy you documented; any collision has an explicit outcome.
- `Alex.Smith+orders@example.com` retains its case, dot and tag in the contact field and the verification request.
- Registration, sign-in and recovery use the same comparison rule. Recovery uses the stored contact address for the account it finds.
- A migration identifies conflicting comparison values before it changes records.

These are regression scenarios for your integration. They do not test delivery or prove that two variants reach the same mailbox.

## Verify the address you intend to contact

Pass the address with its preserved local part to verification. Changing the case first would check a different input. If the result is `unknown`, the evidence is inconclusive; lowercasing and trying again is not a general fix for uncertainty.

Verification also does not establish who controls the mailbox. Send your own confirmation message when control matters. Emvero does not send that message; the [verification and confirmation comparison](https://emvero.io/blog/email-verification-vs-email-confirmation/) explains the distinction.

Use the [email verification API](https://emvero.io/email-verification-api/) from your server after the address has reached it with its local part intact.

## Terms used here

### Email address syntax

The format rules for an email address; passing them does not establish that the domain or mailbox exists.

## Situations this applies to

### Validating an address in a signup form

Somebody is waiting on the other side of the request, so latency decides the design and a wrong rejection costs you the customer.

### Cleaning a CRM without deleting good records

A CRM record is a history, not an address, so nothing here deletes anything - verification decides what you may send, never what you may keep.

[All articles](https://emvero.io/blog/)

## Choose what to check next.

Run a check from your account and inspect the evidence in its result.

Start for free