이메일 주소는 대소문자를 구분합니까?

이메일 주소는 대부분 대소문자를 구분하지 않습니다. John.Smith@gmail.com으로 입력하든 john.smith@gmail.com으로 입력하든 메일은 같은 받은편지함에 도착합니다. @ 뒤의 부분은 대문자를 전혀 구분하지 않습니다. 주의할 부분은 @ 앞입니다. 이메일 표준상으로는 서버가 Smith와 smith를 서로 다른 사람으로 처리해도 됩니다. 가입 양식이나 메일링 리스트를 운영한다면 알아 둘 만한 내용입니다.

@ 뒤의 도메인: 대소문자 구분 없음

@ 기호 뒤에 오는 도메인 이름은 대소문자를 구분하지 않습니다. RFC 5321에 따르면 메일함 도메인은 일반 DNS 규칙을 따르며, DNS는 대소문자를 무시합니다. 따라서 GMAIL.COM, Gmail.com, gmail.com은 정확히 같은 메일 서버를 가리킵니다. 도메인을 대문자로 입력하든 소문자로 입력하든 메일이 가는 곳은 바뀌지 않습니다.

@ 앞부분의 이메일 대소문자 구분

로컬 파트, 즉 @ 왼쪽의 사용자 이름은 다르게 작동합니다. RFC 5321 2.4절은 “메일함의 로컬 파트는 대소문자를 구분하는 것으로 처리해야 한다(MUST BE treated as case sensitive)”고 규정합니다. 메일을 전달하는 서버는 대문자와 소문자를 쓰인 그대로 유지해야 합니다. Smith와 smith가 서로 다른 사람인지는 메일함을 보관하는 수신 서버가 결정합니다.

같은 절은 “메일함 로컬 파트의 대소문자 구분을 이용하면 상호 운용성을 해치므로 권장하지 않는다”고도 경고합니다. 한 회사에 JSmith@ 주소와 jsmith@ 주소를 쓰는 두 직원이 있다고 생각해 보십시오. 두 사람의 메일이 얼마나 자주 섞일지 짐작할 수 있습니다. 대형 메일 서비스 제공업체는 대소문자를 아예 무시하는 방식으로 이 문제를 피합니다.

Gmail과 Outlook

일반 사용자 메일의 대부분을 처리하는 제공업체는 대소문자를 완전히 무시하기로 했습니다. Gmail 도움말 커뮤니티의 제품 전문가들은 Gmail이 계정을 만들 때와 메일을 받을 때 모두 대문자를 무시한다고 확인합니다. 누군가 JaneDoe@gmail.com으로 보내든 janedoe@gmail.com으로 보내든 Google은 두 메일을 같은 메일함에 전달합니다. Google은 @googlemail.com과 @gmail.com도 같은 주소로 처리합니다.

Gmail은 개인 주소의 점(.)도 무시합니다. 그래서 jane.doe@gmail.com과 janedoe@gmail.com은 같은 받은편지함에 도착합니다. 하지만 이 규칙이 모든 곳에 적용된다고 생각하면 안 됩니다. Google 문서에 따르면 직장이나 학교 도메인으로 관리되는 Google Workspace 계정에서는 점이 의미가 있습니다. 점과 대문자는 별개의 규칙입니다. Gmail이 점을 무시한다고 해서 다른 제공업체도 점을 무시한다고 생각하지 마십시오.

Microsoft의 답도 비슷합니다. Microsoft 지원 포럼의 한 답변은 @ 뒤의 부분은 대소문자를 구분하지 않고, 사용자 이름의 대소문자 구분은 제공업체에 따라 다르며, Outlook과 Gmail 같은 대형 제공업체는 이를 무시한다고 설명합니다. 같은 답변은 대소문자를 구분하는 자체 서버를 운영하는 회사도 일부 있다고 덧붙입니다.

대문자가 여전히 문제가 되는 경우

문제는 주로 로그인에서 생깁니다. 휴대폰 키보드가 첫 글자를 대문자로 바꿔 Sarah@example.com으로 가입하고, 나중에 sarah@example.com으로 입력해 로그인하면, 단순한 시스템은 계정을 찾을 수 없다고 표시합니다. 사용자가 주소를 바꾼 것이 아닙니다. 로그인 양식이 대소문자를 엄격하게 구분해 텍스트를 비교한 것입니다.

리스트와 CRM에도 같은 종류의 문제가 있습니다. 누군가 Bob@company.com으로 가입한 뒤 bob@company.com으로 가이드를 내려받으면, 많은 플랫폼이 이를 별개의 리드 2건으로 셉니다. 그러면 지표가 부풀려지고, 같은 사람에게 캠페인이 중복으로 발송됩니다. 마케팅 리스트는 대소문자를 무시하고 중복 레코드를 정리한 다음 리스트 검증(영어)이나 발송을 진행하십시오.

그리고 드물지만 대소문자를 엄격하게 구분하는 회사 서버도 있습니다. Microsoft 답변이 언급한 예외입니다. 연락처가 명함에 주소를 M.MacDonald@specialtycorp.com처럼 적었다면, 메일을 보낼 때 그 대소문자를 그대로 쓰십시오. 일반 시스템에는 아무 문제가 없고, 대소문자를 구분하는 시스템에서는 전달 문제를 막을 수 있습니다.

