Как обрабатывать email адреса с цифрами

Что проверяют

Понимаете ли вы, что цифры в email совершенно законны, и не решаете ли валидацию самодельной регуляркой. Следом обычно спрашивают, как проверить, что адрес существует, и что делать с регистром и символом +.

Как отвечать

Начните с правил. Цифры разрешены и в локальной части (user2024@, 123456@), и в доменах (mail.123.ru). Поэтому «адрес с цифрами» почти всегда всплывает как баг: чья-то регулярка режет нормальных пользователей или тестовые данные таких адресов не содержат.

Каркас обработки:

• очистка: strip() и домен в нижний регистр. Локальная часть формально чувствительна к регистру, поэтому хранят исходный вид, а для поиска дублей держат отдельное нормализованное поле;
• синтаксис: библиотека email-validator, вызов validate_email(addr, check_deliverability=False) возвращает объект с полем normalized и понимает IDN вроде почта@пример.рф. В Pydantic то же даёт тип EmailStr (пакет pydantic[email]);
• существование: надёжна только ссылка подтверждения в письме. Проверка MX-записи отсекает опечатки в домене, но не гарантирует, что ящик есть;
• тесты: pytest.mark.parametrize на наборе user123@example.com, 1@example.com, a+2024@example.com, user@sub.123.example.com и заведомо плохих user@domain, user@@example.com.

Если регулярка всё же нужна, например для поиска адресов в тексте, берите re.fullmatch или якорь \Z и держите шаблон простым, не пытаясь описать весь RFC 5322. А email.utils.parseaddr разбирает строку вида Имя <addr> и ничего не валидирует.

Где спотыкаются

Пишут re.match с $ в конце шаблона. $ совпадает и перед завершающим переводом строки, поэтому "a@b.com\n" проходит проверку, и в базу уезжает адрес с \n.

Ограничивают домен классом [a-zA-Z]. Кириллические и другие IDN-домены такая проверка отвергает, хотя они рабочие.

Отрезают всё после + и выкидывают точки в локальной части у всех адресов подряд. Это правило отдельных почтовых сервисов, у остальных такие адреса ведут в разные ящики.