Общий прокси или выделенный IP для рассылки писем

Как выбрать между общим прокси и выделенным IP-адресом для рассылки писем

Общий прокси и выделенный IP-адрес могут влиять на разные компоненты системы рассылки. Прокси может маршрутизировать подключение пользователя к почтовому ящику или платформе для рассылок, а выделенный IP-адрес может использоваться почтовым сервисом для отправки писем. По одним только названиям нельзя понять, какое именно подключение изменится.

Начните с того, что проследите путь одного реального письма — от человека, который его составляет, до входящих получателя. Если вы выбираете между общим прокси и выделенным IP-адресом для рассылки писем, сначала определите, на какой компонент вашей системы будет влиять каждый из вариантов.

1. Проследите путь каждого письма

Составьте схему для одной учётной записи и одного инструмента. Например, сотрудник может войти в веб-платформу для рассылок через браузер, составить там письмо, а затем отправить его через собственную почтовую инфраструктуру платформы. В таком случае подключение браузера и маршрут исходящей почты — разные части процесса.

В других системах используется почтовый клиент, подключённый к SMTP-серверу, API, связанный с сервисом отправки, или программа, которая объединяет доступ к почтовому ящику с отправкой писем. Запишите, какой компонент отправляет письмо и к какому компоненту подключается пользователь. Прокси, настроенный в браузере, обычно влияет на подключение этого браузера, но не перенаправляет автоматически отдельное SMTP-подключение или серверы платформы.

В этом помогут заголовки письма. Составьте простую схему маршрута с указанием каждого инструмента и подключения, например: пользователь → браузер → платформа для рассылок → сервис отправки → получатель. Если команда отправляет письма через API, укажите приложение и конечную точку API, а не предполагайте, что доставку обеспечивает браузер.

Такая схема поможет обнаружить несоответствие до покупки или настройки чего-либо. Если команда хочет, чтобы вход в почтовые ящики всегда проходил по одному маршруту, ей стоит оценить использование прокси. Если же команда хочет контролировать IP-адрес, который использует сервис отправки, нужно уточнить у этого сервиса, как настроена исходящая доставка. Не следует считать, что одно изменение решит обе задачи.

2. Уточните, какой IP-адрес видят получатели

Чтобы понять, как узнать IP отправки электронного письма, проверьте заголовки тестового письма, полученного на подконтрольный команде аккаунт. Обратите внимание на поля Received, Authentication-Results и Return-Path, а затем сравните их с документацией сервиса отправки. Данные заголовков помогают определить маршрут доставки, но одного поля может быть недостаточно, чтобы понять, как именно провайдер маршрутизирует почту.

Напрямую спросите у платформы для рассылок или почтового провайдера, какой IP-адрес используется для исходящей доставки, является ли он общим или выделенным и может ли он меняться для вашей учётной записи. Эти сведения зависят от конкретного провайдера, поэтому проверьте актуальную документацию или обратитесь в службу поддержки. Не делайте вывод, что получатели видят IP-адрес прокси, только потому, что пользователь вошёл в систему через этот прокси.

Важны и результаты проверки аутентификации. Убедитесь, что SPF, DKIM и DMARC прошли проверку для тестового письма, а видимый домен отправителя совпадает с тем, который команда собиралась использовать. Чтобы понять, как проверить заголовки письма и SPF DKIM DMARC, изучите результаты в заголовках тестового письма и сопоставьте их с настройками домена и требованиями сервиса отправки. Прокси не заменяет эти настройки на уровне домена, и изменение сетевого маршрута не следует считать способом исправить ошибку аутентификации.

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

3. Сопоставьте почтовые ящики, инструменты и сетевые маршруты

Перечислите каждый почтовый ящик, сотрудника или команду, которые им пользуются, подключённый инструмент отправки и маршрут подключения к нему. Для начала достаточно небольшой таблицы. Если пользователь входит в аккаунт через браузер, а отправку писем выполняет платформа или API, укажите эти компоненты отдельно.

Прежде чем что-либо менять, проверьте, нет ли конфликтов маршрутов. Например, два сотрудника могут пользоваться одним аккаунтом, но подключаться к нему разными способами. Или браузер может использовать прокси, а отдельно настроенный почтовый клиент — подключаться напрямую. Это может неожиданно повлиять на доступ к аккаунту или затруднить интерпретацию результатов теста.

