Are email addresses case sensitive? What RFC 5321 actually says

RFC 5321, the SMTP specification, states that the local part of an email address (everything before the @) is technically case sensitive and that interpretation is up to the receiving mail server. The domain part (after the @) is never case sensitive, because domain names themselves are defined as case-insensitive in DNS. In practice, almost no provider enforces case sensitivity on the local part either, but the specification leaves room for it.

What the spec actually says

• Local part (john.smith in john.smith@example.com): case sensitivity is implementation-defined. The receiving server's mailbox system decides whether John.Smith and john.smith are the same inbox.
• Domain part (example.com): always case-insensitive, by DNS design. EXAMPLE.com and example.com are the same domain, full stop.

How major providers actually handle it

Why this still matters practically

• List deduplication: if you're deduplicating an email list programmatically, lowercase every address before comparing - otherwise Jane@Example.com and jane@example.com will be treated as two different contacts even though they're the same mailbox everywhere that matters.
• Validation logic: don't write validation that rejects or flags mixed-case local parts as invalid - they're valid syntax and the overwhelming majority of real addresses using mixed case are genuine, deliverable mailboxes.
• Display versus delivery: a signup form that preserves a user's capitalization for display (showing "John.Smith@example.com" in their profile) while normalizing to lowercase for actual sending and deduplication avoids both problems at once.

What not to do

• Don't build deduplication or suppression-list matching that's case-sensitive - you'll end up with duplicate entries for the same real inbox and send to a suppressed address under a different capitalization.
• Don't assume the domain part can ever meaningfully differ by case - treating EXAMPLE.COM as a different domain from example.com is simply incorrect.
• Don't rely on case as a way to create "separate" addresses for filtering purposes (unlike plus-addressing, which genuinely works for this) - most providers will route both cases to the same inbox regardless of what you intended.

Where case sensitivity could theoretically still bite you

Two narrow situations are worth knowing even though they're rare in practice:

• Self-hosted mail servers with custom mailbox logic: a system administrator running their own mail transfer agent can configure case-sensitive local-part matching, since RFC 5321 permits it explicitly. This is unusual, but not impossible, on custom corporate infrastructure rather than any consumer webmail provider.
• API integrations that treat the local part as an opaque string: some internal systems compare email addresses as raw strings without lowercasing first, which can create a bug where the same real mailbox is treated as two different records purely due to capitalization differences at signup versus a later login.

A quick reference for building your own validation

The practical takeaway is simple even though the specification is more permissive than most people assume: normalize to lowercase for anything comparing or deduplicating addresses, and don't build validation logic that second-guesses a legitimately mixed-case address as malformed.

One more edge case: internationalized email addresses

Modern email standards (RFC 6531 and related extensions) permit non-ASCII characters in both the local part and domain of an address, to support languages beyond ASCII-based scripts. Support for these internationalized addresses varies meaningfully by provider and by the sending platform you use - some systems handle them cleanly end to end, others mangle or reject them at some point in the pipeline. This is a separate issue from case sensitivity, but it's worth knowing about if you operate in markets where non-ASCII local parts are common, since validation logic that only expects standard ASCII characters will incorrectly reject otherwise valid addresses.

MailPilot normalizes address casing automatically when managing seed-list and connected-mailbox records, so a list import with inconsistent capitalization doesn't create phantom duplicate mailboxes in reporting.