Главный совет из этой статьи: не пытайся умничать с валидацией email. Просто отправь письмо с подтверждением. Автор разбирает популярные заблуждения об email-адресах, которые до сих пор ломают жизнь пользователям и разработчикам.
Первое и самое живучее — попытка проверить адрес регулярным выражением. Это дорого, сложно и бесполезно. Любой хороший regex, скопированный 20 лет назад, сегодня уже неактуален. В 2026 году пользователи умеют вводить свою почту, а автозаполнение есть в каждом браузере. Единственная разумная проверка на клиенте — убедиться, что в строке есть @. И не надо проверять MX-запись домена: ваш почтовый сервис сам это делает при отправке.
Второе заблуждение — что почтовые провайдеры поддерживают все валидные адреса. Это не так. Например, поддержка UTF-8 в локальной части (SMTPUTF8, RFC 6531) появилась в Postfix только около 2015 года, а Dovecot не поддерживает её до сих пор. Gmail ограничивает символы при создании ящика. Даже жёсткие ограничения RFC нарушаются: локальная часть длиной 80 байт формально невалидна, но письмо на такой адрес спокойно уходит и доставляется.
Третье — про доменную часть. Многие думают, что домен всегда выглядит как something.something. На деле есть адреса с поддоменами (много точек), без точек вообще (внутренние сети) и с IP-адресом в квадратных скобках вместо домена, как ben@[50.169.39.178]. Gmail не умеет отправлять на такие адреса, а Thunderbird — может. Ещё одна проблема — TLD: почту на домене .email многие компании просто отсекают своей валидацией, потому что ждут только .com, .net и .org.
Четвёртое — про регистр. RFC разрешает делать локальную часть чувствительной к регистру. Но в реальности все крупные провайдеры (Gmail, Outlook) считают ben и BEN одним и тем же ящиком. Проблема в другом: если вы строите уникальный индекс по email, приведение к верхнему или нижнему регистру ломается на юникоде. Немецкое ß в верхнем регистре превращается в SS, а турецкое İ — в обычное i. В итоге два разных пользователя могут случайно схлопнуться. Решение — использовать citext в Postgres или COLLATE utf8mb4_general_ci в MySQL.
Пятое — плюс-теги (ben+company@domain). Это абсолютно валидный приём из RFC, но его до сих пор блокируют. Например, United Airlines и Motorola не пропускают такой адрес через свою форму, хотя письмо на него успешно приходит. Автор напоминает: плюс разрешён в atext по RFC 5322. Не надо его вырезать или считать, что такая адресация работает везде как в Gmail — это особенность конкретного провайдера.
Итог: не нужно запоминать все эти тонкости. Для уникальности — citext или utf8mb4_general_ci. Для проверки — отправка письма. Всё.