Зафиксируйте предполагаемый маршрут рядом с фактической конфигурацией. Если для работы прокси нужны имя пользователя и пароль, храните эти данные согласно утверждённой в вашей организации процедуре работы с паролями, а не в общей заметке. Руководство по безопасной аутентификации на прокси поможет задокументировать, как команда подключается к прокси.

Ведите журнал изменений. Кратко указывайте аккаунт, инструмент, маршрут, имя сотрудника, внёсшего изменение, и полученный результат. Это даст службе поддержки чёткую последовательность действий, если после изменения настроек прокси почтовый ящик перестанет подключаться.

4. Прежде чем менять подключения, проверьте правила платформы

Ознакомьтесь с актуальными правилами почтового провайдера и платформы для рассылок, которые касаются использования прокси, смены IP-адреса, доступа к аккаунту и автоматизированной активности. Проверяйте условия, действующие именно для нужного почтового ящика и тарифного плана. Не предполагайте, что настройка, разрешённая одним сервисом, будет допустима у другого.

Прежде чем менять маршрут, проверьте требования к входу в аккаунт и права администратора. Если в документации что-то неясно, уточните это у владельца аккаунта или в службе поддержки провайдера.

Не используйте прокси, чтобы скрыть действия, запрещённые провайдером, или обойти ограничения аккаунта. Если платформа пометила вход как подозрительный или заблокировала доступ, приостановите проверку и обратитесь в её службу поддержки. Подключение ещё одного IP-адреса без понимания причины может затруднить объяснение ситуации.

Также уточните, какие типы подключений поддерживает инструмент. Протокол прокси, способ аутентификации или порт, работающие в одном приложении, могут не поддерживаться другим. Если вы рассматриваете аутентифицированное подключение SOCKS5, изучите инструкции по настройке самого приложения и до перенаправления доступа к почтовому ящику подтвердите конфигурацию у провайдера.

5. Проведите небольшой контролируемый тест

Для начала протестируйте один почтовый ящик и один маршрут. При сравнении текущей и предполагаемой конфигурации не меняйте инструмент отправки, настройки аккаунта и содержимое письма. Если изменить сразу несколько параметров, будет трудно понять, что вызвало сбой входа или изменило результат доставки: прокси, платформа или другая настройка.

Во время тестирования проверьте четыре момента: может ли пользователь войти в аккаунт, сохраняет ли инструмент подключение, отправляется ли письмо и соответствуют ли заголовки полученного письма ожидаемому маршруту доставки. Также запишите результаты проверки аутентификации. Если цель — лишь изменить способ доступа к почтовому ящику, успешный вход не доказывает, что получатель видит другой IP-адрес отправки.

Отправьте письмо на тестовый почтовый ящик, подконтрольный команде, а не запускайте рассылку по большой базе. Если подключение прервётся, зафиксируйте время, сообщение об ошибке в инструменте и использовавшийся маршрут. Эти сведения помогут отличить проблему с аутентификацией прокси от ограничений на вход со стороны провайдера или сбоя сервиса отправки.

Проводите тест в рамках правил провайдера и обычных прав доступа к аккаунту. Не увеличивайте объём отправки только ради проверки смены IP-адреса: важно выяснить, работает ли нужный маршрут и соответствуют ли фактические заголовки настройкам. Если платформа не даёт достаточно информации для проверки маршрута, прежде чем переносить настройки в рабочую среду, обратитесь в её службу поддержки.

6. Выбирайте решение исходя из задачи

Чтобы разобраться, чем отличается прокси от выделенного IP для рассылки, точно сформулируйте проблему по результатам теста. Если она связана с тем, как пользователь или приложение подключается к почтовому ящику или платформе, оцените возможность использовать общий прокси для этого маршрута доступа — при условии, что соответствующие сервисы это разрешают. Если проблема касается адреса, который сервис отправки использует для доставки писем, спросите у провайдера, доступен ли выделенный IP-адрес и какие настройки аккаунта им управляют.

Общий прокси и выделенный IP-адрес не взаимозаменяемы. Прокси может маршрутизировать конкретное подключение, но не обязательно определяет IP-адрес исходящей почты. Выделенный IP-адрес может использоваться для доставки через сервис отправки, но он автоматически не меняет маршрут, по которому пользователь входит в почтовый ящик через браузер.

Вносите изменения, только если ответ провайдера, схема маршрута и результаты тестирования указывают на один и тот же компонент системы. Если это не так, сохраните текущую конфигурацию и сначала устраните неопределённость: смена прокси для доступа не изменит маршрут доставки, если проблема связана с сервисом отправки.