Перейти к основному содержанию
AFF Lab
Доставляемость писем

Доставляемость писем 2026: почему каждое третье не доходит

В наших клиентских рассылках примерно каждое третье письмо не доходит до «Входящих» — тихо, без отбоя. Что чинят аутентификация, репутация и содержимое.

Автор Mark Barkan 22 мин чтения
На странице

Из холодных рассылок, которые мы вели клиентам последние два года, примерно каждое третье письмо так и не доходит до «Входящих». Оно не отбивается. Его не отклоняют. Оно тихо оседает в папке «Спам» Gmail, Outlook или фильтра принимающего сервера — невидимо для адресата, не учтено инструментом рассылки, помечено как «доставлено» в любом отчёте, который вы откроете. Этот разрыв между доставлено и увидено — и есть то, о чём на самом деле идёт речь, когда говорят про доставляемость писем, и именно здесь большинство холодных рассылок умирают, а никто этого не замечает.

Большая часть того, что пишут на эту тему в 2026, всё ещё промахивается мимо реальной механики. Это длинная версия. К концу вы будете понимать, как Gmail и Microsoft на самом деле оценивают ваши письма, какие шаги по аутентификации и репутации реально работают (а какие — театр) и как выглядит ежедневный операционный ритм отправителя, который думает о доставляемости. Мы опираемся на инфраструктуру, которую держим сами в AFF Lab: прогрев доменов в объёме, Postfix и OpenDKIM в бою и данные реальных клиентских рассылок.

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

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

«Доставлено» — это не то, что вы думаете

Первую путаницу надо убрать сразу: слова доставлено, попадание во «Входящие» и доставляемость сплошь и рядом используют в разных смыслах, и именно в зазоре между ними умирает большинство холодных рассылок.

Когда ваш инструмент рассылки говорит, что письмо доставлено, обычно это значит одно: принимающий SMTP-сервер принял письмо на шлюзе и вернул 250 OK. И всё. Сервер согласился взять письмо. Что произойдёт дальше — окажется оно во «Входящих», в «Спаме», во вкладке «Промоакции» или в карантине, который пользователь никогда не открывает, — решает уже принимающая система, а не отправитель.

Метрика, которая действительно важна, — это доля попадания во «Входящие»: из каждых 100 принятых писем сколько оказалось в основной папке, где их увидит живой человек. Отраслевые ориентиры для холодных писем B2B в 2026 лежат в довольно широком диапазоне:

Что мы видим на собственной отправляющей инфраструктуре, в разбивке по состоянию отправителя:

Состояние отправителяТипичное попадание во «Входящие»
Хорошо настроенный домен, прогрет 6+ недель75–90%
Новый домен, аутентификация настроена верно50–70%
Новый домен без прогрева20–40%
Домен в публичном чёрном списке5–20%
Аутентификация не проходит (нет SPF/DKIM)10–30%

Невидимая для вас потеря, о которой мы сказали в начале, — это разница между отчётом инструмента «95% доставлено» и реальным попаданием в 60%. Ничто в вашей платформе рассылки об этом не скажет. Узнать это можно лишь двумя способами: тестом по контрольным ящикам (отправка на панель тестовых ящиков у разных провайдеров) или сторонними инструментами — GlockApps, MailGenius, Mailtrap. Настройте это до того, как отправите первую рассылку. Иначе вы летите вслепую.

Три слоя доставляемости

Современные почтовые провайдеры (Gmail, Microsoft, Yahoo, Apple) решают, куда положить ваше письмо, на основе трёх независимых слоёв. Разберём каждый по очереди, но сначала важно понять саму структуру: большинство «лайфхаков по доставляемости», о которых пишут в интернете, зациклены на одном слое и полностью игнорируют другой.

  1. Аутентификация. Верит ли принимающий сервер, что отправитель тот, за кого себя выдаёт? Этим занимаются SPF, DKIM, DMARC и ARC. Сбой здесь бинарный: большинство крупных провайдеров теперь попросту отклоняют или отправляют в карантин массовую почту без аутентификации.
  2. Репутация. Доверяет ли получатель этому домену и IP на основе их прошлого поведения? Доля жалоб на спам, доля возвратов, вовлечённость, статус в чёрных списках и стабильность паттерна отправки — всё это сворачивается в репутационный балл, который получатель считает у себя, ни с кем не делясь. Свой балл вы напрямую не видите; его можно только вывести косвенно.
  3. Содержимое и вовлечённость. Похоже ли само письмо на спам и взаимодействуют ли с ним реальные пользователи после доставки? Заголовки, тело письма, паттерны ссылок, соотношение картинок и текста, поведение получателя (открытия, ответы, отметки «Спам») — всё это питает классификацию по каждому письму.

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

