Google Workspace против Microsoft 365 для холодных писем: настройка и масштабирование

Почему выбор настройки для холодных писем влияет на доставляемость

Холодные письма часто «работают» на небольшом объёме, а затем тихо разваливаются при росте отправок. Вы продолжаете те же outreach-кампании, но ответов становится меньше, открытий падает, и письма начинают попадать в спам (или вовсе не доходят). Обычно это не случайность. Это ваш способ отправки, упирающийся в реальные ограничения.

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

Большинство команд в итоге выбирают один из трёх путей отправки:

• Google Workspace mailboxes (вы отправляете из почтовых ящиков под управлением Gmail)
• Microsoft 365 mailboxes (вы отправляете из почтовых ящиков Outlook/Exchange)
• API-based sending (ваше приложение отправляет через email API/провайдера вместо «входа» в традиционный почтовый ящик)

Речь не о том, какой бренд «лучше». Важнее то, что меняет результат при масштабировании: сколько действительно занимает настройка, сколько контроля у вас над репутацией отправителя (домены, почтовые ящики и изоляция), какие ограничения появятся позже и какие ошибки доставляемости типичны для каждого варианта.

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

Простой пример: две команды отправляют по 2000 писем в неделю. Команда A использует свежий домен, прогревается медленно, таргетит узко и получает ответы. Команда B повторно использует один старый список везде, получает отказы и продолжает увеличивать объём. Команда B потеряет попадание во входящие независимо от того, используют ли они Google Workspace, Microsoft 365 или API.

Что на самом деле значит «время настройки» для холодной почты

«Время настройки» — это не только то, как быстро вы можете создать ящик и начать отправлять. Для холодной почты это включает все элементы, которые решают, окажутся ли ваши письма во входящих или потеряются в спаме.

Реалистичная настройка обычно включает:

• Выбор или покупка домена для отправки (часто не основной домен компании)
• Аутентификация в DNS (SPF, DKIM, DMARC)
• Создание почтовых ящиков (и решение, сколько нужно на домен)
• Прогрев новых ящиков так, чтобы они выглядели как обычные отправители
• Подключение инструментов для последовательностей, трекинга и обработки ответов

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

«Скрытая работа» удивляет многие команды. Проблемы с доставляемостью часто рождаются в скучных операционных деталях: обработка отписок, подавление отскоков (жёсткие отказы должны быть исключены немедленно), маршрутизация ответов (чтобы заинтересованные лиды не получали следующий follow-up) и последовательность отправки (резкие скачки объёма выглядят рискованно).

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

Настройка Google Workspace: что занимает время и что может сломаться

Google Workspace — распространённый выбор для outbound, потому что знакомо. Вы создаёте ящики, отправляете из Gmail и подключаете аккаунты к секвенсеру. Разница не в интерфейсе, а в том, насколько надёжно вы можете сделать базовые вещи, не упустив важную деталь доставляемости.

Типичная настройка выглядит так: покупка домена для отправки (обычно отдельного от основного), верификация в Google Admin, добавление SPF/DKIM/DMARC в DNS, создание пользователей и ящиков (пароли, восстановление, политики 2FA), затем подключение ящиков к инструменту отправки и установка лимитов.

Что занимает время, — это редко клики внутри Google. Это работа с DNS и ожидание. DNS-изменения могут распространяться долго, и одна опечатка оставит домен наполовину аутентифицированным. Прогрев требует терпения. Новый ящик, который с нуля переходит на высокий объём, часто будет фильтроваться, даже если всё вроде бы «настроено».

Где чаще всего ломается:

• Запись DKIM добавлена, но подпись фактически не включена в Admin
• SPF слишком свободный или, наоборот, слишком строгий, что вызывает неожиданные ошибки
• DMARC отсутствует или установлен в политику, к которой вы не готовы
• Проблемы с входом (2FA, пароли приложений, уведомления безопасности)
• Внезапные пики отправки, которые приводят к временным троттлингам

Тщательная настройка может занять несколько часов, если вы управляете DNS и знаете шаги, или несколько дней, если нужны утверждения, распространение и прогрев.

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

Пример: солопредприниматель покупает домен, создаёт два ящика и подключает их к секвенсеру в тот же день. Технически всё работает. Но если он пропускает прогрев и начинает с 200 писем на ящик, ответы могут доходить нормально, а письма первого касания уйдут в Promotions или Spam.

Настройка Microsoft 365: что занимает время и что может сломаться

