Email Address Capitalization: What It Changes for Senders

An unsubscribe arrives from J.Doe@example.com. It gets written to the suppression list exactly as it was typed. Six weeks later the same person is sourced again, this time as j.doe@example.com, and the suppression check compares the two strings character by character and finds no match. The message goes out, and the second complaint is worse than the first.

That is the version of this question that costs a sending team something. Capitalization in an email address almost never decides whether a message is delivered. It decides whether two rows in your database are one person, and everything expensive about it happens on that side of the line.

What the standard actually says

The rules for the address itself are written down, and they are more interesting than the answer everyone repeats.

RFC 5321, the SMTP specification published by the RFC Editor and fetched for this article on 2 September 2026, splits the address in two and treats the halves differently. On the domain half it is unambiguous: "Mailbox domains follow normal DNS rules and are hence not case sensitive." Anything to the right of the at sign can be upper case, lower case or mixed, and it resolves to the same host.

On the half to the left of the at sign, the specification says the opposite of what the popular answer says. "The local-part of a mailbox MUST BE treated as case sensitive." It goes further and puts an obligation on software: "SMTP implementations MUST take care to preserve the case of mailbox local-parts." The same paragraph then names the practical consequence, that for some hosts the user smith is a different user from the user Smith.

The specification does not stop there, and the qualifier is the part worth carrying away: "exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged". So the standard permits a receiving host to distinguish two casings, tells every sender to preserve what it was given, and advises operators not to build anything that depends on the distinction.

Read as an instruction to a sending team, that is a clean rule. Send the address as you received it. Never re-case a local part on the way out, because the host that treats the two as different mailboxes is a host you cannot enumerate in advance.

RFC 5321The specification

• The domain half is not case sensitive
• The local part MUST BE treated as case sensitive
• Implementations MUST preserve the case they are given
• Depending on the distinction is discouraged

Google's Gmail helpWhat Google publishes

• Dots in a consumer Gmail address are ignored
• On a Workspace domain, dots do change the address
• The page fetched here settles dots and not capitalization
• A rule you cannot find on a vendor page is not a vendor fact

Microsoft Exchange Online docsWhere case is load-bearing

• The SMTP prefix on a proxy address carries meaning
• Upper case marks the primary address
• The mailbox name is not what that rule is about
• An admin who lower-cases the prefix changes behaviour

What the two providers you can actually read publish

The pages that rank for this question assert confidently that Gmail and Microsoft 365 ignore capitalization. Very few of them link to a page from either company that says so, and there is a reason for that.

Google's own help page, fetched on 2 September 2026, is titled "Dots don't matter in Gmail addresses" and answers the neighbouring question rather than this one. It says "If someone accidentally adds dots to your address when emailing you, you'll still get that email." and tells the reader "you own all dotted versions of your address". It also carries the clause that matters far more to anyone building a B2B list, which is that on a work or school domain "dots do change your address". The page fetched for this article does not carry a statement about capitalization, and a rule that cannot be found on a vendor surface is not a fact that belongs in an article as one.

Microsoft's Exchange Online documentation, on the page for adding and removing email addresses on a mailbox, last updated 2025-04-30 and fetched the same day, is where case turns out to be genuinely load-bearing in a Microsoft tenant. Describing the proxy address syntax, the page states that "The address with the case-sensitive qualifier SMTP is the primary SMTP address." The upper-case prefix marks the primary address and a lower-case prefix marks an alias. That is a rule about the protocol qualifier in front of the address rather than about the mailbox name, and an administrator who normalises the wrong string there changes which address a tenant sends from.

So the honest position for a sender is narrower than the SERP's. The standard settles the domain half and hands the local part to the receiving host. One provider publishes a dot-folding rule and a warning that it inverts on business domains. The other publishes a case rule about the prefix rather than the mailbox. Everything else circulating on this question is inference from observed behaviour, and observed behaviour is a reasonable basis for a sending decision as long as nobody dresses it up as documentation.

Delivery is not where this costs anything

In practice a message addressed to Firstname.Lastname at a company domain reaches the same mailbox as the lower-case version, and it does so at every provider an outbound team is likely to meet. That is an observation about how hosts are configured rather than a guarantee any of them publishes, and RFC 5321's own advice explains why it holds: an operator who made the two casings resolve to different mailboxes would be generating support tickets forever.

Which means the capitalization in an address is not a deliverability lever. It does not raise a spam score, it does not affect authentication, and it is not why a campaign landed in the junk folder. The things that decide placement are infrastructure and list quality, and the diagnosis order for a placement problem is set out in our guide to spam words and what actually triggers a filter.

Where casing genuinely costs money

Four comparisons happen in an ordinary outbound stack, and every one of them can be performed case-sensitively by accident.

Deduplication inside a list. Two sources hand you the same person under different casing and the upload treats them as two rows. That is how a single account receives the same campaign twice, which is the failure our email list cleaning page prices against the cost of the send.

