Как запустить почтовую отправку с нового IP

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

Почему новый IP нельзя прогреть по таймеру

Новый IP означает отсутствие собственной истории отправки, а не автоматический бан. Почтовая система получателя оценивает сообщения и отправителя по совокупности сигналов: корректности DNS и аутентификации, характеру потока, отказам и реакции адресатов. SPF, DKIM и DMARC помогают подтвердить происхождение писем и задать политику домена, но сами по себе не дают пропуск во «Входящие». В работе с корпоративной почтой я сначала проверяю домен, PTR и реальный маршрут письма, а уже потом обсуждаю объём. Если эту проверку нужно провести за вас, мы занимаемся настройкой корпоративной почты.

У Google в рекомендациях нет нормы «50 писем в час первую неделю». Компания советует начинать с небольшого объёма для заинтересованных получателей, отправлять равномерно, постепенно повышать нагрузку и смотреть на ответы SMTP, жалобы и репутацию. Скорость зависит от отправляемого объёма, частоты и обратной связи. Это полезнее любого красивого календаря: IP, который нужен для десятка уведомлений в день, и адрес, с которого планируют массовую рассылку, — разные задачи. Я сверяю рекомендации по конкретным доменам получателей и фиксирую исходный уровень, а не копирую чужую таблицу. Google отдельно считает объём, обратную связь и ограничения на уровне домена и IP; общая квота IP затрагивает отправителей, которые делят этот адрес. Поэтому я записываю не только имя домена в поле From, но и фактический исходящий адрес, маршруты реле и домены, подписывающие письма. Перед стартом отправляю контрольные сообщения на свои адреса у нужных получателей и проверяю заголовки: какой IP реально виден снаружи, прошли ли проверки SPF и DKIM и совпадает ли домен для DMARC. Если тест проходит с одного маршрута, это ещё не подтверждает другой IPv4 или IPv6.

• История отправки у нового IP ещё не сложилась.
• Аутентификация подтверждает домен, но не гарантирует доставку.
• Темп выбирают по ответам систем получателей.

Как разобрать сценарий небольшого офиса

В поле company указан условный пример: студия видеомонтажа «Монтажный стол», 25 рабочих мест. Я рассматриваю его именно как сценарий, а не как подтверждённую историю клиента. Чтобы показать ход мысли, примем ещё одно условие: в первый день с IP уходит около 300 писем. Эти 300 — допущение для разбора, не допустимый порог и не доказательство, что именно такой объём вызывает блокировку. В реальной работе перед планом я выясняю, сколько писем составляют ответы сотрудников, уведомления систем и подписные сообщения, и куда каждую группу отправляют.

Если в таком сценарии часть писем начинает отклоняться, я не объявляю IP «сожжённым» и не выключаю всю почту без разбора. Сначала отделяю срочные пользовательские уведомления от необязательных массовых сообщений, проверяю очередь и сохраняю полный текст отказа. Затем смотрю, повторяется ли проблема у одного получателя или у разных систем, и меняю только соответствующий поток. Успешный результат здесь — не обещание «всё в Inbox через неделю», а понятная причина отказа, чистая очередь и стабильная отправка без всплесков. Если причины пока неясны, скорость не повышаю. Я также сохраняю исходные логи до любых изменений: без отметки времени, адреса получателя и полного ответа легко сравнивать разные ошибки как одну. Для офиса с несколькими системами отправки отдельно выясняю, не используют ли они общий внешний адрес. В этом сценарии полезно сначала измерить обычный поток рабочего дня и его состав, затем провести небольшой контрольный запуск и сравнить ответы для каждого типа писем. Так становится видно, упираемся ли мы в настройки сервера, качество адресов или политику конкретного получателя; число рабочих мест само по себе этого не показывает.

• 25 рабочих мест — условие исходного сценария.
• 300 писем в первый день — модельное допущение.
• Решение принимают по ответам, а не по этим числам.

Что проверить до увеличения отправки

До первого заметного объёма я проверяю, что адрес отправителя действительно принадлежит компании, а доменная аутентификация настроена для каждого используемого источника. Для почтового IP важны согласованные прямое и обратное разрешения DNS: PTR должен вести к имени узла, а A или AAAA этого имени — обратно к отправляющему адресу. Проверяю также, что сервер не отправляет письма через неожиданный IPv6 или сторонний SMTP-релей. В рекомендациях Gmail SPF или DKIM нужны всем отправителям, а для массовой отправки Google требует оба механизма и DMARC; условия зависят от типа и объёма отправки. Записи не заменяют тестовое письмо и чтение заголовков. Отдельный разбор записей есть в материале о проверке SPF, DKIM и DMARC.

Следующий шаг — разделить легитимные сценарии отправки. Транзакционное уведомление отправляется потому, что человек запросил действие; подписная рассылка должна уходить только тем, кто действительно на неё согласился, с понятной отпиской. Сотрудникам не нужно рассылать бессмысленные письма, а затем просить переносить их из спама: это имитация спроса, а не прогрев. Google отдельно предупреждает, что внутренние сообщения не следует отмечать как спам. Если типов трафика несколько и объём уже оправдывает раздельные адреса, их можно разделить; смешивать рекламу с квитанцией или уведомлением о пароле не надо. SPF перечисляет разрешённые источники для домена отправителя; DKIM добавляет криптографическую подпись, которую получатель может проверить; DMARC связывает результат SPF или DKIM с доменом в From и сообщает получателю, как поступить при провале проверки. Я проверяю не только наличие TXT-записей, но и фактический результат на тестовом сообщении: длинная или ошибочная SPF-запись, неверный selector DKIM либо несогласованный домен не исправятся от самого факта публикации DMARC. Отчёты DMARC помогают обнаружить неожиданные источники, но тоже не измеряют репутацию IP. Эти проверки отвечают на разные вопросы — кто отправил письмо и как его обработать, — поэтому я не смешиваю их с постепенным наращиванием объёма.