Слой 1: аутентификация как надо

Это фундамент. Каждый современный почтовый провайдер теперь требует как минимум SPF и DKIM, а DMARC переходит из «рекомендуется» в «ожидается»: с февраля 2024 Google требует от массовых отправителей (свыше 5000 писем в день в Gmail) настроить SPF и DKIM и опубликовать запись DMARC, пусть даже с самой мягкой политикой p=none, при условии что домен в поле From выровнен по SPF или DKIM.[1] Yahoo ввёл те же требования к аутентификации и DMARC (минимум p=none), не называя порога по объёму.[2]

Три записи, которые нужно опубликовать:

  • SPF (Sender Policy Framework) — запись DNS TXT со списком серверов, которым разрешено отправлять почту от вашего домена. Принимающие серверы сверяют отправителя из конверта с этим списком.
  • DKIM (DomainKeys Identified Mail) — криптографическая подпись, добавляемая к каждому исходящему письму. Получатель забирает ваш открытый ключ из DNS и проверяет подпись.
  • DMARC (Domain-based Message Authentication, Reporting & Conformance) — говорит получателям, что делать, когда SPF или DKIM не проходят, и куда слать сводные отчёты.

SPF и DKIM — не альтернативы, нужны оба. SPF аутентифицирует отправляющий IP («имеет ли этот сервер право слать от этого домена?»); DKIM аутентифицирует само письмо («не изменили ли его в пути?»). SPF ломается при пересылке почты; подпись DKIM её переживает. DMARC хочет, чтобы хотя бы один из них проходил с выравниванием, и держать оба — это тот самый ремень с подтяжками, который сохраняет аутентификацию, когда один из них ломается. Три раздела ниже — это точная настройка каждой записи: сначала SPF и DKIM, потом DMARC, который их связывает.

Настройка SPF (по шагам)

SPF (Sender Policy Framework) — это одна запись TXT в корне отправляющего домена, перечисляющая серверы, которым разрешено слать почту от вашего имени. Когда письмо приходит, получатель ищет эту запись и сверяет отправляющий IP со списком — совпадение проходит, промах читается как сигнал спама. Запись выглядит так:

v=spf1 include:_spf.google.com include:spf.smartlead.ai ~all

Шаг 1 — перечислите каждый сервис, который отправляет от вашего домена. Провайдер почтовых ящиков (Google Workspace, Microsoft 365), ваш инструмент холодной рассылки (Smartlead, Instantly, Lemlist, Apollo) и любой транзакционный или CRM-отправитель (SendGrid, Mailgun, HubSpot). Пропустите хоть один — и его почта провалит SPF.

Шаг 2 — соберите значение include: для каждого сервиса из его документации: Google Workspace include:_spf.google.com, Microsoft 365 include:spf.protection.outlook.com, SendGrid include:sendgrid.net. Объедините их в одну строку, которая начинается с v=spf1 и заканчивается замыкающей директивой.

Шаг 3 — опубликуйте одну запись TXT в корне (@) отправляющего домена со значением из строки выше, TTL по умолчанию. Одна запись SPF на домен, никогда не две — несколько записей v=spf1 аннулируют друг друга.

Шаг 4 — проверьте после распространения (5–60 минут) командой dig +short TXT yourdomain.com или проверялкой SPF от MXToolbox, которая заодно проверит синтаксис и число запросов.

Работает она или нет, решают два правила. Ставьте ~all (мягкий отказ), а не -all (жёсткий отказ), пока не убедитесь, что перечислен каждый легитимный сервис — преждевременный -all отклонит вашу же почту в тот момент, когда вы забудете один сервис; ужесточайте до -all только после месяца чистой отправки. И держитесь в пределах лимита в 10 запросов DNS: каждый include: считается, вложенные includes тоже, а превышение выдаёт permerror, который большинство получателей читают как прямой провал SPF.[3] Если глубокие цепочки includes (Salesforce, HubSpot) выводят вас за 10, разверните includes в IP-адреса или уберите сервисы, которыми уже не пользуетесь. Никогда не используйте +all (разрешает кому угодно) или ?all (без мнения) — оба обнуляют смысл записи.

Настройка DKIM (по шагам)

