Выделенный IP или общий: как объём и регулярность отправки решают за вас
Хостинг продаёт выделенный IP «для лучшей доставляемости» всем подряд — и ниже порога объёма это прямой путь в спам. Разбираем на числах, при каком суточном потоке и какой регулярности dedicated окупается, даём формулу прогрева, график на 6 недель и матрицу решения. Плюс отдельный разворот для temp-mail и inbound, где логика IP-репутации переворачивается.
EvilMail Team15 июля 2026 г.12 мин чтения
Хостинг предлагает выделенный IP за +5 $ в месяц и обещает «лучшую доставляемость». В половине случаев это билет в один конец — в папку «Спам». Причина проста и контринтуитивна: репутация в почте привязана к IP-адресу, а у нового выделенного IP репутации нет вообще. Ноль. Для фильтров Gmail и Outlook «нет истории» читается как «неизвестный отправитель», а неизвестный отправитель с ненулевым объёмом — это подозрительный отправитель.
Выбор «выделенный или общий» — не вопрос престижа и не вопрос «крупный ты или мелкий». Это арифметика прогрева, и она сводится ровно к двум числам: сколько писем в сутки уходит с одного IP и насколько регулярно это происходит. Всё остальное — производные. Ниже — конкретные пороги, формула, график и матрица вместо «зависит от ситуации».
Что на самом деле «репутирует»: IP, домен и их связка
В почте есть два независимых счётчика доверия, и их постоянно путают.
IP-репутация — это репутация конкретного адреса, с которого ваш MTA открывает соединение на 25-й порт принимающего сервера. Она работает на самом раннем этапе, на уровне TCP: rDNS/PTR, проверка по RBL (Spamhaus ZEN/SBL/CSS/PBL), throttling соединений. Приёмник ещё не видел ни заголовков, ни тела письма — он уже решает по одному IP, притормозить вас или нет.
Domain-репутация — это репутация домена из подписи DKIM (
Выделенный IP или общий: выбор по объёму и регулярности отправки — EvilMail Blog
d=
) и из
From:
. С 2016 года, и особенно после ужесточения требований Gmail и Yahoo в феврале 2024-го, крупные провайдеры смещают вес в сторону домена: он переносим между IP, его сложнее «отмыть» сменой адреса. Но домен оценивается позже — уже после того, как соединение принято. IP остаётся первым фильтром.
Отсюда ключевая разница между вариантами:
Общий IP — это чужая история. Вы делите адрес с десятками отправителей из managed-пула ESP. Один спамящий сосед может уронить весь пул в CSS-листинг Spamhaus, и ваши письма поедут в спам не по вашей вине. Обратная сторона: у пула уже накоплен положительный трафик, и один ваш «тихий» день на нём незаметен.
Выделенный IP — чистый лист. Никаких соседей, полный контроль над PTR и трафиком. Но «чистый» для фильтра означает «неизвестный», а неизвестный с трафиком — подозрительный. Репутацию с нуля вы строите сами, руками, неделями.
Важный технический факт: у IP есть «память». У большинства крупных приёмников это скользящее окно порядка 30 дней. Провайдер смотрит не на «сколько вы отправили всего», а на «как вы вели себя последние ~30 дней». Из этого напрямую вытекает всё, что дальше.
Порог окупаемости: считаем, а не гадаем
Главное число, которое хостинги вам не назовут: чтобы выделенный IP имел смысл, нужен устойчивый поток порядка 5 000–10 000 писем в сутки на один IP. Это индустриальный ориентир — исторически SendGrid и Mailgun называют нижней границей около 100k писем в месяц, то есть более 3 000 в сутки.
Логика порога прямо завязана на окно памяти. Чтобы приёмник накопил по вашему IP статистически значимую выборку внутри 30-дневного окна и присвоил устойчивую положительную репутацию, ему нужен ощутимый ежедневный объём. Если вы шлёте 300 писем в день, за 30 дней это 9 000 событий — слишком мало и слишком размазано, чтобы IP «прогрелся». Такой адрес вечно висит в статусе «новичок», и любой всплеск жалоб бьёт по нему непропорционально сильно: знаменатель крошечный.
Ниже порога общий IP выигрывает практически всегда. На пуле ESP ваши 300 писем растворяются в миллионах чужих, где статистика уже набрана. Ваш собственный dedicated при том же объёме — одинокий неизвестный адрес, которому никто не доверяет.
Регулярность важнее пиков. Провайдеры считают rolling volume — скользящий объём. Отправили 50 000 в понедельник и тишина до пятницы — для Gmail вы каждый понедельник «новый» отправитель, всплеск на фоне нуля. А всплеск с неизвестного адреса — классическая сигнатура взломанного сервера. Практический порог: не допускать провалов дольше 48–72 часов, а полного простоя — дольше 5–7 дней. Простой свыше недели фактически обнуляет набранную в 30-дневном окне репутацию, и прогрев придётся начинать заново.
Собираем оба параметра в одну картинку.
Прогрев выделенного IP: график и практика
Если вы попали в зелёный квадрант справа-сверху, dedicated оправдан — но его придётся прогревать. Прогрев (warm-up) — это управляемый рост объёма, при котором вы даёте приёмникам время накопить положительную статистику, не спровоцировав throttling.
Базовый график: старт с 50 писем в сутки, рост +30–100% в день, выход на целевой объём за 4–6 недель. Удвоение агрессивнее и подходит только при отличном engagement; +30% безопаснее для холодной базы. Ключевое правило первых дней — слать только самым активным получателям. Открытия и клики от вовлечённых адресатов — сигнал, который приёмник взвешивает выше самого объёма. Начинать прогрев с «мёртвой» базы означает генерировать баунсы и жалобы ровно тогда, когда IP максимально уязвим.
Обратите внимание на синюю кривую: репутация растёт с задержкой 5–7 дней относительно объёма. Вы уже нарастили трафик, а доверие ещё догоняет — именно поэтому нельзя ускорять график «потому что баунсов нет». Красный пунктир — визуальный аргумент про регулярность: остановка на неделе 4 роняет репутацию почти к старту.
Разные приёмники прогреваются по-разному. Gmail и Outlook держат отдельные throttling-лимиты, и во время прогрева вы будете ловить временные отказы 4xx вида «too many messages» или «try again later». Это норма — MTA должен отрабатывать бэкофф и повторять позже, а не долбить. Читайте bounce-коды: 421/451 — притормозить, 550 — уже проблема с репутацией или контентом. Мониторинг обязателен: Google Postmaster Tools (отдельные дашборды IP и domain reputation), Microsoft SNDS для Outlook/Hotmail и грепанье собственных логов.
bash
# Свежие отклонения по репутации/спаму в очереди Postfix
grep -E "status=(deferred|bounced)" /var/log/mail.log \
| grep -iE "reputation|spam|blocked|blacklist|4\.7\.|5\.7\."
Технический фундамент, без которого IP не спасёт
Любой прогрев бессмысленен, если не закрыты базовые проверки. Провайдер отбраковывает письмо ещё до анализа репутации, когда не сходится аутентификация.
PTR/rDNS обязателен и должен совпадать с HELO/EHLO. Forward-confirmed reverse DNS (FCrDNS) — это когда PTR адреса указывает на хостнейм, а A-запись этого хостнейма возвращается на тот же IP. Без него Gmail режет сразу.
bash
# PTR должен вернуть mail.evilmail.pro
dig -x 203.0.113.10 +short
# A-запись хостнейма должна вернуться на тот же IP (FCrDNS)
dig A mail.evilmail.pro +short
# Каким HELO и сертификатом сервер представляется приёмнику
openssl s_client -connect gmail-smtp-in.l.google.com:25 -starttls smtp
# Листинг в Spamhaus ZEN — реверс октетов IP + зона
dig +short 210.69.22.212.zen.spamhaus.org
Ответ на последнюю команду должен быть пустым. Любой 127.0.0.x — это листинг: 127.0.0.2 (SBL), 127.0.0.3 (CSS), 127.0.0.10/127.0.0.11 (PBL — блокировка «residential/dynamic» адресов на 25-м порту). Выделенный IP от хостинга обязан быть вне PBL, иначе исходящая почта на 25-й порт не уйдёт в принципе.
Дальше — три DNS-записи, которые с февраля 2024 обязательны для любого отправителя ≥5000 писем/сутки на домен:
dns
; SPF — какие IP имеют право слать от домена
evilmail.pro. IN TXT "v=spf1 ip4:203.0.113.10 -all"
; DKIM — публичный ключ подписи
default._domainkey.evilmail.pro. IN TXT "v=DKIM1; k=rsa; p=MIGf..."
; DMARC — политика и отчётность, строгий alignment
_dmarc.evilmail.pro. IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; adkim=s; aspf=s; pct=100"
; PTR (в зоне in-addr.arpa у владельца IP)
210.69.22.212.in-addr.arpa. IN PTR mail.evilmail.pro.
Если у вас пул из нескольких IP, отправку нужно явно привязывать к конкретному адресу. В Postfix это делается через smtp_bind_address и sender-dependent транспорты:
ini
# main.cf — один IP для всей исходящей
smtp_bind_address = 203.0.113.10
# sender-dependent маршрутизация для пула
sender_dependent_default_transport_maps = hash:/etc/postfix/sender_transport
# master.cf — по транспорту на каждый IP пула
out-ip1 unix - - n - - smtp -o smtp_bind_address=203.0.113.10
out-ip2 unix - - n - - smtp -o smtp_bind_address=212.22.69.211
Так вы держите маркетинговые рассылки и транзакционные письма на разных IP — жалобы на промо не топят пароль-ресеты.
Особый случай: temp-mail и inbound, где живёт evilmail.pro
Всё выше — про исходящую почту: транзакционка, рассылки, свой SMTP. Но есть второй мир, где логика IP-репутации переворачивается, — приём почты. Сервисы временной почты вроде evilmail.pro и любые inbound-потоки (регистрации, вебхуки, уведомления) в первую очередь принимают письма на свой MX, а не рассылают миллионами.
Здесь IP-репутация работает в две стороны. На приёме отправляющие серверы проверяют ваш MX-хост по FCrDNS и RBL точно так же, как вы проверяете чужие: «грязный» IP MX-сервера приводит к тому, что письма для ваших пользователей задерживаются или отбиваются на чужой стороне. На небольшой исходящий поток (системные уведомления, подтверждения) IP тоже влияет, но объёмы там низкие и стабильные.
Для inbound-инфраструктуры выделенный IP почти всегда оправдан — и не из-за объёма, а из-за контроля. Вам нужен собственный PTR, совпадающий с именем MX, и гарантия, что сосед по shared-хостингу не затащит ваш адрес в CSS-листинг именно тогда, когда пользователь ждёт код подтверждения. На общем shared-хостинге temp-mail сервис регулярно ловит чужие блокировки; выделенный MX-IP с корректным rDNS эту зависимость обрывает. Порог окупаемости из первой части тут просто не применяется — критерий другой: контроль и изоляция, а не набор статистики на объёме.
Когда общий IP — честно правильный выбор
Признать это важнее, чем продать вам dedicated:
Объём меньше 2 000 писем/сутки и/или нерегулярная отправка → managed shared pool нормального ESP обыграет ваш собственный dedicated с гарантией.
Нет ресурса на 4–6 недель прогрева и постоянный мониторинг → shared, где за репутацию пула отвечает провайдер.
Риск shared реален — neighbor effect и отсутствие прямого контроля, — но серьёзные ESP активно чистят пулы, снимают проблемных отправителей и балансируют трафик. Для большинства это меньший риск, чем собственный непрогретый адрес.
Чек-лист перед покупкой выделенного IP
Посчитайте устойчивый суточный объём на один IP. Ниже ~5 000 — берите shared, не переплачивайте.
Оцените регулярность: будут ли провалы дольше 48–72 часов или простои дольше 5–7 дней. Если да — dedicated будет постоянно «остывать».
Заложите 4–6 недель на прогрев по графику 50 → +30–100%/день и ресурс на его сопровождение.
Настройте FCrDNS: PTR ↔ A совпадают, HELO равен PTR-хостнейму.
Пропишите SPF (-all), DKIM и DMARC (минимум p=quarantine, строгий alignment).
Проверьте IP по Spamhaus ZEN — он обязан быть вне SBL/CSS/PBL.
Подключите Google Postmaster Tools и Microsoft SNDS/JMRP до, а не после старта.
Сегментируйте базу по engagement — первые дни только самым активным получателям.
Держите метрики в норме: спам-жалобы <0.1% (Gmail жёстко режет при >0.3%), hard bounce <2%.
Решите заранее: один IP или пул с разделением транзакционка/маркетинг через smtp_bind_address.
