Требования Gmail и Yahoo к массовым отправителям: аутентификация, one-click отписка и порог жалоб на практике
5000 писем в сутки на один принимающий домен — и вы массовый отправитель. Формальное наличие DMARC-записи не спасает: Gmail и Yahoo требуют реального выравнивания DKIM/SPF, рабочего обработчика one-click отписки и жёстко следят за порогом жалоб. Разбираем, что именно отбивается кодами 421 4.7.28 и 550 5.7.1, и как настроить инфраструктуру, чтобы не попасть в серую зону.
EvilMail Team15 июля 2026 г.12 мин чтения
5000 писем в сутки на Gmail-адреса — и вы массовый отправитель. Не по объёму базы, а по домену в заголовке From, суммарно за скользящие сутки. С этого порога Gmail начинает считать вашу репутацию всерьёз, а Yahoo — молча резать доставку, ничего не показывая в дашборде, которого у него нет.
Требования Google и Yahoo, вступившие в силу в феврале 2024 года, к 2026-му давно перестали быть новостью. Проблема в том, как их «сдали»: большинство отправителей добавили TXT-запись _dmarc с p=none, поставили галочку в чек-листе ESP и забыли. Но принимающая сторона проверяет не факт наличия записей. Она проверяет три вещи, которые ломаются именно в проде: выравнивание (alignment) DKIM/SPF по домену в From, реально работающий обработчик one-click отписки и долю жалоб. Формальное соответствие и доставка — это разные состояния, и разрыв между ними оплачивается кодами 421 4.7.28 и 550 5.7.1.
Кого считают массовым отправителем и что именно проверяют
Требования Gmail и Yahoo к массовым отправителям 2026: DMARC, one-click отписка, порог жалоб — EvilMail Blog
Порог — 5000+ сообщений в сутки, доставленных на Gmail-адреса. Считается по организационному домену в
RFC5322.From
, а не по отправляющему IP и не по домену в конверте (
MAIL FROM
). Это важно: раскидать рассылку по десяти IP-адресам не помогает, потому что счётчик привязан к бренду в шапке письма. И статус не сбрасывается — один раз перешагнув порог, вы остаётесь bulk sender в глазах Gmail, даже если следующий день был тихим.
Требования делятся на три корзины:
Аутентификация. SPF *и* DKIM настроены, DMARC-запись опубликована, и хотя бы один из механизмов выровнен с доменом From.
One-click отписка по RFC 8058 для промо- и маркетинговых писем — оба заголовка, с рабочим POST-обработчиком.
Порог жалоб — user-reported spam rate ниже 0,3% по данным Postmaster Tools, а на практике сильно ниже.
Плюс базовая гигиена: валидная PTR-запись с forward-confirmed reverse DNS, TLS на транспорте (STARTTLS), корректный по RFC 5322 заголовок и никакой подделки @gmail.com в поле From.
Yahoo, AOL и их семейство доменов применяют почти те же правила. Разница одна и она болезненная: у Yahoo нет публичного аналога Postmaster Tools. О проблемах вы узнаёте не из графика, а из потока 421-tempfail и bounce-сообщений. Поэтому Gmail используют как измерительный прибор, а к Yahoo относятся как к минному полю, которое проходят по тем же правилам, но вслепую.
Аутентификация: не «наличие записей», а выравнивание
Здесь ломается большинство «формально соответствующих» отправителей. SPF pass и DMARC pass — это не одно и то же.
SPF аутентифицирует домен в конверте (Return-Path / MAIL FROM). DKIM аутентифицирует домен из тега d= в подписи. DMARC поверх этого требует выравнивания: домен, прошедший SPF или DKIM, должен совпадать с доменом в видимом From. В режиме relaxed (по умолчанию) достаточно совпадения организационного домена; в strict (aspf=s, adkim=s) — точного. DMARC проходит, если выровнен хотя бы один из двух механизмов.
Классический сценарий поломки: письмо уходит через ESP.
Return-Path указывает на bounce.esp.com, а From — на news.yourbrand.com. SPF отработает по домену ESP, но выравнивания с From не будет. Единственное, что спасает DMARC, — выровненный DKIM с подписью d=yourbrand.com, которую ESP ставит от вашего имени по делегированному ключу. Правило, которое стоит запомнить: SPF в одиночку недостаточен, DKIM обязателен всегда.
Минимальный набор записей выглядит так:
dns
; SPF — авторизует источники в конверте
yourbrand.com. IN TXT "v=spf1 include:_spf.esp.com -all"
; DKIM — селектор, выданный ESP; ключ 2048 бит
s1._domainkey.yourbrand.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."
; DMARC — стартуем с p=none ради отчётов
_dmarc.yourbrand.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; fo=1"
p=none на старте — это не «заглушка», а осознанный этап. Он ничего не блокирует, но включает поток агрегированных отчётов на адрес из rua=. Пару недель вы читаете эти XML (или скармливаете их парсеру), находите все легитимные источники, которые не выравниваются — забытый биллинг-шлюз, CRM, транзакционный сервис — чините их, и только потом двигаетесь к p=quarantine, а затем p=reject. Перепрыгнуть сразу к reject — верный способ уронить собственные транзакционные письма.
Отдельно про пересылку. Когда письмо форвардится или проходит через список рассылки, SPF ломается (меняется конверт), а тело иногда модифицируется — рушится и DKIM. Для таких случаев существует ARC (Authenticated Received Chain): промежуточный сервер запечатывает исходные результаты аутентификации в цепочку, и Gmail валидную ARC-цепочку учитывает. Сами вы ARC не публикуете, но знать о нём нужно, когда разбираете, почему письмо через чью-то пересылку внезапно попало в спам.
Проверка занимает три команды:
bash
dig +short TXT _dmarc.yourbrand.com
dig +short TXT s1._domainkey.yourbrand.com
dig -x 203.0.113.10 # PTR + сверить прямой резолв обратно
А дальше — самое честное: отправьте письмо себе на Gmail, откройте «Показать оригинал» и прочитайте Authentication-Results. Там будет прямым текстом spf=pass, dkim=pass, dmarc=pass (p=NONE). Если видите spf=pass, но dmarc=fail — у вас ровно тот случай несовпадения доменов, о котором шла речь выше.
One-click отписка, которая реально работает (RFC 8058)
Требуются два заголовка, и работают они только в паре:
Без второго заголовка Gmail не покажет системную кнопку «Отписаться» рядом с именем отправителя. Механика такая: когда пользователь жмёт эту кнопку, Gmail или Yahoo сами отправляют HTTP POST на URL из List-Unsubscribe с телом List-Unsubscribe=One-Click. Без открытия страницы, без участия человека дальше клика. Ваш обработчик обязан принять этот POST, вернуть 2xx и снять подписку в течение двух дней (на практике — сразу).
Где это ломается чаще всего:
URL за авторизацией или CSRF-защитой. Провайдер приходит анонимным POST без cookie и без CSRF-токена. Если ваш фреймворк по умолчанию отбивает такие запросы 403 — отписка не работает, а Gmail видит неудачу. Эндпоинт отписки нужно вынести из-под общей CSRF-защиты.
Обработка только по GET. Классическая ссылка «отписаться» в теле ждёт клик и открывает страницу. One-click требует именно POST-обработчик.
Редирект на страницу подтверждения. POST-отписка не должна требовать второго клика «да, точно». Приняли POST — сняли подписку.
Заголовок на транзакционных письмах. One-click нужен для промо и маркетинга. На чеках, кодах подтверждения и уведомлениях безопасности он не нужен и вреден — вы рискуете отписать человека от писем, которые он обязан получать.
Ссылка отписки в *теле* письма при этом всё равно обязательна — заголовки её не заменяют.
Минимальный идемпотентный обработчик с подписанным токеном, чтобы эндпоинт не превратился в открытую дверь для отписки чужих адресов:
js
// POST /u — вызывается провайдером, без cookie и CSRF
app.post('/u', express.urlencoded({ extended: false }), (req, res) => {
const token = req.query.t;
const payload = verifyHmac(token, process.env.UNSUB_SECRET); // null при плохой подписи
if (!payload) return res.sendStatus(400);
// идемпотентно: повторный POST по тому же токену — тоже 200
unsubscribe(payload.list, payload.email); // upsert, не бросает на повторе
return res.sendStatus(200);
});
Проверить руками — одна строка:
bash
curl -i -X POST -d 'List-Unsubscribe=One-Click' \
'https://u.yourbrand.com/u?t=SIGNED_TOKEN'
# ожидаем HTTP/1.1 200 OK
Если тут не 200 — Gmail это увидит раньше вас, и кнопка «Отписаться» начнёт конкурировать с кнопкой «Спам». А жалоба на спам стоит в разы дороже отписки.
Порог жалоб: почему 0,3% — это уже поздно
Gmail считает user-reported spam rate как долю писем, помеченных пользователями как спам, от числа доставленных во Входящие. Ключевое слово — во Входящие: письма, которые и так ушли в папку «Спам», в знаменатель не попадают. Данные видны в Postmaster Tools, вкладка *User-reported spam rate*.
Официальный порог — 0,3%. Относиться к нему нужно как к красной черте, а не как к цели. Целевой средний показатель — ниже 0,10%. Разовый всплеск выше 0,3% в один день уже даёт throttling; хроническое превышение — reject.
Знаменатель коварен именно поэтому. Как только репутация проседает и часть писем начинает уходить в «Спам», эти письма выпадают из знаменателя — доля жалоб от оставшихся «входящих» растёт быстрее, чем растёт абсолютное число жалоб. Ухудшение ускоряет само себя. Вот почему 0,3% на графике — это не предупреждение, а свидетельство уже случившегося throttling.
Про обратную связь. У Gmail нет классического per-message FBL — только агрегат в Postmaster Tools, и чтобы его увидеть, домен нужно верифицировать TXT-записью. А вот у Yahoo (Complaint Feedback Loop) и Microsoft (SNDS + JMRP) полноценные FBL есть, и их надо зарегистрировать — иначе вы теряете единственный сигнал о жалобах в этих сетях.
Что реально снижает жалобы: sunset policy (перестать слать тем, кто не открывал письма N месяцев), изоляция маркетинга на отдельном поддомене (news.yourbrand.com), чтобы жалобы не тянули вниз репутацию транзакционного домена, прогрев домена и IP на старте, и заметная, рабочая отписка — чтобы человек уходил через unsubscribe, а не через «Спам».
Диагностика: коды отказов и чтение заголовков
Коды в SMTP-ответах — самый прямой источник правды. Что они означают:
`421-4.7.28 ... unusual rate of unsolicited mail ... temporary rate limited` — репутация и/или скорость. Временный отказ, письмо в очереди на ретрай. Лечится не ретраями, а снижением жалоб и объёма.
`550-5.7.1 ... not RFC 5322 compliant / unauthenticated` — либо аутентификация не прошла, либо DMARC-политика отбила, либо кривой заголовок.
`550 5.7.26` — прямо про аутентификацию: письмо не прошло проверку и политика домена требует отклонения.
Yahoo `421 4.7.0 [TSS04] ... deferred due to user complaints` — deferred из-за жалоб пользователей. У Yahoo это часто первый и единственный сигнал, что вы за чертой.
Разбор всегда начинается с полного заголовка полученного письма. Authentication-Results с spf=pass smtp.mailfrom=bounce.esp.com, но dmarc=fail (p=none dis=none) header.from=yourbrand.com — это буквально несовпадение доменов из первой диаграммы: SPF технически прошёл, но не выровнялся, а выровненного DKIM нет.
Контур мониторинга: Postmaster Tools (spam rate, domain & IP reputation, authentication) как ежедневный прибор для Gmail, mail-tester для быстрой проверки одиночного письма и собственный парсер DMARC-отчётов из rua=.
Чеклист перед первой массовой рассылкой
SPF, DKIM, DMARC опубликованы и проверены через dig.
DKIM d= совпадает с организационным доменом в From (выравнивание, а не просто pass).
DMARC поднят с p=none + rua=, отчёты реально читаются; переход к quarantine/reject — после анализа.
PTR-запись есть, forward-confirmed reverse DNS сходится.
TLS (STARTTLS) включён на транспорте.
List-Unsubscribe + List-Unsubscribe-Post присутствуют на промо-письмах; POST-обработчик отдаёт 200 в тесте curl.
Обработчик отписки идемпотентен, токен подписан HMAC, эндпоинт выведен из-под CSRF.
Маркетинг вынесен на отдельный поддомен от транзакционных писем.
Google Postmaster Tools подключён, домен верифицирован TXT-записью.
Yahoo CFL и Microsoft SNDS/JMRP зарегистрированы.
Sunset policy включена, база почищена от неактивных.
Записи в DNS ставятся один раз и правильно — это гигиена, а не ежедневная работа. Выживание массового отправителя определяется другим: порогом жалоб, который проверяется каждый день, и отпиской, которая работает без вашего участия. Первые недели после запуска смотрите на User-reported spam rate ежедневно — к тому моменту, когда он сам попросит внимания цифрой 0,3%, чинить будет уже поздно.