• Проверьте SPF, DKIM и DMARC для своего потока.
• Сверьте PTR, A/AAAA и фактический IP отправки.
• Отправляйте только ожидаемые адресатами сообщения.

Как читать отказы и проверять репутацию

В журнале меня интересуют не только числа 550 или 554. Сохраняю полный SMTP-ответ, расширенный код состояния, домен получателя, время и идентификатор сообщения. Код 550 может означать, например, недоступный адрес, а 554 — общий отказ транзакции; по одним трём цифрам нельзя заключить, что IP попал в блоклист. Решение зависит от полного ответа конкретного сервера и этапа SMTP. По стандарту временные ответы 4xx требуют повторной попытки со стороны отправляющей системы, а окончательные 5xx — разбора причины до новой попытки. Это обычная диагностика, не повод бездумно повторять рассылку. Подробный разбор репутации адреса есть в статье о проверке почтового IP.

Для получателей Gmail Google Postmaster Tools показывает, в частности, сведения о спам-отметках, доставке, аутентификации и репутации домена или IP. Это данные именно о почте, отправленной пользователям Gmail; панель не заменяет логи остальных получателей. Для Outlook.com Microsoft SNDS выдаёт данные по отдельным IP и отчёты пользовательских жалоб, но доступ запрашивает владелец или ответственный за соответствующий IP. Из базы знаний добавляю практический ориентир: SNDS нужен для наблюдения за репутацией IP у Microsoft, а не для универсального прогноза доставки на все домены. Если данные по конкретному получателю доступны, сопоставляю их со временем отправки и ответом SMTP. В SNDS сначала нужно войти и запросить доступ к IP, за который вы отвечаете; это не общедоступный рейтинг любого адреса. Панель показывает сведения о доставке к Outlook.com, поэтому отсутствие там записи не доказывает ни хорошую, ни плохую доставку к другим доменам. Postmaster Tools тоже имеет свой охват — сообщения Gmail, — и данные в нём нельзя подменять общим процентом «доставлено» из почтового сервера. Я сопоставляю панели с очередью и конкретными SMTP-ответами, а если жалобы или отсрочки выросли только у одного получателя, сначала выясняю его отдельное правило. Внешний агрегатор блоклистов может подсказать, где проверить адрес, но решение принимает принимающий сервер, и не всякий список он использует.

Проверка блоклистов тоже требует точности. Spamhaus PBL — Policy Blocklist: присутствие IP в PBL может означать, что диапазон по политике не предназначен для прямой отправки почты; это не равнозначно доказанной рассылке спама. Для отдельного статического IP, который действительно обслуживает исходящую почту, Spamhaus указывает условия снятия: корректные A и rDNS, сам IP назначен запрашивающей стороне, а исходящий порт 25 не открыт для других устройств. Сначала определите список и его причину, затем устраняйте причину и следуйте процедуре именно этого списка. Проверка доставки после переезда почты описана в отдельном плане контрольных проверок.

• Сохраните полный текст SMTP-ответа.
• Сверьте очередь с данными Postmaster Tools или SNDS.
• Уточните, какой именно список отметил адрес.

Как наращивать объём и когда остановиться

Я начинаю с небольшого постоянного потока реальных сообщений адресатам, которые их ждут. Не делаю резкий запуск «всего накопленного», не меняю одновременно IP, шаблон письма и список получателей. Google советует наращивать объём постепенно, причём более крупный поток увеличивать осторожнее; частота отправки и обратная связь тоже влияют на темп. Поэтому у статьи нет таблицы с процентами на каждый день: без истории адреса получателя и исходного объёма это была бы псевдоточность. Записываю отправленный объём, долю принятых писем, отказы и отсрочки по каждому крупному домену. Следующую ступень выбираю после того, как предыдущая проходит без новых проблем.

Если растут отказы или отсрочки, объём уменьшаю до снижения ошибок, а не пытаюсь «продавить» сервер получателя. Если проблема остаётся на малой отправке, проверяю конкретное сообщение, адрес, DNS, авторизацию и возможный компрометированный ящик. Восстановление репутации не имеет гарантированного срока: на него влияют причины отказов, провайдер, список и качество адресатов. При изменении инфраструктуры или заголовков я отдельно наблюдаю за изменённым потоком — так легче понять, что повлияло на результат. А когда появятся новые успешные наблюдения, прибавляю объём осторожно. Календарь может подождать; очередь и ответы сервера — нет. Для каждого шага веду короткую таблицу: дата и время, объём по типу письма, доля принятых сообщений, временные отсрочки, окончательные отказы и заметки по панели провайдера. Если я изменил DNS, маршрут или шаблон, отмечаю это отдельно и не делаю в тот же момент следующую прибавку. При проблеме прекращаю именно спорный поток, оставляя рабочие уведомления только если они продолжают проходить и это безопасно для адресатов; затем проверяю источник и повторяю контрольный тест. Такой журнал позволяет отличить разовый отказ от устойчивого ухудшения и объяснить заказчику, почему темп пришлось замедлить. Это и есть управляемый запуск — не обещание, что любой адрес станет доверенным к заданной дате.

• Держите отправку равномерной.
• При росте отказов вернитесь к меньшему объёму.
• Меняйте один фактор и проверяйте результат.

Частые вопросы