DKIM (DomainKeys Identified Mail) добавляет криптографическую подпись к каждому исходящему письму. Отправляющий сервис подписывает закрытым ключом; получатель забирает соответствующий открытый ключ из вашего DNS по адресу <selector>._domainkey.yourdomain.com и проверяет подпись — это доказательство, что письмо пришло с вашего домена и не было изменено в пути.[4] В опубликованной записи хранится только открытая половина:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQK...

Шаг 1 — сгенерируйте пару ключей. Почти каждый сервис делает это за вас и отдаёт открытый ключ для публикации (Google Workspace: Admin Console → Apps → Gmail → Authenticate email → Generate new record). Самостоятельно поднятый Postfix использует opendkim-genkey.

Шаг 2 — запишите селектор, который выдал сервис (google, s1, smartlead, default). Хост в DNS — это <selector>._domainkey, например google._domainkey.

Шаг 3 — добавьте запись TXT по этому хосту со значением открытого ключа. Используйте ключи на 2048 бит; они превышают лимит в 255 символов на строку TXT и разбиваются на несколько строк в кавычках — большинство провайдеров DNS делают это за вас, но убедитесь через dig, что весь ключ попал целиком. Никогда не кладите закрытый ключ в DNS.

Шаг 4 — проверьте, что запись резолвится: dig +short TXT <selector>._domainkey.yourdomain.com.

Шаг 5 — проверьте, что подпись действительно ставится. Опубликованный ключ не означает, что почта подписывается. Отправьте тестовое письмо и убедитесь, что на выходе есть заголовок DKIM-Signature, а у получателя — dkim=pass в Authentication-Results. Этот шаг ловит самый частый сбой — правильную запись поверх сервиса, у которого подпись так и не включили.

Дайте холодной рассылке собственный селектор, отдельный от транзакционной почты, чтобы удар по репутации одного потока никогда не задевал другой; а когда у вас несколько отправляющих сервисов, дайте каждому свой селектор, чтобы их ключи оставались изолированными. Большинство команд настраивают DKIM один раз на сервис и раз в год меняют ключи ради гигиены безопасности.

Настройка DMARC и выбор политики

DMARC связывает SPF и DKIM и говорит получателям, что делать, когда те не проходят. Одна запись TXT по адресу _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r

p= — это политика (о ней ниже); rua= — куда слать сводные отчёты, укажите ящик, который вы действительно проверяете; adkim/aspf задают режим выравнивания, и мягкий режим (r) подходит почти всем. DMARC проходит только тогда, когда SPF или DKIM не просто проходит, а выравнивается с доменом в поле From: письмо с outreach.example.com и заголовком From [email protected] не проходит выравнивание даже с валидной подписью. И запись на example.com не покрывает поддомен mail.example.com — задайте sp=, если с ваших поддоменов идёт отправка.

Политика — это лестница, и ошибка, которая губит доставляемость, — прыгнуть сразу на её верх.

  • p=none (наблюдение). Получатели ничего не меняют, но шлют вам отчёты. Всегда начинайте отсюда. Побудьте здесь 2–4 недели — пока отчёты не подтвердят, что 100% вашей легитимной почты проходит SPF или DKIM с выравниванием.
  • p=quarantine. Не прошедшая почта уходит в спам вместо «Входящих» — понижена, но не потеряна. Раскатывайте постепенно ручкой pct=: p=quarantine; pct=10 отправляет в карантин 10% не прошедшей почты[5]; поднимайте до 25, 50, затем 100 за 2–3 недели, следя за отчётами. Именно здесь большинству отправителей холодных писем B2B стоит остановиться.
  • p=reject. Не прошедшая почта отбивается сразу — самый сильный сигнал против подделки и самый беспощадный: любая брешь в аутентификации молча теряет реальную почту. Приберегите её для банков, госсектора и брендов с высоким риском подделки отправителя, у которых есть операционная строгость под это.

Сделанная правильно, полная миграция занимает 6–12 недель. Сжать её или пропустить p=none — вот так команды и оказываются в ситуации, когда неделями отбивают собственную почту, прежде чем понять, почему.

Ещё два режима сбоя переживают даже правильный набор записей:

  • Свой SMTP без записи PTR. Обратный DNS в 2026 всё ещё важен. Без записи PTR, указывающей обратно на имя хоста отправителя, Gmail понижает вас, как бы чисто ни выглядели SPF, DKIM и DMARC.
  • Пропуск ARC. Если ваша холодная почта проходит через сервис, который переподписывает или пересылает (Google Groups, списки рассылки, некоторые агентства), заголовки ARC сохраняют исходную цепочку аутентификации. Большинству отправителей холодных писем это не нужно, но если вы видите провалы DMARC на письмах, которым доверяете, — причина, скорее всего, в ARC.

