[avar]

Even things at the right side of the @ are up to the E-Mail server. You can send an E-mail to @gmail.com or @GMAIL.COM and Google could be routing it differently.

It'll resolve the same in DNS, but what the user typed will be encoded in E-Mail headers, and you could route differently depending on whether it's upper-case, mixed-case or whatever.

[written]

Not true, domain part is case insensitive by the standard.

Server can decide for non-standard behavior, but that would be foolish.

[thrill]

The name part, per the standard, is case sensitive. However, some organizations I get email from canonicalize it to all caps - and one even removes the dots(!) and all-cap it, which for my gmail I have a filter that sends all non-dotted email to spam, since 90% of my spam is non-dotted. Since that particular email was important and I'd just happened to notice it in spam, I checked the capitalization change and called them and even managed to get through to speak with their email manager. He absolutely insisted I was wrong about it mattering and said they wouldn't change it.

[chrsstrm]

Changing case could be a co's lazy way of checking for existing accounts. In a perfect world they would store the input as-is and also use a lower or upper func on the indexed col. I suppose if they are verifying emails with their users and not seeing a big drop-off in verified accounts, they probably don't care to be too exact. Removing dots from the user portion is pretty shitty though.

[avar]

The domain being in any case for the purpose of delivery is part of the standard, but there's nothing I know if which would prohibit you from implementing local delivery and routing in any way you want once the mail is accepted.

[written]

You have no guarantee that the domain part case is preserved from what the user wrote, if it's not defined to be case-sensitive. So you can do what you want, but the input data are not reliable.