Microsoft 365 может быть надёжным выбором для холодных писем, когда вам нужны знакомые почтовые ящики и админ-контроли, но настройка редко «просто добавь DNS и начни отправлять». Outlook часто ощущается более политически управляемым: он ведёт себя хорошо, когда вы выглядите как нормальный бизнес, и ужесточается, когда паттерны выглядят автоматизированными.

Шаги, которые обычно занимают время:

• Создать tenant, добавить домен и верифицировать его
• Создать пользовательские почтовые ящики (и общие ящики там, где нужно)
• Настроить SPF, DKIM и DMARC корректно
• Просмотреть исходящие и антиспам-политики (особенно фильтрацию исходящего спама)
• Подключить инструмент отправки (SMTP или OAuth), затем протестировать ответы и отказы

Распространённая проблема «вчера работало, сегодня нет» — настройки безопасности по умолчанию. Базовая SMTP-аутентификация часто блокируется, а некоторые инструменты всё ещё на неё завязаны. OAuth может быть чище в долгосрочной перспективе, но добавляет экраны разрешений и админские одобрения, которые люди пропускают.

Контроли входа и рисков добавляют трение. Новые tenant'ы и новые пользователи могут триггерить флаги подозрительных входов, запросы MFA или временные блокировки, особенно если логины происходят из разных мест (например, команда плюс хостованный сервер). Это может остановить отправку, даже если DNS в порядке.

По доставляемости Outlook может быть стабильным при низко–среднем объёме, когда вы медленно наращиваете и поддерживаете вовлечённость. Он становится чувствительным при слишком быстром увеличении объёма с нового ящика, повторном использовании одного шаблона через многие ящики, всплесках отказов или жалоб или при отправке без работающего механизма отписок.

Реалистичное время настройки часто 2–6 часов, если опытный админ делает это с проверенным инструментом отправки. Если вы новичок или ваша организация требует проверок безопасности, рассчитывайте на 1–3 дня плюс время на прогрев перед масштабированием.

API-отправка: больше контроля, больше движущихся частей

API-отправка означает, что ваши письма формирует приложение (или платформа), а затем доставляет служба отправки писем. Вы не «отправляете из почтового ящика» через UI. Вы отправляете через настроенные идентичности отправителя.

Основы всё равно начинаются с домена под вашим контролем. Вы верифицируете его у сервиса отправки и настраиваете аутентификацию, чтобы получатели могли доверять почте. Если SPF, DKIM или DMARC настроены неверно, вы получите тихую фильтрацию, даже если текст письма хорош.

Что настраивают до первого письма

Большая часть работы операционная, а не писательская:

• Верифицировать домен отправки и включить DKIM-подпись
• Опубликовать записи SPF и DMARC, соответствующие вашему отправителю
• Создать выделённую идентичность (домен или поддомен) для холодной почты
• Решить, включать ли трекинг открытий/кликов (или пропустить трекинг, чтобы снизить риск)
• Настроить «From» и обработку ответов в соответствии с процессом

Когда вы начинаете отправлять, вы также отвечаете за негативные сигналы. С провайдерами почтовых ящиков многие вещи скрыты. С API вам придётся всё обрабатывать.

Обязанности, которые нельзя игнорировать

Вам нужен реальный процесс для отказов и жалоб, списки подавления (отписки, жёсткие отказы, жалобщики), постепенный прогрев новых доменов и изоляция, чтобы одна плохая кампания не отравила всё остальное.

Пример: малые SDR-команда переходит на API-отправку для масштабирования. Они забывают обработку жалоб, продолжают повторно отправлять недовольным лидам, и их репутация падает быстро. Та же команда, с правильными списками подавления и медленным прогревом, может масштабироваться безопаснее, чем при чистой почтовой модели, но это требует большего объёма начальной заботы.

Контроль репутации: домены, ящики, IP и изоляция

Репутация отправителя — это ваша история поведения. Она строится со временем из трёх элементов: ваш домен (часть после @), конкретный почтовый ящик или идентичность отправителя и инфраструктура отправки за ним (часто IP-адрес), плюс реакция получателей.

Когда команды сравнивают Google Workspace и Microsoft 365 для холодных писем, они часто сосредотачиваются на интерфейсе и ценах. Для доставляемости важнее вопрос, сколько истории репутации вы можете контролировать и сколько приходится делить с другими.

С Google Workspace или Microsoft 365 вы контролируете домен и почтовые ящики. Но вы не получаете чистого выделенного контроля над подлежащими IP. Вы отправляете через большие общие системы. Это не обязательно плохо, но это значит, что результаты могут зависеть от вещей, которые вы не видите.