Когда аутентификация выстроена, вы заслужили право отправлять — но отправка это лишь половина проводки.

DNS-панель Cloudflare для домена отправителя: записи A, MX, SPF, DKIM и DMARC, политика DMARC раскрыта
Полностью настроенный домен отправителя. Обратите внимание на колонку Proxy status: веб-записи проксированы, все почтовые — DNS only. Проксирование MX молча ломает входящую почту.

MX-записи: что это и как их настроить

Аутентификация — это всё про отправку. Но холодная рассылка работает, только если ответы возвращаются, — а начинается это с MX.

Запись MX (Mail eXchange) говорит интернету, куда доставлять почту, адресованную вашему домену. Это имя хоста плюс значение приоритета (меньше = пробуют первым); принимающий сервер смотрит ваши записи MX и доставляет на отвечающий хост с наименьшим приоритетом. Нет записи MX — нет ответов, и вы этого не заметите, потому что возврат уходит адресату, а не вам; они просто как будто замолкают. Сервисы верификации тоже читают MX, чтобы понять, способен ли домен вообще принимать почту, так что домен, который шлёт в объёме без MX, выглядит подозрительно.

Для Google Workspace в 2026 настройка — это одна запись:

Type: MX   Host: @   Value: smtp.google.com   Priority: 1

Она заменила старый набор из пяти записей aspmx.l.google.com (приоритет 1 плюс четыре запасных alt); старый формат всё ещё работает, но новым доменам стоит использовать одну запись.[6] Шаги:

Шаг 1 — откройте DNS домена у своего провайдера (Cloudflare, Route53, GoDaddy, Namecheap).

Шаг 2 — удалите все устаревшие записи MX, оставшиеся от прежнего провайдера. Смешение старых и новых записей MX делает маршрутизацию непредсказуемой.

Шаг 3 — добавьте запись MX сверху: хост @ для корня домена, значение smtp.google.com, приоритет 1. Задавайте приоритет явно — некоторые провайдеры по умолчанию ставят 0 или 10, что не совпадёт.

Шаг 4 — проверьте после распространения командой dig +short MX yourdomain.com (ожидаете одну запись, smtp.google.com, приоритет 1), затем подтвердите в Admin Console → Apps → Gmail → Verify your domain.

Две вещи держите в голове. Указывайте MX на имя хоста с реальной записью A, никогда на CNAME — часть получателей отклоняет MX через CNAME. И дайте каждому отправляющему поддомену, который должен принимать почту, свою запись MX. Частая путаница: инструменты холодной рассылки (Smartlead, Instantly, Apollo) — это отправляющие платформы, им записи MX не нужны; они нужны провайдеру вашего почтового ящика.

Отправка и чтение почты: SMTP и IMAP

SMTP (порты 587 STARTTLS или 465 SSL) отправляет вашу исходящую почту. IMAP (порт 993) читает «Входящие» и папку отправленных. Платформам холодной рассылки нужны оба: SMTP чтобы отправлять, IMAP чтобы отслеживать ответы, подтверждать отправку, замечать возвраты и авто-ответы и вести единый общий ящик. Настроите только SMTP — платформа шлёт, но никогда не видит ответов. Две практические заметки на 2026: аутентифицируйтесь через пароль приложения или OAuth, никогда паролем от аккаунта — Microsoft 365 полностью убрал базовую SMTP-аутентификацию, так что OAuth там обязателен, — а на больших объёмах предпочитайте отправку через API (Gmail API, Microsoft Graph) вместо SMTP ради более высоких лимитов и более чистой обратной связи о доставке. Не используйте POP3: он стягивает почту с сервера и ломает постоянное состояние, на которое опираются платформы холодной рассылки.

Когда сантехника на месте, репутация решает, прочитает ли кто-нибудь вообще то, что вы отправляете.

Слой 2: репутация, невидимое табло

Вот часть, о которую спотыкаются новые отправители: даже идеально аутентифицированное письмо с совершенно нового домена попадёт в спам у Gmail. Причина — репутация.

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

У нового домена репутации нет. Для Gmail «нет репутации» ближе к «не доверяем», чем к «нейтрально». Поэтому шаг номер один для любого нового отправителя холодных писем — это прогрев домена — постепенное наращивание объёма отправки и вовлечённости, чтобы наработать послужной список.

