IOSOR

IOSOR База знань

Прогрів email-домену: dedicated vs shared і чому холодний домен не можна «вибухати»

Як B2B прогріває транзакційні домени — виділена vs спільна репутація, гальма bounce і скарг, ворота SPF/DKIM/DMARC і prepaid-чесність до production-обсягу.

Холодний домен, який у день один розсилає чеки, посилання входу й «разові» промо, — не амбіція, а спосіб навчити транзакційну пошту теки спаму. Прогрів — це крива довіри з темпом: приймачі дивляться форму обсягу, bounce, скарги й вирівнювання автентифікації, перш ніж вважати вас відомим відправником. Dedicated і shared ламаються по-різному, але обидва карають тих, хто пропускає криву.

IOSOR тримає транзакційний email як white-label prepaid поряд із messaging: кожна відправка — рядок debit, каталог чесно live або in setup, незакрита auth — не production-значок. Біля USD 1 000+ місячного platform usage bounce/скарги й нахил прогріву стають матеріалом комерційного review. Спочатку evidence, потім scale.

Dedicated і shared прогрів

Шлях Чим володієте Наслідок для прогріву
Виділений домен / identity Ваша репутація, ваші помилки Ви задаєте темп; ви платите за blast
Спільний пул Сусіди можуть вас подряпати Гігієна й auth усе одно обов’язкові
Суміш промо + транзакційка Найгірше з обох Листи входу успадковують скарги промо

Dedicated — не «безлімітний blast після DNS». Це іменована identity з планом обсягу, власниками і kill switch. Shared — не «проблема сусіда»: брудний список усе одно палить prepaid і користувачів. Закрийте автентифікація email до продакшену, перш ніж сперечатися, який шлях дешевший.

Не вибухайте холодний домен

Прогрів означає: почніть із трафіку, який приймачі вже чекають (чеки, скидання пароля відомим користувачам), піднімайте денний обсяг за записаним нахилом, зупиняйтесь, коли спрацьовують гальма bounce/скарг, і ніколи не ховайте маркетинговий blast усередині «транзакційної» identity. Новий піддомен усе ще холодний. Каталог in setup — не звільнення від прогріву. Заздалегідь купленого пулу прогрітих доменів на нічну підміну немає — JIT-чесність для email-identity та сама, що для номерів.

Bounce і скарги як гальма прогріву

Hard bounce, повторений під час прогріву, — як чиста identity стає відфільтрованою. Скарга — судження людини: одразу suppress. Deferral — це темп, не чистка списку. Зберіть bounce, complaint і deferral на одній сторінці з власниками; див. bounce проти скарг. Якщо автоматизація прогріву не вміє зупинитися за complaint rate, у вас не прогрів, а запланований blast.

Гаманець і ворота auth

Prepaid email без SPF/DKIM/DMARC — принтер debit у спам. Ворота до live: названі identity, опубліковані записи, власник DMARC-звітів, спільний suppression-список, рядки гаманця до подій відправки. Зв’яжіть із email на тому самому prepaid-ledger, щоб фінанси бачили обсяг прогріву як usage, а не загадковий бічний рахунок. Low-balance stop діє: job прогріву не повинен тихо йти в овердрафт, поки ops «дає докрутитися».

Червоні прапорці

  • Blast у день один із нового домену
  • Промо і скидання пароля на одній identity
  • Значок live при незакритих SPF/DKIM/DMARC
  • Hard bounce ретраять «про всяк випадок»
  • Немає власника complaint rate на прогріві
  • Каталог in setup продається як production inbox
  • Помилки з чужими поштовими брендами

Початок з IOSOR

Назвіть транзакційний From і оберіть dedicated або shared до першої відправки. Закрийте SPF, DKIM і звіти DMARC на цьому шляху. Напишіть семиденний нахил із гальмами bounce і скарг саме для обраного шляху й шліть лише очікувану пошту відомим користувачам. Звірте рядки prepaid-гаманця з accepted проти bounced, перш ніж піднімати обсяг.

Підсумок IOSOR

Холодний домен не можна підривати. Dedicated-прогрів будує репутацію вашого IP; shared успадковує сусідів.

Робіть: закрийте auth, тоді піднімайтеся похилом обраного шляху. Не робіть: не копіюйте dedicated-похил на спільний пул і не стрибайте в обсяг сьомого дня в перший.

Чи був матеріал корисним?

Пов’язані гіди