API-отправка даёт больше регуляторов инфраструктуры. Некоторые провайдеры также изолируют клиентов, чтобы репутация одной организации не переливалась на другую. В любом случае прогрев важен. Новый домен, ящик или IP выглядит рискованным, пока не покажет устойчивое поведение.

Простейшая модель обратной связи:

• Положительные сигналы: открытия, ответы, сохранения, пересылки
• Негативные сигналы: жалобы на спам, быстрые удаления, отказы, отписки
• Быстрое повреждение: высокий процент отказов и жалоб
• Медленное повреждение: слишком много объёма слишком быстро, низкая вовлечённость со временем

Обработка ответов важнее, чем команды ожидают. Если заинтересованные ответы пропускают, а follow-up’ы продолжают идти, вы вызовете больше жалоб. Системы, которые категоризируют ответы (заинтересован, не заинтересован, автоматический ответ, отказ, отписка), помогают быстро остановить последовательности и защитить репутацию.

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

Ограничения при масштабировании: что вас замедляет в каждом варианте

Масштабирование холодных рассылок редко блокируется билдером последовательностей. Его блокирует репутация и операционная часть. Как только вы переходите от «одного человека, который отправляет» к «команда, которая отправляет каждый день», решение перестаёт быть про фичи и переходит в плоскость того, как быстро вы сможете добавить ёмкость, не запустив спам-фильтры.

При отправке через почтовые ящики (Google Workspace или Microsoft 365) масштабирование обычно означает добавление новых ящиков и часто новых доменов. Это кажется простым, пока вам не нужно поддерживать всё одинаковым: аутентификацию, темп прогрева, подписи, настройки трекинга и обновления текста по всем ящикам.

Где команды обычно тормозят:

• Google Workspace: аккуратный прогрев и накладные расходы на управление множеством ящиков. Если один ящик получают флаг, вы теряете время на паузу, замену и повторный прогрев.
• Microsoft 365: похожие ограничения, плюс админ-политики могут стать поглотителем времени при добавлении пользователей и поддержании единообразного поведения.
• API-отправка: вы можете чисто увеличить ёмкость, но получаете больше движущихся частей (домены, аутентификация, маршрутизация, списки подавления). Ошибки распространяются быстро на больших объёмах.

Каким бы путём вы ни шли, вы столкнётесь с практическими пределами: суточными лимитами, троттлингом и «мягкими» ограничениями, которые не всегда ясно документированы. Они проявляются не сразу, а при увеличении объёма, добавлении ящиков или изменении таргетинга.

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

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

Частые ошибки доставляемости (и как их избегать)

Большинство проблем с доставляемостью — самосделанные. Вариант отправки важен, но одинаковые ошибки появляются везде.

Самый быстрый способ убить новый отправитель — казаться «больше», чем ваша репутация. Если вы с 0 переходите на высокий суточный объём, провайдеры быстро решат, что вы рискованны, даже если ваше предложение честно.

Ловушки, которые наносят наибольший урон (и как исправить):

• Пропуск прогрева и наращивания: начинайте с малого, увеличивайте постепенно и держите отправку последовательной.
• Массовая рассылка одного и того же сообщения всем: узкий таргет лучше объёма. Первая строка должна доказать, что вы не «соскребли» список.
• Спамоподобное форматирование: избегайте тяжёлого HTML, больших изображений, CAPS LOCK, странных шрифтов и избыточной пунктуации. Стиль в виде простого текста обычно проходит лучше.
• Разрывы в аутентификации (SPF/DKIM/DMARC): убедитесь, что все три есть, правильно настроены и согласованы с доменом, который видит получатель.
• Использование основного бизнес-домена для холодного аутрича: используйте отдельный домен, чтобы плохая неделя не навредила повседневной почте.

Трекинг и ссылки тоже могут навредить. Множество ссылок, сервисы сокращения URL или агрессивный кликовый трекинг выглядят подозрительно. Если трекинг нужен, делайте его умеренным и избегайте маскировки ссылок.

Как заметить спад доставляемости на ранней стадии

Следите за этими сигналами:

• Рост процентa отказов (особенно «blocked» или «rejected»)
• Падение процента ответов при том же качестве списка
• Больше жалоб или сердитых ответов
• Резкое снижение открытий у нескольких провайдеров

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

Пошагово: как выбрать подходящий вариант отправки

Начните с цели, а не с инструмента. Настройка, которая работает для небольшого теста, может превратиться в ежедневную головную боль, как только вы добавите больше представителей, доменов и последовательностей.

Запишите ожидаемый объём на ближайшие 4–8 недель: новых контактов в неделю, количество отправителей и количество кампаний. Эта оценка обычно определяет, сможете ли вы остаться на простой почтовой модели или нужен более строгий контроль.

