Message-ID: зачем каждому письму нужен уникальный идентификатор
Message-ID is a header field that contains a globally unique identifier for an email message. It is generated by the originating MTA (or MUA) at the time the message is created, and it stays with the message throughout its entire lifecycle - delivery, storage, forwarding, replies. No two messages should ever share the same Message-ID.
Format
RFC 5322 defines Message-ID as a string enclosed in angle brackets, structured as a local part, an "@" sign, and a domain:
Message-ID: <20260115102345.A1B2C3@mail.example.com>
The local part is typically a combination of timestamp, process ID, random string, or internal counter. The domain part is usually the hostname of the server that generated the message. Together, they guarantee uniqueness: the timestamp and random component prevent collisions on the same server, and the domain prevents collisions across servers.
Some systems produce Message-IDs that look different:
Message-ID: <CABx+XJ3vE2=nQ@mail.gmail.com>
Message-ID: <5f2a1b3c-8d4e-4f6a-9b0c-1d2e3f4a5b6c@smtp.sendgrid.net>
Gmail uses a Base64-encoded string. SendGrid uses a UUID. The format of the local part is not standardized beyond being unique - each implementation chooses its own scheme.
Дедупликация сообщений
Основная функция Message-ID на стороне получателя - дедупликация. Если одно и то же письмо доставлено дважды (из-за сетевого сбоя, retry после таймаута, или пересылки через несколько путей), почтовый клиент или сервер сравнивает Message-ID с уже имеющимися. Совпадение означает дубликат, который можно отбросить.
Gmail активно использует дедупликацию по Message-ID. Если вы отправите одно и то же письмо (с тем же Message-ID) на один адрес Gmail дважды, второе не появится в ящике. Это защищает пользователей, но может сбить с толку отправителя при тестировании: письмо "не дошло", хотя оно просто было отфильтровано как дубликат.
Threading: In-Reply-To и References
Когда вы отвечаете на письмо, почтовый клиент берёт Message-ID исходного сообщения и помещает его в заголовок In-Reply-To нового сообщения. Заголовок References содержит цепочку всех Message-ID в треде:
Message-ID: <reply-002@mail.example.com>
In-Reply-To: <original-001@mail.example.com>
References: <original-001@mail.example.com>
Почтовые клиенты используют References для группировки писем в беседы (threads). Без корректных Message-ID эта система ломается: ответы отображаются как отдельные письма, а не как часть переписки.
Message-ID в массовых рассылках
Для ESP Message-ID выполняет ещё одну задачу: идентификация конкретного письма в логах. Когда получатель жалуется на спам или bounce возвращается с ошибкой, Message-ID позволяет найти именно это сообщение в системе отправки и понять, что пошло не так.
Хороший ESP генерирует уникальный Message-ID для каждого отдельного получателя в рассылке. Если одна кампания отправляется 50 000 адресатам, создаётся 50 000 разных Message-ID. Это правильное поведение. Если ESP использует один Message-ID для всех копий, дедупликация на стороне получателей может отбросить легитимные письма.
Отсутствие или подделка Message-ID
Письмо без Message-ID - аномалия. RFC 5322 обязывает его наличие. Если отправляющий MTA не сгенерировал Message-ID, принимающий сервер обычно создаёт его сам и добавляет в заголовки. Но само отсутствие заголовка от отправителя расценивается спам-фильтрами как признак плохо настроенного или подозрительного источника.
Подделка Message-ID (повторное использование чужого идентификатора) может привести к тому, что письмо будет отброшено дедупликацией. Некоторые спамеры копируют Message-ID легитимных писем, рассчитывая обойти фильтры, но результат обычно обратный: письмо не доставляется, потому что получатель уже видел этот ID.
Домен в Message-ID
Часть после @ в Message-ID обычно совпадает с доменом отправляющего сервера. Некоторые спам-фильтры проверяют это соответствие. Если письмо утверждает, что отправлено от company.com, а Message-ID содержит @random-vps.net, это расхождение может повысить спам-скор.
На практике строгая проверка домена в Message-ID не является стандартом. Но рекомендация проста: используйте домен своего почтового сервера в Message-ID. ESP делают это автоматически (Message-ID содержит домен ESP или кастомный домен клиента).
Message-ID и Feedback Loop
Когда получатель нажимает "Спам" в Gmail или Yahoo, почтовый провайдер отправляет Abuse Report (ARF) на адрес, зарегистрированный в Feedback Loop. Этот отчёт содержит Message-ID исходного письма. ESP использует его для идентификации: какое именно письмо вызвало жалобу, из какой кампании, для какого клиента.
Без уникального Message-ID привязать жалобу к конкретному сообщению невозможно. Это делает анализ complaint rate неточным и затрудняет работу над улучшением рассылок.
Message-ID в диагностике
При разборе проблем с доставкой Message-ID - главный ключ для поиска в логах. Администратор сервера получателя может найти запись о сообщении по его ID и увидеть: принято, отклонено, помещено в карантин, или доставлено в ящик. Без Message-ID поиск превращается в перебор по временным меткам и IP-адресам, что на загруженных серверах крайне неэффективно.
Лог Postfix, например, записывает Message-ID для каждого обработанного сообщения. Одна команда grep по ID покажет весь путь письма через систему: приём, обработка, передача на следующий hop, финальный статус.
uChecker проверяет адреса до отправки рассылки, чтобы каждый сгенерированный Message-ID соответствовал реальному доставленному письму, а не bounce-уведомлению в логах вашего ESP.