Механика типичного прогрева:

  • Недели 1–2: отправляйте 5–10 писем в день на ящики, которыми управляете сами или которые участвуют в пуле прогрева. Открывайте каждое письмо, отвечайте примерно на треть, любое попавшее в спам возвращайте во «Входящие».
  • Недели 3–4: нарастите до 25–50 писем в день. На период прогрева держите долю ответов от корреспондентов прогрева около 20–30% — это цель прогрева на посевных ящиках, а не ориентир для холодных кампаний.
  • Недели 5–6: 100–200 в день, включая несколько настоящих писем рассылки, подмешанных в поток.
  • Неделя 7+: аккуратно наращивайте до реального объёма рассылки, каждую неделю отслеживая попадание во «Входящие».

Пропуск прогрева стоит вам первого месяца рассылок — они уйдут прямиком в спам. Несколько инструментов это автоматизируют (Mailwarm, Lemwarm, Warmup Inbox, встроенный прогрев Instantly). Все они делают примерно одно и то же: гоняют письма между ящиками-участниками и имитируют вовлечённость. Это не магия — они лишь выигрывают вам время, чтобы наработать послужной список, не выжигая реальных адресатов.

Помимо прогрева, текущая репутация зависит от пяти показателей, за которыми следят получатели:

СигналЧто измеряетЗдоровый диапазон (холодный B2B)
Доля жалоб на спам% получателей, нажавших «Пожаловаться на спам»< 0.1%
Доля возвратов% писем, отклонённых принимающим сервером< 2%
Доля ответов% писем, на которые ответил человек> 3% (тёплый сигнал)
ВовлечённостьОткрытия и клики (в 2026 весят меньше)зависит от случая
Стабильность отправкиКолебания объёма день ото днянизкие

Доля жалоб на спам — безусловно, главный убийца. Стоит вам перешагнуть 0.1% — то есть одна жалоба на тысячу писем — Gmail быстро режет вам скорость и потом ещё несколько недель держится настороже.[1] Доля возвратов тоже важна; выше 2% намекает на плохую гигиену списка, а это получатели читают как признак того, что вы шлёте по спарсенным или устаревшим данным.

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

Самое трудное в управлении репутацией: потерять её можно за считаные дни, а восстанавливать — неделями. Один плохой заход (устаревший список, тема письма, убивающая доставляемость, внезапный пятикратный скачок объёма) может уронить вашу долю попадания на 20–30 процентных пунктов за одну ночь. Восстановление требует возврата к малым объёмам, высокой вовлечённости и терпения. Закладывайте это заранее. Отправители, которые относятся к репутации своего домена как к хрупкому активу — а она хрупкая, — переживают тех, кто так не делает.

Слой 3: содержимое и сигналы вовлечённости

Контентные фильтры в 2026 — это совсем не спам-фильтры 2010-х, блокировавшие по ключевым словам. Gmail и Microsoft оба гоняют обученные модели, которые комбинируют сотни признаков: структуру заголовков, языковые паттерны тела письма, домены ссылок, соотношение картинок и текста, паттерны отправки, историю взаимодействия получателя. Их не обойти трюками вроде «FR3E» вместо «FREE».

Что вы можете сделать — избегать паттернов, которые устойчиво коррелируют со спамом в обучающих данных.

Темы писем. Избегайте сплошного КАПСА, нескольких восклицательных знаков, символов валют перед суммами, маркеров срочности («ACT NOW», «limited time»), а также префиксов «Re:» и «Fwd:» при первом контакте (последнее раньше работало, а теперь активно вызывает флаг). Темы, которые хорошо работают в холодных письмах B2B, обычно короткие (3–7 слов), конкретные и ссылаются на что-то про получателя или его компанию.

Тело письма. Самый большой красный флаг в 2026 — это ощущение шаблона: тело, которое читается как 10 000 других одинаковых писем. Фильтры замечают это и через оценку схожести текстов, и через отсутствие переменных персонализации в отрендеренном HTML. Письмо, которое подставляет только [First Name] и больше ничего, выглядит шаблонным; письмо, которое ссылается на конкретное недавнее событие, деталь должности или факт о компании, выглядит сделанным вручную. Фильтры это различают.

Ссылки. Одна ссылка на письмо — нормально. Две — нормально. Пять-шесть — вызывают срабатывание фильтров. Используйте одну прямую ссылку (ваш домен или сервис для встреч), а не сокращатели ссылок (bit.ly, tinyurl), которые сильно понижаются. Если вы используете собственный домен отслеживания — а вы должны, — убедитесь, что у него свои SPF и DKIM и что он сам не числится ни в каких чёрных списках, независимо от отправляющего домена.

