Да. Email-адрес со знаком «+» в локальной части может быть корректным. Не отклоняйте его и не удаляйте метку только из-за символа +. Проверяйте адрес целиком: правильный синтаксис ещё не доказывает, что сервер принимает почту для этого получателя.
В форме или интеграции через API сохраняйте адрес, который указал человек. Если заменить Alex+orders@example.com на Alex@example.com, вы проверите другого получателя и запишете в базу другой контактный адрес.
Что означает знак «+»
При плюс-адресации перед @ добавляют метку. В адресе Alex+orders@example.com локальную часть записывают как Alex+orders, а домен как example.com. Почтовая система с поддержкой этой функции может направить письма в тот же ящик, что и для Alex@example.com.
Это зависит от принимающей системы. RFC 5233 описывает кодирование таких дополнительных адресов как особенность конкретной системы или реализации. По одному символу + приложение не может определить, как произвольный домен трактует адрес.
В Exchange Online плюс-адресация включена по умолчанию, но организация может её отключить. Если поддержка функции важна для вашего сценария, проверьте настройки принимающего провайдера. Подробнее в документации Microsoft о плюс-адресации.
Все адреса в примерах синтетические и используют зарезервированные домены для примеров. Они показывают обработку данных, а не работающие почтовые ящики.
Разрешите символ и проверьте весь адрес
Грамматика локальной части без кавычек допускает +. Остальные ограничения сохраняются: разрешённый символ не делает любую строку корректной. RFC 5322, раздел 3.2.3.
Например, текущий парсер Emvero принимает структуру Alex+orders@example.com, но отклоняет Alex..orders@example.com. Во втором адресе ошибка связана с двумя точками подряд. Другие ограничения описаны в правилах синтаксиса email-адреса.
Если форма отклоняет первый адрес, проверьте валидатор на фронтенде и парсер на бэкенде. Список, который разрешает в локальной части только буквы, цифры, точки, подчёркивания и дефисы, исключает + ещё до обращения к сервису проверки.
Отделяйте проверку формата от свидетельств, которые появляются на следующих этапах. В сравнении проверки синтаксиса и SMTP-проверки разобрано, что устанавливает каждый метод.
Нормализуйте домен, сохраняя локальную часть
Значение локальной части определяет принимающая система. SMTP-клиенты обязаны сохранять её регистр, а для доменных имён регистр не имеет значения. RFC 5321, разделы 2.3.11 и 2.4.
Для интеграции с разными провайдерами сохраняйте регистр, точки и метку после плюса в локальной части. Не применяйте правила псевдонимов одного провайдера ко всем адресам.
Текущий парсер Emvero допускает обычный синтаксис с меткой после плюса, сохраняет локальную часть и нормализует домен. Для этого синтетического примера ожидаемая обработка выглядит так:
| Входные данные или часть адреса | Значение |
|---|---|
| Введённый адрес | Alex+orders@EXAMPLE.COM |
| Сохранённая локальная часть | Alex+orders |
| Нормализованный домен | example.com |
| Адрес для проверки | Alex+orders@example.com |
Проверка адреса без метки ответит на другой вопрос. Даже если оба адреса ведут в один ящик, приложение потеряет контактный адрес и метку, которые выбрал человек.
Проверьте, не превратился ли + в пробел
При разборе данных application/x-www-form-urlencoded символ + превращается в пробел. Правильная сериализация кодирует плюс как %2B. Стандарт URL от WHATWG.
Используйте сериализатор, а не собирайте строку параметров вручную:
const email = "Alex+orders@example.com";
const body = new URLSearchParams({ email });
console.log(body.toString());
console.log(new URLSearchParams(body.toString()).get("email"));
Результат:
email=Alex%2Borders%40example.com
Alex+orders@example.com
Сравните значение поля со значением, которое получает бэкенд. Если на сервер приходит Alex orders@example.com, сначала проверьте кодирование данных. Исправьте сериализатор: замена всех пробелов на + после декодирования скроет некорректный ввод.
Для запроса в Emvero отправляйте JSON из бэкенда на POST /v1/verifications. Сохраняйте полный адрес в теле запроса:
{
"email": "Alex+orders@EXAMPLE.COM"
}
Храните учётные данные API на сервере.
Проверьте адрес с меткой и подтвердите доступ к ящику
Сам по себе плюс не доказывает существование ящика, принадлежность провайдеру временной почты или наличие дубликата аккаунта. Проверяйте весь введённый адрес и читайте поля action и reason_codes в ответе. В зависимости от свидетельств рекомендация может иметь значение allow, allow_with_email_confirmation или reject.
При unknown имеющихся свидетельств недостаточно для вывода об адресе. При pending проверка ещё не завершена. Ни одно из этих состояний не даёт оснований для постоянного отказа только из-за плюса в адресе.
Если доступ к аккаунту зависит от контроля над ящиком, отправьте собственное письмо подтверждения на полный адрес. Проверка Emvero не отправляет это письмо и не устанавливает, кто контролирует ящик. Руководство по проверке адресов в форме регистрации показывает, как включить проверку и подтверждение в общий сценарий.
В сравнении проверки адреса и подтверждения доступа к ящику показано, почему эти результаты нужно хранить отдельно.
Отделяйте правила для дубликатов от контактных данных
Удаление метки не подходит как универсальное правило идентификации. Так можно объединить адреса, которые принимающая система считает разными. Одни лишь псевдонимы не доказывают, что две регистрации принадлежат одному человеку.
Если продукту нужно группировать подтверждённые адреса по правилу для известного провайдера, храните эту группировку отдельно от адреса для связи, подтверждения и восстановления доступа. Не перезаписывайте контактный адрес и не объединяйте аккаунты автоматически. Руководство по защите пробных периодов от злоупотреблений объясняет, какую роль могут играть свидетельства об адресе.
Перед изменением валидатора добавьте регрессионные проверки всего пути через приложение:
Alex+orders@example.comпроходит проверку, передачу и запись в базу с неизменной локальной частью.- В
Alex+orders@EXAMPLE.COMможно нормализовать домен, сохранивAlex+orders. Alex..orders@example.comпо-прежнему отклоняется из-за некорректного синтаксиса.- Кодирование и декодирование данных формы сохраняет
+. Удаление метки из значения для сравнения само по себе не приводит к объединению аккаунтов.
Подключите API проверки email-адресов, чтобы проверять адрес после того, как бэкенд получил его без изменений.