Практический процесс принятия решения:

1. Определите ближайшую веху: тест (один отправитель) или масштабный исходящий процесс (несколько отправителей и рост каждую неделю).
2. Выберите модель репутации: нужна ли изоляция между командами/клиентами или допустима общая репутация?
3. Оцените операционную нагрузку: быстрый запуск может создать больше ручной работы позже.
4. План безопасного развёртывания: начните с одного домена и 1–2 ящиков, проверьте попадание во входящие, затем расширяйтесь медленно.
5. Установите минимальные стандарты перед отправкой: аутентификация, прогрев, чистые списки и работающий процесс отписок.

Пример: если вы хотите протестировать предложение с 200 новыми лидами в неделю, стандартный почтовый подход подойдёт, если держать объёмы скромными и следить за ответами и отказами. Если же цель — вырасти до 2000 новых лидов в неделю среди нескольких SDR, приоритет — изоляция и повторяемая настройка, потому что ошибки быстро накапливаются.

Что бы вы ни выбрали, не пропускайте базу: SPF/DKIM/DMARC для каждого домена отправки, постепенный прогрев для каждого ящика и строгая очистка списков.

Быстрый чек-лист перед масштабированием холодной почты

Прежде чем добавить ящики или повысить суточный объём, остановитесь и убедитесь, что базовые вещи действительно работают. Многие проблемы с доставляемостью на масштабе происходят из-за одной упущенной «маленькой» настройки, которая проявляется только после сотен писем.

Простой предварительный чек-лист:

• Идентичность согласована: From-адрес, домен отправки и домен трекинга согласованы. SPF/DKIM/DMARC настроены и проходят проверки для того же домена, который видит получатель.
• Прогрев и наращивание запланированы: прогрев активен для каждого нового ящика и у вас есть письменный план роста.
• Проверены пути отказов: вызовите отскок, отписку и автоматический ответ и убедитесь, что система корректно фиксирует и останавливает отправку, где нужно.
• Проверка попадания во входящие: отправьте короткое простое сообщение на несколько реальных почтовых ящиков (Gmail и Outlook/Hotmail достаточно) и проверьте вручную, где оно оказалось.
• У ответов есть владелец: решите, кто просматривает ответы ежедневно, целевые сроки ответа и что делается после «заинтересован» vs «не заинтересован».

Практический пример: если вы собираетесь удвоить объём в понедельник, сделайте seed-тест в пятницу утром. Если в Gmail вы попадаете в спам, а в Outlook нет — исправляйте аутентификацию и контент сначала, а не увеличивайте объём.

Пример сценария и следующие шаги для чистого развёртывания

Двухчленная команда хочет начать исходящую работу, не тратя неделю на настройку. Они планируют отправлять 20–40 писем в день в начале, затем вырасти до нескольких сотен в день по мере добавления лидов и тестирования офферов.

Они начинают с почтовых ящиков (Google Workspace или Microsoft 365), потому что это самый быстрый способ получить реальные почтовые ящики, доступы и простую ежедневную рутину. На неделях 1 и 2 они держат объёмы низкими и фокусируются на таргетинге и ответах. На неделях 3–6 они добавляют второй домен и ещё несколько ящиков, чтобы один отправитель не тянул всю нагрузку.

Как только они увидят повторяемые результаты и потребуется больший объём, они пересматривают метод отправки. Если нужно больше контроля репутации и изоляции, они рассматривают перенос части начальных объёмов на API-отправку, оставляя почтовые ящики для ответов и отношений.

Что они проверяют каждую неделю, чтобы ловить проблемы на ранней стадии:

• Тренды отказов
• Спайки жалоб на спам (даже небольшие)
• Соотношение типов ответов (заинтересован vs не заинтересован vs автоответы, плюс злые ответы)
• Проверки попадания во входящие
• Объём по каждому ящику и домену (чтобы избежать случайных скачков)

Чистое развёртывание простое, но требует дисциплины: выберите один путь на следующие 30 дней, задокументируйте настройку (домены, статус SPF/DKIM/DMARC, список ящиков, суточные лимиты), наращивайте контрольными шагами и останавливайтесь, чтобы исправить причину при ухудшении метрики.

Если постоянный подбор инструментов замедляет вас, единая платформа вроде LeadTrain (leadtrain.app) может консолидировать домены, почтовые ящики, прогрев, многошаговые последовательности и классификацию ответов, чтобы вы реже пропускали мелкую настройку, которая потом превращается в проблему доставляемости.