HTML против простого текста. В холодных письмах B2B выигрывает простой текст или легко оформленный HTML. Тяжёлые HTML-письма со встроенными картинками, несколькими шрифтами и вычурной вёрсткой выглядят как маркетинг и попадают в категорию рекламных. Штраф за оформление реален — мы видели одно и то же письмо в двух вариантах (простой текст против оформленного HTML), которое попало во «Входящие» на 78% против 41% в одном и том же пуле доменов.

Ссылка отписки. Требуется для соответствия правилам, но что важнее — её наличие снижает долю жалоб на спам. Получатель, который хочет выйти, воспользуется ссылкой, а не нажмёт «Пожаловаться на спам». Одна эта разница стоит 5–10 пунктов попадания во «Входящие». Отписку в один клик по RFC 8058 (List-Unsubscribe-Post: List-Unsubscribe=One-Click) теперь ожидает Gmail от массовых отправителей (свыше 5000 писем в день)[1] и Yahoo.[2]

Вовлечённость — половина оценки. Получатели придают большой вес тому, что ваши реальные адресаты делают с вашими письмами. Открытия (меньше, чем раньше, с тех пор как Apple Mail Privacy Protection добавил много шума), клики, ответы, удаления без прочтения и отметки «Спам» — всё это возвращается в репутацию по получателю и по домену. Вывод: таргетинг важен не меньше содержимого. Идеальное письмо, отправленное не по тому списку, всё равно проигнорируют, и принимающая система запомнит, что ваш домен шлёт людям, которые не вовлекаются.

Собственные домены отслеживания

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

Собственный домен отслеживания это исправляет: запись CNAME направляет нейтральный поддомен (track., link. или r. — никогда offers. или promo.) на хост отслеживания вашей платформы, так что ссылки читаются как ваш домен, а репутация вашего отслеживания изолирована от чужой. Настройка — 15–30 минут на отправляющий домен: добавьте CNAME, укажите его в платформе и убедитесь, что отрендеренные ссылки идут по HTTPS (ссылка отслеживания по HTTP сама по себе флаг для фильтра). Прямой прирост попадания скромный — пара пунктов, — но изоляция репутации накапливается по мере роста объёма, поэтому боевые команды на 500+ отправках в день считают это стандартной инфраструктурой, а не необязательным дополнением.

Операционка: ежедневная рутина

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

Управление объёмом. Не разгоняйтесь с 50 до 500 писем в день за одну ночь. Увеличивайте объём не больше чем на 30% в неделю и сразу откатывайтесь, если доля попадания падает. Отправляйте в рабочие часы по времени получателя, а не всё одним залпом в полночь.

Гигиена списка. Каждый список нужно чистить перед отправкой. Инструменты проверки адресов (NeverBounce, ZeroBounce, Hunter Email Verifier, Bouncer) ловят недействительные адреса до того, как они дадут возврат — а возвраты напрямую бьют по репутации. Чистка обычно убирает 5–15% любого списка; это норма. Если проверка отмечает больше 25%, ваш источник, скорее всего, спарсен или устарел, и такой список надо выбросить, а не отправлять по нему.

Несколько отправляющих доменов. Опытные операторы холодной рассылки держат несколько отправляющих доменов в ротации. Схема такая: владейте yourbrand.com как основным корпоративным доменом (для транзакционной почты и бренда), а затем регистрируйте варианты вроде yourbrand-mail.com, getyourbrand.com, tryyourbrand.com под холодную рассылку. У каждого варианта свой прогрев, своя репутация, и это ограничивает радиус поражения, если один из них сгорит. Если вы шлёте больше 1000 холодных писем в неделю, это уже не опция.

Мониторинг чёрных списков. Публичные чёрные списки (Spamhaus, SORBS, Barracuda) отмечают домены и IP, которые считают источником злоупотреблений. Попадание туда — обычно симптом, а не причина: к тому моменту, как вы оказались в Spamhaus, ваше попадание уже рухнуло. Но еженедельная проверка ловит проблемы, которые вы иначе пропустили бы. MXToolbox или Multi-RBL check дают просканировать за 30 секунд.

Отчёты DMARC. Когда DMARC выставлен на p=quarantine или p=reject, вам ежедневно приходят сводные отчёты в XML. Большинство отправителей их никогда не читают. В сыром виде они неприятны — XML, технические, объёмные, — но это единственное место, где видны провалы аутентификации от третьих сторон, а это ловит ошибки конфигурации и попытки подделки. Postmark DMARC, dmarcian или EasyDMARC превращают XML в панель за $20–50 в месяц.

