Держим жалобы Gmail ниже 0.3%: инженерный разбор снижения complaint rate у массовых отправителей
Порог 0.3% в Postmaster Tools — запаздывающий индикатор: когда он краснеет, репутация домена уже просела. Разбираем, как держать реальный complaint rate на уровне 0.02–0.05% через аутентификацию, корреляцию по Feedback-ID и жёсткую сегментацию по вовлечённости — с позиции инженера, который вытаскивал домены из красной зоны Gmail.
EvilMail Team14 июля 2026 г.12 мин чтения
Вторник, 09:40. Postmaster Tools показывает spam rate 0.34% за предыдущий день, репутация домена уехала из Medium в Low, инбоксинг по Gmail просел на ~20% за сутки. Отправитель — 40 000 писем в день, в контенте ничего не менялось, шаблон тот же, что и месяц назад. И всё равно почта поехала в спам-папку.
Это типовой сценарий, и он вводит в заблуждение своей внезапностью. На самом деле ничего внезапного здесь нет: цифра 0.34% — это уже последствие, а не событие. Реальные жалобы копились несколько дней, репутация домена ползла вниз с инерцией, и Postmaster просто досчитал сэмпл и показал результат с опозданием на пару суток.
Отсюда главный тезис: 0.3% — это не цель, а потолок, при котором Gmail уже наказывает. Инженерная норма для здорового bulk-отправителя — 0.02–0.05%. Внутренний триггер тревоги ставим на 0.05%, а не на 0.3%. И жалобы не «случаются» — вы их создаёте сами, отправляя письма людям, которые перестали их ждать. Чинится это на уровне сегментации списка, а не текста в футере.
Что на самом деле измеряет Gmail и почему 0.3% — это уже поздно
Формула, которую считает Postmaster Tools, простая:
text
Снижение complaint rate Gmail ниже 0.3%: практика для bulk-отправителей — EvilMail Blog
spam rate = (письма, помеченные "Report spam" Gmail-пользователями)
/ (доставленные в Gmail, кроме заблокированных на SMTP-уровне)
Заблокированные на этапе SMTP письма в знаменатель не попадают: чем агрессивнее Gmail рубит вас ещё на подключении, тем меньше знаменатель и тем выше выходит процент при том же числе жалоб. Считается всё это только по Gmail-получателям, данные сэмплируются и запаздывают на 1–3 дня. График появляется лишь при достаточном объёме — нужны сотни писем в день на домен, иначе он просто пустой.
Ключевой нюанс, на котором спотыкаются даже опытные люди: рейтинг репутации домена (Bad / Low / Medium / High) — это отдельная кривая от spam rate. Она реагирует на всплеск жалоб с инерцией и, что важнее, восстанавливается медленнее, чем падает. Один плохой день роняет вас из Medium в Low за сутки, а обратный путь занимает недели чистых отправок. Поэтому ориентироваться на сам порог 0.3% нельзя по определению: к моменту, когда он покраснел, ущерб репутации уже нанесён, и разгребать его вы будете дольше, чем создавали.
Фундамент: аутентификация, без которой остальное не считается
С февраля 2024 для отправителей 5000+ писем в день на Gmail аутентификация — не рекомендация, а входной билет. Без неё разговор о complaint rate не имеет смысла: неаутентифицированное письмо Gmail изначально кладёт ближе к спаму, а из спам-папки на вас жмут «Report spam» чаще — и вы получаете завышенный процент жалоб на пустом месте.
Минимальный набор:
SPF — жёсткий, с -all, покрывающий реальный исходящий IP.
DKIM с выровненной подписью — домен в d= должен совпадать с From-доменом.
DMARC — минимум p=none с rua, но для боевого bulk-потока лучше p=quarantine со строгим выравниванием.
ARC — если письма проходят через форвардинг.
PTR/rDNS — прямая и обратная записи должны совпадать.
TLS на исходящем и обязательный RFC 8058 one-click unsubscribe.
Боевые записи для домена выглядят так:
dns
evilmail.pro. IN TXT "v=spf1 ip4:203.0.113.10 -all"
_dmarc.evilmail.pro. IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=s; aspf=s"
sel1._domainkey.evilmail.pro. IN TXT "v=DKIM1; k=rsa; p=MIGf..."
Проверяем перед каждым большим запуском — это тридцать секунд, которые экономят недели восстановления репутации:
Отдельно про самую частую тихую поломку: один битый или неподписанный DKIM-селектор на части базы превращает эти письма в «неаутентифицированные». Gmail охотнее кладёт их в спам, оттуда прилетают жалобы, и complaint rate накручивается искусственно — при том что контент и список у вас нормальные. Всегда сверяйте заголовок Authentication-Results в тестовом письме: dkim=pass, и header.d= обязан быть равен From-домену.
Feedback-ID: узнать, КТО жалуется, а не просто СКОЛЬКО
Google FBL работает не как у Yahoo. Индивидуальных ARF-отчётов на каждую жалобу вы не получите. Вместо этого Google агрегирует жалобы по заголовку Feedback-ID и показывает долю жалоб на каждый identifier прямо в Postmaster Tools, в разделе FBL. Условие: минимум ~200 писем на один identifier за окно, иначе статистика по нему не отдаётся (защита от деанонимизации отдельных пользователей).
Формат заголовка — до трёх ваших полей плюс идентификатор отправителя последним:
Схема разметки, которую стоит держать: тип : кампания : сегмент : SenderID. Смысл — превратить обезличенный «0.3% по домену» в адресный сигнал. Когда разметка на месте, в Postmaster вы видите буквально следующее: рассылка по сегменту 90+ дней даёт 0.42%, а та же кампания по 30-дневному сегменту — 0.03%. Это и есть локализация источника жалоб до конкретного среза базы, без гаданий по контенту.
Сегментация по вовлечённости — главный рычаг
Здесь режется 80% проблемы. Модель engagement-based sending строится на окнах с момента последнего открытия или клика:
0–30 дней — активные, шлём как обычно.
30–90 дней — остывающие, снижаем частоту, добавляем полезность.
90+ дней — молчащие. Их не трогаем обычными рассылками вообще. Только реактивационная серия с явным CTA «нажми отписаться», после чего — в suppression.
Sunset policy — это автоматика: подписчик молчит N дней (типично 60–90 для промо) → уходит в suppression без ручного разбора. И double opt-in на входе как фильтр от случайных и чужих адресов, которые чаще всего и генерируют жалобы.
Почему спящий подписчик — главный источник жалоб? Он банально не помнит, что подписывался. Через полгода тишины ваше письмо для него — незнакомый отправитель, и рефлекторное действие в Gmail — «Report spam», а не поиск ссылки отписки. Вы сами кладёте письмо человеку, который перестал его ждать, и получаете жалобу, которую сами же и запрограммировали.
Механика письма: где физически прячутся жалобы
Список чист, аутентификация в порядке — а жалобы всё равно есть? Смотрим на само письмо:
Видимая ссылка отписки в шапке, а не только мелким шрифтом в футере. Отписаться должно быть легче, чем нажать «Report spam».
Консистентный From. Домен и отображаемое имя не меняем от кампании к кампании. Смена = «кто это?» = жалоба.
Preference center вместо бинарного «отписаться от всего» — дайте снизить частоту вместо ухода в спам.
Разделение потоков. Транзакционка и маркетинг на разных поддоменах (mail.evilmail.pro для подтверждений, news.evilmail.pro для промо), в идеале на разных IP. Тогда жалобы на промо не топят репутацию письма со сбросом пароля.
Технически one-click unsubscribe по RFC 8058 — это два заголовка, и оба обязательны:
Заморозить все рассылки по неактивным сегментам. Оставить только 0–30 дней и транзакционку.
Снизить объём — резко, не «на 10%».
Изолировать проблемный поток на отдельный поддомен/IP, чтобы не тянуть за собой здоровые потоки.
Прогрев по нарастающей — возвращать объём кривой вверх, не рывком.
И главное — нельзя просто «переждать», не сокращая базу. Gmail помнит паттерн отправителя. Если поставить рассылки на паузу на неделю, а потом вернуться к тем же молчащим сегментам, красная зона вернётся с первого же запуска. Бакет репутации восстанавливается неделями чистых, вовлечённых отправок — а не днями тишины.
Мониторинг: алерты до того, как Postmaster покраснеет
Поскольку spam rate запаздывает, ловим прокси-метрики, которые двигаются раньше:
Рост hard bounce — база протухает, значит и жалобы на подходе.
Падение open rate по сегменту — вовлечённость упала, риск жалоб вырос.
Рост неаутентифицированного трафика в DMARC aggregate (`rua`) — где-то сломался DKIM.
Per-campaign complaint через Feedback-ID — адресный сигнал по конкретному срезу.
Seed-тесты по набору Gmail-адресов — куда физически падает письмо, инбокс или спам.
Внутренний порог — 0.05% с автоматической остановкой сегмента. Не 0.3%. К 0.3% вы уже опоздали.
Чеклист перед массовой рассылкой
SPF -all, DKIM выровнен (d= = From), DMARC минимум p=quarantine — проверено через dig.
PTR и forward-запись совпадают.
Authentication-Results в тестовом письме: dkim=pass, spf=pass, dmarc=pass.
Заголовок Feedback-ID проставлен по схеме тип:кампания:сегмент:sender.
List-Unsubscribe + List-Unsubscribe-Post (RFC 8058) присутствуют и реально работают.
Список отфильтрован по вовлечённости; 90+ дней исключены или только реактивация.
Sunset policy активна, suppression применён перед сборкой рассылки.
Транзакционный и маркетинговый потоки на разных поддоменах.
Отписка видна в шапке, From консистентен с прошлыми кампаниями.
Частота не выросла скачком относительно прошлой недели.
Внутренний алерт на 0.05% настроен, автостоп сегмента включён.
Seed-тест по Gmail-адресам пройден, письмо в инбоксе.
Соберите этот чеклист в скрипт предполётной проверки — и «внезапные» вторники с 0.34% в Postmaster у вас просто закончатся. Жалобы не приходят из ниоткуда; вы их либо программируете сегментом 90+ дней, либо не программируете.