Suppression and do-not-contact matching. This is the expensive one. A suppression list stores what it was given, a new list arrives cased differently, and a person who asked not to be contacted is contacted. Nothing in the send logs looks wrong afterwards.

Unsubscribe processing. The same failure wearing a compliance jacket. An unsubscribe is a promise about a person, not about a string, and a case-sensitive match breaks that promise silently.

Reply and bounce attribution. A reply arriving from a differently cased address fails to join back to the record that produced it, so the campaign under-reports its own results and the person stays in the sending pool.

A worked example, and these figures are invented to show the shape rather than measured on any real list. Take a list of 4,000 rows assembled from three sources. If 3 percent of the rows appear twice under different casing, an invented rate picked to show the shape, that is 120 duplicate sends into 120 accounts that were meant to receive one message each. None of those sends bounces, none of them fails, and the only visible symptom is a reply rate that looks slightly worse than it should.

1. Step 1Store the address exactly as supplied

   This is the string that gets sent to, because the standard tells implementations to preserve the case they were given.

2. Step 2Derive a comparison key beside it

   Lower-case the whole address into a second field. The key is what dedupe, suppression and reply matching read.

3. Step 3Match on the key, never on the raw value

   Every join in the stack uses the key, including the unsubscribe check and the do-not-contact list.

4. Step 4Send the stored original

   Re-casing an address before a send is the one behaviour the specification advises against, and it buys nothing.

The normalisation rule, and the one place it goes wrong

Lower-casing the domain is safe under the specification, which settles that half outright. Lower-casing the local part is safe as a comparison key and unwise as a replacement for the value you send.

One trap sits inside that rule. Because Google folds dots on consumer Gmail addresses, a comparison key that only lower-cases still reads the dotted and undotted spellings of the same consumer Gmail local part as two separate people, and at gmail.com they are one inbox. It is tempting to fold dots out of every key to fix that. Do not: Google's own page says dots do change the address on a work or school domain, and business lists are built on exactly those domains. Fold dots only for gmail.com itself, and leave every other domain alone.

The second trap is a verifier or CRM that normalises for you without saying so. A tool that silently lower-cases on import is doing the right thing to the key and the wrong thing to the value if it overwrites the original, and you will not find out until an address at one of the rare case-sensitive hosts stops resolving.

What to check before trusting your dedupe

• ✓Yes: Your verifier returns the same verdict for both casings of one address
• ✓Yes: Your sequencer treats the two casings as one contact on upload
• ✓Yes: The suppression import lower-cases before it compares
• ✓Yes: The unsubscribe handler matches case-insensitively
• ✓Yes: Reply and bounce events join back on the lower-cased key
• ✕No: Dots are folded out of every domain rather than gmail.com alone
• ~Depends: The stored original address survives import unchanged

Verification tooling deserves the same one-off check, and the wider question of what a verifier can and cannot settle for you is covered in our comparison of email verification tools. The tier that no verifier resolves in either casing is the accept-all one, described in catch-all domain.

The question people are usually asking

The pages ranking for this phrase answer two different questions, and the second one is about capitalization in a subject line or in body copy rather than in an address. There the answer is different and the stakes are real.

There, the house position is short. Writing in capitals is a reader problem before it is a filter problem, because it reads as shouting from a stranger, and a stranger has one sentence to sound like a person. Filters do not work from a word list either, which is the argument our subject line guidance and the placement diagnosis in spam words both make. If a campaign is landing badly, the address casing is not the variable to test; the bounce numbers to compare it against sit in our cold email bounce rate benchmarks.

The short version

Capitalization in an email address does not decide delivery, and the reason it does not is that receiving hosts choose not to make it decide delivery. RFC 5321 settles the domain half, then states that "The local-part of a mailbox MUST BE treated as case sensitive.", requires implementations to preserve the case they receive, and calls depending on the difference discouraged. Google publishes a dot-folding rule for consumer Gmail with a warning that it inverts on business domains, and the page fetched here settles nothing about case. Microsoft publishes a case-sensitive rule about the SMTP qualifier in front of a proxy address rather than about the mailbox name.

The operating rule that falls out of all three is one line. Preserve the address you were given for sending, derive a lower-cased key beside it, and run every dedupe, suppression, unsubscribe and reply match against the key. Teams that skip the second clause of that sentence do not get bounces. They get duplicate sends, a suppression list that quietly fails, and a reply rate that undercounts itself.

If you would rather have the list hygiene, the sending infrastructure and the suppression discipline built and run for you against your own market, start a free campaign and we will put the whole motion together.

RFC 5321 quotations are taken from the specification as served by rfc-editor.org and fetched on 2 September 2026. The Gmail rule is taken from Google's own help page, fetched the same day. The Exchange Online proxy address rule is taken from Microsoft's documentation page carrying a last updated date of 2025-04-30, fetched the same day. Verify current provider behaviour on the vendor's own pages before relying on it.