Тесты по контрольным ящикам. Прогоняйте тест по контрольным ящикам перед любой рассылкой свыше 1000 писем. Контрольный список — это 30–50 ящиков, распределённых по Gmail, Outlook, Yahoo и корпоративным доменам и используемых как контрольная группа. Отправьте рассылку на контрольный список первым; если попадание ниже 60%, что-то исправьте, прежде чем слать остальное.

Настройка за 30 дней, день за днём

Для совершенно новой отправляющей операции реалистичный график — месяц от регистрации до уверенного объёма рассылки:

  • Дни 1–3. Зарегистрируйте отправляющий домен, настройте SPF, DKIM, DMARC на p=none. Поднимите инфраструктуру почтовых ящиков (Google Workspace или самостоятельный Postfix + Dovecot + OpenDKIM). Настройте записи PTR на своём отправляющем IP. Зарегистрируйтесь в Postmaster Tools и в панели отчётов DMARC.
  • Дни 4–7. Начните прогрев. Стартуйте с 5 писем в день, к концу первой недели дойдите до 25. Ежедневно отслеживайте попадание на небольшом контрольном списке.
  • Дни 8–14. Продолжайте прогрев. Дотяните до 75 писем в день. Переведите DMARC на p=quarantine, когда просмотрите две недели чистых отчётов.
  • Дни 15–21. Начните реальную рассылку в малых объёмах (50 холодных писем в день плюс продолжающийся прогрев). Перед первой реальной отправкой прогоните тест по контрольным ящикам.
  • Дни 22–30. Наращивайте до целевого объёма отправки. Еженедельные тесты по контрольным ящикам, еженедельные проверки по чёрным спискам, ежедневные проверки в Postmaster. Подстраивайте текст, таргетинг и объём по тому, что показывают данные.

Чего Google не объясняет прямо: Postmaster Tools ничего не покажет, пока домен не шлёт на Gmail заметный ежедневный объём в течение нескольких дней подряд. Ниже этого порога все графики отвечают «No data to display» — то есть небольшой или только что прогретый отправитель пока не может использовать его для диагностики. Точный порог Google не публикует. Если графики пустые — сломан не инструмент и не ваш домен: вы просто шлёте на Gmail недостаточно, чтобы данные вообще появились.

После 30 дней у вас реальный домен с реальной репутацией, доставляемость около 75–85% и работающий цикл измерений. Это базовый уровень; дальше текущая работа решает, поднимется ли доставляемость до 85–95% за следующие 90 дней или будет медленно проседать.

Диагностика проблем с доставляемостью: пятиминутный разбор

Когда рассылки внезапно перестают работать, пройдите этот чек-лист по порядку. Большинство проблем решаются на одном из первых трёх шагов.

Шаг 1 — Проверка аутентификации (60 секунд). Прогоните ваш отправляющий домен через MXToolbox SuperTool или dig. Убедитесь, что SPF резолвится без ошибок и держится в пределах 10 запросов DNS. Убедитесь, что селектор DKIM резолвится в валидный ключ. Убедитесь, что запись DMARC существует и использует разумную политику. Если что-то из этого не проходит, чините аутентификацию первым делом — ничто другое не имеет значения, пока эти три не пройдут.

Шаг 2 — Проверка по чёрным спискам (60 секунд). Прогоните ваш отправляющий домен и отправляющий IP через MXToolbox Multi-RBL. Попадания в Spamhaus, SORBS или Barracuda блокируют 80%+ попадания во «Входящие» у крупных провайдеров. Исключение из списка занимает 1–7 дней и требует доказательств, что проблема устранена.

Шаг 3 — Тест по контрольным ящикам (5 минут на прогон, 30 минут на результаты). Отправьте рассылку — или всего одно её письмо — на контрольный список. Если попадание выше 75%, с доставляемостью всё в порядке и проблема в другом (таргетинг, текст, предложение). Если попадание ниже 50%, проблема на стороне отправителя.

Шаг 4 — Проверка недавнего объёма и жалоб. Не подскочил ли объём в последнее время? Не набрала ли недавняя рассылка необычно много жалоб на спам? Gmail и Microsoft режут вам скорость на несколько дней после одного плохого захода. Срежьте объём на 70% на неделю, восстановите вовлечённость, потом медленно наращивайте.

