Синтаксическая валидация email

Синтаксическая валидация email - проверка того, что email-адрес соответствует формату, описанному в стандартах RFC 5321 и RFC 5322. Прежде чем обращаться к DNS или SMTP-серверу, система убеждается: строка вообще может быть email-адресом.

Из чего состоит email-адрес

Формат прост на первый взгляд: local-part@domain. Слева от символа @ находится локальная часть (имя ящика), справа - домен. Но правила для каждой части отличаются.

Локальная часть может содержать латинские буквы, цифры, точки, дефисы, знаки подчёркивания и ряд специальных символов. Точка не может быть первым или последним символом. Две точки подряд запрещены. Максимальная длина локальной части - 64 символа.

Домен подчиняется правилам DNS: допустимы буквы, цифры и дефис. Каждая метка (часть между точками) не длиннее 63 символов. Общая длина адреса - не более 254 символов.

Как работает проверка

Самый распространённый инструмент для синтаксической валидации - регулярное выражение (regex). Простейшие regex проверяют наличие символа @ и точки в домене. Продвинутые варианты учитывают допустимые символы, длину частей и структуру домена.

Полностью воспроизвести RFC 5322 одним regex почти невозможно. Стандарт допускает экзотические конструкции: кавычки в локальной части, комментарии в скобках, IP-адреса вместо домена. На практике 99,9% реальных адресов не используют эти крайние случаи, поэтому валидаторы работают с разумным подмножеством правил.

Некоторые системы заменяют regex парсером - последовательным разбором строки по правилам грамматики. Парсер надёжнее: его проще тестировать и отлаживать. Но для быстрой проверки на фронтенде regex остаётся стандартным выбором.

Частые ошибки формата

• Пробелы внутри адреса: user @mail.com
• Две точки подряд: user..name@mail.com
• Пропущенный домен: user@
• Кириллица в домене без Punycode: user@почта.рф
• Запрещённые символы: user<name>@mail.com
• Адрес длиннее 254 символов

Зачем нужна синтаксическая проверка

Это первый и самый дешёвый фильтр. Он отсекает явный мусор до того, как система потратит ресурсы на DNS-запросы и SMTP-подключения. Без синтаксической проверки валидатор будет пытаться резолвить домен из строки «привет», а это бессмысленная нагрузка.

Синтаксическая валидация ловит опечатки на уровне структуры: пропущенный @, двойные точки, случайный пробел. Она не гарантирует, что адрес существует, но гарантирует, что формат корректен.

В формах подписки синтаксическая проверка на стороне клиента (JavaScript) даёт моментальную обратную связь. Пользователь видит ошибку сразу, не дожидаясь ответа сервера. Это снижает процент невалидных адресов ещё до их попадания в базу.

Ограничения

Синтаксически корректный адрес может быть полностью бесполезным. Строка zzzzz@zzzzz.zzz пройдёт проверку формата, хотя такого домена не существует. Поэтому синтаксическая валидация - только первый шаг. За ней следуют проверка DNS, MX-записей, SMTP-подключение и другие этапы.

Ещё одна ловушка - слишком строгие правила. Адрес с символом+ (например, user+tag@gmail.com) валиден по RFC, но некоторые самописные regex его отклоняют. Аналогично с IDN-доменами: они корректны, но требуют конвертации через Punycode.

Практические примеры

HTML5-атрибут type="email" в форме включает встроенную браузерную валидацию. Она проверяет базовый формат, но пропускает адреса вроде a@b - технически валидные, но бесполезные.

Серверные библиотеки (email-validator в Python, validator.js в Node) предлагают более строгую проверку. Они разделяют адрес на части, проверяют длину, кодировку, допустимые символы. Некоторые из них умеют нормализовать адрес: привести к нижнему регистру, убрать лишние пробелы по краям.