이메일 주소를 저장하는 경우

웹 애플리케이션을 만들거나 연락처 데이터베이스를 관리한다면 대소문자를 보존하는 방식을 쓰십시오. 주소는 사용자가 입력한 그대로 저장하고, 모든 비교, 조회, 중복 확인은 소문자로 하십시오.

원래 입력을 보존하면 프로필과 이메일 헤더에서 사용자가 원하는 표시 방식을 지킬 수 있습니다. 소문자 정규화는 중복 계정을 막습니다. 누군가 IStillUse@AOL.COM으로 가입했다면 표시 이름을 소문자로 바꾸지 마십시오. 대신 iSTilLUSE@aol.com은 같은 주소의 중복으로 처리하십시오.

PostgreSQL에서 중복을 막으려면 일반 고유 제약 조건을 추가하지 말고, 소문자로 바꾼 표현식에 인덱스를 만드십시오.

CREATE UNIQUE INDEX users_email_lower ON users (lower(email));

PostgreSQL은 문자열을 대소문자 구분 없이 비교하는 citext 확장도 제공합니다. MySQL에서는 기본 콜레이션(utf8mb4_0900_ai_ci)이 이미 대소문자를 구분하지 않습니다. 따라서 별도 함수 없이 일반 고유 키로 대소문자만 다른 중복을 막을 수 있습니다.

백엔드 언어, 특히 Java에서는 소문자 변환의 함정에 주의하십시오. Java에서 email.toLowerCase()를 호출하면 서버의 기본 로캘이 사용됩니다. 터키어 로캘에서는 대문자 라틴 문자 I가 i가 아니라 ı(점 없는 소문자 i)로 바뀌어 INFO@example.com 같은 주소가 깨집니다. 이 버그를 막으려면 Locale.ROOT를 전달하십시오.

// Locale.ROOT avoids language-specific letter mapping like Turkish dotless i
String cleanEmail = email.toLowerCase(Locale.ROOT);

JavaScript의 toLowerCase()는 호스트 로캘 설정이 아니라 유니코드 기본 매핑을 사용하므로 이 함정에서 안전합니다. 로캘에 따라 달라지는 것은 toLocaleLowerCase()뿐입니다.

잘못된 형식과 잘못된 입력이 데이터베이스에 들어가기 전에 막으려면, 가입 단계에서 이메일 유효성 검사 API(영어)로 주소를 검사하십시오. 사용자가 아직 페이지에 있는 동안 오타와 없어진 도메인을 찾아냅니다.

자주 묻는 질문

Gmail은 대소문자를 구분합니까? 아니요. Gmail은 계정을 만들 때와 메일을 전달할 때 대소문자를 무시합니다. 주소가 john.doe@gmail.com이라면 JOHN.DOE@gmail.com과 John.Doe@googlemail.com으로 보낸 메일도 받습니다. 기존 사용자와 대소문자만 다른 새 계정은 등록할 수 없습니다.

이메일 주소를 대문자로 입력해도 괜찮습니까? 일반 사용자와 기업의 받은편지함으로 보내는 일반적인 발송에서는 대문자 때문에 메일이 전달되지 않는 일은 없습니다. 수신 메일 서버는 대소문자를 무시하고 메일을 정상적으로 전달합니다. 이메일 주소를 정확한 문자열로 비교하는 로그인 양식에서만 주의하면 됩니다.

이메일 ID는 대소문자를 구분합니까? 실제로는 구분하지 않습니다. 이메일 ID는 이메일 주소의 다른 이름일 뿐이며, Gmail, Outlook 등 대형 제공업체는 ID의 대문자를 무시합니다. 표준상 서버가 @ 앞의 대문자를 다르게 처리할 수는 있지만 드문 경우입니다. 읽기 쉽도록 ID에 대문자를 써도 메일을 받지 못할 가능성은 매우 낮습니다.

이메일 주소는 소문자로 저장해야 합니까? 중복 계정과 로그인 실패를 막으려면 이메일 주소를 소문자로 비교하고 인덱싱해야 합니다. 사용자의 원래 대소문자를 표시용 열에 보관하면 알림을 깔끔하게 표시할 수 있습니다. 열을 하나만 쓸 수 있다면 주소를 입력한 그대로 저장하고 lower()로 비교하십시오. 그러면 원래 값을 잃지 않습니다.

대문자 때문에 이메일이 반송될 수 있습니까? 매우 드뭅니다. Admin@ 주소와 admin@ 주소를 별개의 메일함으로 처리하도록 설정된 특이한 서버에서만 생깁니다. 대문자가 들어간 주소가 반송되면 먼저 오타나 더 이상 없는 메일함 같은 다른 원인을 찾으십시오. 반송 메일의 코드가 어느 쪽인지 알려 줍니다. 자세한 내용은 하드 바운스와 소프트 바운스에서 설명합니다.

대문자 때문에 메일이 도착하지 않는 일은 없지만, 오타가 있으면 도착하지 않습니다. 다음 발송 전에 연락처 리스트를 정리한다면 Giggal.ai(영어)로 먼저 없어진 메일함과 잘못된 도메인을 찾아내십시오.