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 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 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 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.COMtoexample.comkeeps the local part intact through storage and retrieval. Alex@example.comandalex@example.comfollow the account-matching policy you documented; any collision has an explicit outcome.Alex.Smith+orders@example.comretains 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 explains the distinction.
Use the email verification API from your server after the address has reached it with its local part intact.