Виділений чи спільний IP для розсилок: вибір за репутацією, обсягом і швидкістю прогріву
Виділений IP — не апгрейд і не престиж, а зобов'язання перед арифметикою обсягу. Нижче порогу ~50 000 листів/день dedicated робить доставність гіршою, а не кращою. Розбираємо математику порогу, реальний графік прогріву по днях, гібридну архітектуру потоків і postfix-конфіг розведення по IP.
EvilMail Team12 липня 2026 р.13 хв читання
Чому репутація живе на IP, а не на домені
Найчастіша помилка, з якою до мене приходять клієнти: «ми налаштували DKIM і DMARC на домені, тепер візьмемо власний IP і матимемо ідеальну доставність». Це два різні рівні, які люди зливають в один.
DKIM і SPF дають репутацію на рівні домену — Gmail і Microsoft бачать, що лист криптографічно підписаний вашим доменом, і накопичують історію його поведінки. Але перша фільтрація відбувається раніше, ще на рівні TCP-з'єднання, і там зважується IP-адреса, з якої ви під'єдналися. Обидва провайдери оперують парою «IP + домен»: репутація формується як зв'язка, і саме тому міграція на новий IP скидає частину напрацьованого, навіть якщо домен той самий.
Ключовий наслідок, на якому тримається все далі: новий чистий IP без історії стартує не з «доброго» стану, а з «unknown». Для приймального фільтра «невідомий» — майже те саме, що «підозрілий». Стартового кредиту довіри у вас немає; ви будуєте його з нуля кожним листом.
Звідси два принципово різні продукти:
Спільний (shared) IP — ви орендуєте вже прогріту репутацію, побудовану сусідами по пулу. Плюс: миттєвий старт. Мінус: успадковуєте і їхній спам.
Виділений (dedicated) IP — ви будуєте репутацію самі й повністю нею володієте. Плюс: ніхто вас не топить. Мінус: спочатку ви — той самий «unknown», і поки не наженете статистику, доставність буде гіршою, ніж на shared.
Ось чому dedicated — це зобов'язання, а не апгрейд. Він вимагає обсягу, щоб окупитися.
Математика порогу: коли обсягу вистачає на dedicated
Провайдеру потрібна статистична вибірка, щоб побудувати модель поведінки вашого IP. Модель тримається на стабільному, передбачуваному денному обсязі. Немає обсягу — немає вибірки — IP довічно висить у стані «unknown», а будь-який сплеск трактується як аномалія й летить у спам.
Робочі евристики на 2026 рік:
Менше 5 000 листів/день — тільки shared. Крапка. На виділеному IP при 500 листах/день Gmail фізично не набирає вибірку, щоб відрізнити вас від сплячого спамера. IP лишається «unknown», і кожна розсилка стартує наосліп.
5 000–50 000 листів/день — сіра зона. Вирішує регулярність, а не пік. Стабільні 20k щодня — краще для dedicated, ніж 50k раз на тиждень і тиша між ними.
Стабільно 50 000+ листів/день — dedicated виправданий і бажаний. Обсягу вистачає, щоб тримати IP теплим, а контроль над власною репутацією починає переважати ризик noisy-neighbor.
Нижню межу я називаю «мінімальною підтримувальною дозою» IP: це той денний потік, нижче якого репутація не тримається на плаву й деградує від простою. Виділений IP, який мовчав три дні, на четвертий знову напівхолодний.
Економіка це підтверджує: dedicated IP коштує $30–100/міс плюс ваш час на обслуговування. Ділити цю суму на 500 листів/день — марнотратство, яке ще й погіршує результат.
Прогрів: реальний графік, а не «поступово збільшуйте»
«Поступово збільшуйте обсяг» — порада, після якої на другий день шлють 20k і потрапляють у спам. Прогрів — це не темп, це умовне подвоєння: наступний крок дозволений тільки тоді, коли попередній пройшов чисто.
Ось робочий графік для виходу на 100k/день приблизно за 30 днів. Стартуєте з найактивнішого сегмента — тих, хто відкривав вас за останні 30 днів. Ранній позитивний відгук будує репутацію швидше за будь-який обсяг.
День
Обсяг/день
Сегмент
Умова переходу далі
1
50
відкривачі 30 днів
bounce < 2%, скарги < 0.1%
2
100
ті самі
те саме
3
200
+ відкривачі 60 днів
те саме
5
500
+ 90 днів
те саме
8
1 500
активна база
те саме
12
5 000
активна база
стежити за Postmaster
18
20 000
+ напівактивні
тримати spam rate < 0.1%
25
60 000
повна чиста база
—
30
100 000
цільовий обсяг
вихід на плато
Головне правило: обсяг ніколи не біжить попереду довіри. Репутація IP росте із затримкою відносно потоку — спершу ви шлете, потім провайдер спостерігає й повільно піднімає оцінку. Погнати обсяг швидше, ніж встигає рости оцінка, — і ви влітаєте в червону зону, де фільтр бачить незнайомий IP з різко зростаючим потоком. Це класичний профіль спамера.
При відкаті — коли bounce перевалив за 2% або скарги за 0.1% — реакція одна: тримати або знижувати обсяг, а не збільшувати. Це контрінтуїтивно, але провайдер щойно сказав вам, що не встигає вас переварити. Дайте йому надолужити.
Ще одне, що новачки пропускають: репутація не одна. Gmail, Outlook і Yahoo ведуть її окремо, кожен за своїм зрізом одержувачів. IP може бути «High» у Google і водночас «фільтрований» в Outlook, бо там ваша база менша й вибірка тонша. Тому прогрів розкладають не лише по днях, а й по провайдерах: тримайте окремі per-destination ліміти в MTA (у Postfix — smtp_destination_rate_delay і default_destination_concurrency_limit, ще краще — policyd/postfwd), щоб не завалити один поштовик, поки решта ще холодні. Якщо Yahoo відповідає 421 4.7.0 [TS03] або Gmail — 421 4.7.28, це не помилка конфігурації, а сигнал «пригальмуй саме до нас».
Shared IP: коли це розумний дефолт, а не компроміс
Спільний IP незаслужено вважають «економ-варіантом для бідних». Для транзакційних і низькооб'ємних потоків це технічно правильний вибір, а не поступка.
Плюси, за які варто платити:
Миттєва прогрітість. Пул уже теплий, ваш перший лист доставляється як тисячний.
Амортизація ризику. Ваш випадковий сплеск розчиняється у сумарному потоці пулу.
Нуль обслуговування. Не треба гріти, стежити за rDNS, тримати мінімальну дозу.
Мінуси без прикрас:
Noisy neighbor. Один спамер у пулі — і тимчасове зниження доставності зачіпає всіх. Чужі скарги ви не контролюєте.
Блок пулу б'є по вас. Якщо IP потрапив у Spamhaus через сусіда, страждаєте і ви.
Складніша діагностика. Важче відділити свій сигнал від шуму пулу.
Головний критерій при виборі провайдера shared-пулу: сегментація за репутацією відправника. Хороший провайдер розкладає клієнтів по пулах за їхньою поведінкою — чисті відправники в одному казані, ризикові в іншому. Один спільний казан на всіх — червоний прапор.
Гібрид: розділення потоків як найкраща інженерна відповідь
Для більшості серйозних сендерів правильна відповідь — не «або/або», а розведення потоків за їхньою природою.
Транзакційні листи (паролі, чеки, 2FA) мають високий відгук і критичну вимогу до доставності — їх ставлять на надійний shared або окремий dedicated. Маркетинг і бюлетені з їхніми неминучими скаргами йдуть на свій dedicated. Різні субдомени розділяють репутацію так, щоб скарга на розсилку не топила лист про скидання пароля:
транзакційка → mail.evilmail.pro
маркетинг → news.evilmail.pro
Технічно розведення по різних IP у Postfix робиться через кілька smtp-транспортів у master.cf, кожен зі своїм smtp_bind_address, і маршрутизацію за адресою відправника:
# master.cf — два вихідні транспорти, кожен зі своїм IP
out-tx unix - - n - - smtp
-o smtp_bind_address=203.0.113.10
-o syslog_name=postfix-tx
out-mkt unix - - n - - smtp
-o smtp_bind_address=212.22.69.211
-o syslog_name=postfix-mkt
Після редагування — postmap /etc/postfix/sender_transport && systemctl reload postfix. Тепер транзакційка й маркетинг фізично виходять з різних IP і будують репутацію незалежно.
Розведення по IP — лише половина роботи. Щоб репутації справді не змішувалися, кожен субдомен має власний DKIM-селектор і власний SPF, а From: і Return-Path: мають бути в одному субдомені — інакше DMARC-вирівнювання зламається й маркетинговий потік почне «позичати» історію транзакційного. Практично: mail.evilmail.pro підписуєте селектором tx1._domainkey, news.evilmail.pro — mkt1._domainkey, і envelope-sender (bounce-адресу) кожного потоку тримаєте у його ж субдомені. Тоді скарга на акцію б'є рівно по news. і жодним чином не зачіпає лист про скидання пароля.
Що моніторити після переходу
Прогрів наосліп — це не прогрів. Мінімальний набір дашбордів, які мають бути підключені до першого листа з нового IP:
Google Postmaster Tools — IP reputation (Bad/Low/Medium/High), Domain reputation, Spam rate. Тримати spam rate під 0.1%; критичний поріг Gmail — 0.3% (обов'язкова вимога до bulk-відправників від 5k/день, чинна з лютого 2024). Для доступу DKIM-домен має бути верифікований TXT-записом.
Microsoft SNDS + JMRP. SNDS дає дані по вашому IP на боці Outlook/Hotmail; JMRP — feedback loop, який повертає вам скарги, щоб ви чистили список.
dig +short 210.69.22.212.zen.spamhaus.org
# порожньо = чисто; будь-який 127.0.0.x = ви в списку
Ключові пороги здоров'я, які тримаєте постійно: bounce rate < 2%, complaint rate < 0.1%. Якщо в Postmaster reputation впала з High до Medium — це не привід чекати. Це 24-годинне вікно на реакцію: зменшити обсяг, вирізати найпасивніший сегмент, перевірити, чи не поламався один зі шаблонів зі сплеском скарг.
Дивіться на тренд, а не на точку. Postmaster показує дані із затримкою в добу-дві й вимагає щонайменше кількасот листів провайдеру на день, щоб узагалі щось малювати — тому під час прогріву перші графіки будуть рвані, і це норма. Тривожить не одноденний провал, а стійкий нахил униз три дні поспіль. І звіряйте одне з одним: якщо spam rate у Postmaster тримається низько, а доставність усе одно просіла, проблема, найпевніше, не в репутації, а в контенті чи автентифікації — тоді дивіться Authentication-Results, а не крутите обсяг.
Швидкий тест доставки й читання автентифікації:
bash
swaks --to [email protected] --from [email protected] --server 203.0.113.10
# у вхідному листі дивимось Authentication-Results:
# spf=pass dkim=pass dmarc=pass — усі три мають бути pass
Чекліст переходу на dedicated
PTR/rDNS з FCrDNS.dig -x 203.0.113.10 має віддавати mail.evilmail.pro, а A-запис mail.evilmail.pro — вказувати назад на той самий IP. Без прямо-зворотного збігу Gmail відповість 550.
HELO/EHLO дорівнює PTR-імені. Розбіжність — мінус до довіри.
SPF з новим IP. Після стабілізації жорсткий: v=spf1 ip4:203.0.113.10 -all.
DKIM 2048-bit, селектор напр. s1._domainkey, ротація ключів раз на 6–12 місяців.
DMARC поетапно:v=DMARC1; p=none; rua=mailto:[email protected]; pct=100 → через 2–4 тижні p=quarantine → далі p=reject.
Warm-up графік узгоджений, і хтось відповідає за щоденне рішення «рости чи плато».
Postmaster Tools і SNDS/JMRP підключені до першої відправки.
Список почищено за sunset policy: адреси без відкриттів 90–180 днів — на виключення, щоб engagement-сигнал під час прогріву був максимально чистим.
Окремий субдомен для маркетингу (news.), відділений від транзакційки (mail.).
Feedback loop зареєстровано там, де він є (JMRP для Microsoft).
Виділений IP окупає свої $30–100/міс тільки тоді, коли за ним стоїть обсяг, що тримає його теплим, і дисципліна, що тримає його чистим. Немає обсягу — беріть shared і не оглядайтесь. Є і обсяг, і два різні за природою потоки — розводьте їх гібридом, і кожен лист про пароль перестане залежати від того, скільки скарг зібрала вчорашня акційна розсилка.