Шаг 5 — Postmaster Tools. Зарегистрируйтесь в Google Postmaster Tools на свой отправляющий домен. Это единственное публичное окно в то, как Gmail видит вашу репутацию.[7] Рейтинг репутации домена «Bad» или «Low» означает — прекратите отправку, пока не исправите. «Medium» — поправимо. «High» — это то, чего вы хотите.

Для основателей, которые шлют 20 писем в день, всё описанное выше — избыточно: Google Workspace плюс адекватный текст вполне хватит. Для отделов продаж, которые шлют 200+ писем в день на каждого менеджера сразу в нескольких рассылках, доставляемость — это работа на полную ставку. Большинство команд серьёзно недооценивают её и теряют три месяца воронки, прежде чем понимают, что у них проблема с доставляемостью, а не с текстом. Если вы видите попадание во «Входящие» ниже 60% на домене, который должен работать лучше, или вот-вот масштабируетесь со 100 до 1000 писем в день, арифметика обычно за то, чтобы отдать инфраструктурную работу тем, для кого её поддержка — единственная работа, — а именно этим мы и занимаемся в сервисе email-рассылок AFF Lab. Экономия на одной рассылке, которая реально долетает, окупает это с запасом.

Источники

  1. 1.Email sender guidelines — authentication & spam-rate requirements — Google Workspace Admin Help
  2. 2.Yahoo Sender Best Practices — authentication & DMARC requirements — Yahoo Sender Hub
  3. 3.RFC 7208 — Sender Policy Framework (SPF) — IETF
  4. 4.RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures — IETF
  5. 5.RFC 7489 — Domain-based Message Authentication, Reporting & Conformance (DMARC) — IETF
  6. 6.Google Workspace MX record values — Google Workspace Admin Help
  7. 7.Google Postmaster Tools — domain/IP reputation & spam rate — Google

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

Почему мои холодные письма уходят в спам?

Почти всегда — сбой в одном из трёх слоёв: аутентификация (SPF/DKIM/DMARC), репутация отправителя или сигналы содержимого и вовлечённости. Каждый необходим; ни один сам по себе не достаточен.

«Доставлено» — значит письмо дошло до «Входящих»?

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

В чём разница между SPF и DKIM — нужны ли оба?

Да, оба. SPF разрешает, каким серверам можно отправлять от вашего домена (проверяет отправляющий IP); DKIM криптографически подписывает письмо, чтобы получатель убедился, что его не изменили. SPF ломается при пересылке, DKIM её переживает. DMARC требует, чтобы хотя бы один прошёл с выравниванием, поэтому в боевых настройках холодной рассылки держат оба.

DMARC ставить на quarantine или reject?

Начните с p=none для наблюдения, перейдите на p=quarantine, когда отчёты покажут, что легитимная почта проходит, и остановитесь — quarantine это правильная конечная точка для большинства отправителей холодных писем B2B. p=reject нужен только банкам, госсектору и брендам с высоким риском подделки отправителя; он отбивает любое письмо, не прошедшее аутентификацию.

~all или -all в SPF-записи?

Ставьте ~all (мягкий отказ), пока не убедитесь, что перечислены все легитимные сервисы. -all (жёсткий отказ) отклоняет любого неуказанного отправителя — включая вашу собственную почту, если сервис пропущен. Ужесточайте до -all только после месяца чистой отправки.

Нужны ли MX-записи для холодных писем?

Да — чтобы принимать ответы. MX-записи направляют входящую почту в ваш ящик; без них ответы адресатов отбиваются, и вы их не видите. Google Workspace использует одну MX-запись (smtp.google.com, приоритет 1). Инструментам холодной рассылки MX не нужны; они нужны провайдеру вашего почтового ящика.

В чём разница между IMAP и SMTP?

SMTP отправляет исходящую почту (порты 587 или 465); IMAP читает входящую почту и папки (порт 993). Платформам холодной рассылки нужны оба — SMTP чтобы отправлять, IMAP чтобы отслеживать ответы, возвраты и подтверждать отправку. Аутентифицируйтесь через пароль приложения или OAuth, но никогда паролем от аккаунта.

Нужен ли собственный домен отслеживания?

Если шлёте в объёме — да. Общий домен отслеживания по умолчанию несёт на себе репутацию всех остальных отправителей на платформе; собственный домен отслеживания (CNAME на нейтральном поддомене вроде track.) изолирует вашу. Настройка занимает 15–30 минут, и изоляция репутации важнее по мере роста объёма.

Все статьи раздела

Похожие статьи