Письмо может быть идеально свёрстанным и полезным, но если почтовый сервер получателя не понимает, кто его отправил, — оно уходит в спам или отклоняется прямо на входе. За этим «пониманием» стоят три DNS-записи: SPF, DKIM и DMARC. С 2024 года Gmail и Yahoo перестали считать их желательной опцией: обычному отправителю нужен хотя бы один механизм — SPF или DKIM, а массовым обязателен весь набор — SPF, DKIM и DMARC. Порог массовой рассылки числом задаёт только Gmail — 5000 и более писем в сутки на Gmail-адреса; Yahoo относит к массовым отправителей «значительного объёма», но конкретного числа намеренно не публикует. Mail.ru предъявляет требования в том же духе.
Ниже — пошаговая техничка: что делает каждая запись, как добавить их в DNS руками и как это за пару кликов настраивают сервисы рассылок вроде Unisender, SendPulse и UniOne. Без магии — только стандарты RFC и официальные требования почтовиков. Если вы ещё не отправили первую кампанию, начните с гайда как сделать email-рассылку, а сюда вернитесь на этапе настройки домена.
Коротко
- SPF (RFC 7208) — список серверов и IP, которым разрешено отправлять письма от вашего домена. Лимит — не более 10 DNS-запросов на проверку, иначе ошибка PermError.
- DKIM (RFC 6376) — криптографическая подпись письма приватным ключом; получатель проверяет её публичным ключом из DNS. RFC 8301 требует минимум 1024 бита и рекомендует 2048; 2048 — текущий практический стандарт.
- DMARC (RFC 7489) — политика обработки непрошедших писем (none / quarantine / reject) плюс отчёты. Срабатывает, только если провалились ОБА — и SPF-, и DKIM-выравнивание.
- С 1 февраля 2024 Gmail и Yahoo требуют минимум SPF или DKIM у всех отправителей, а у массовых — полный набор SPF + DKIM + DMARC. Числовой порог массовой рассылки прописал только Gmail — 5000 и более писем в сутки; Yahoo относит к массовым «значительный объём», не публикуя конкретного числа.
- Mail.ru требует, чтобы SPF, DKIM и DMARC проходили каждый, плюс осмысленный PTR и заголовок Precedence: bulk; пороги жалоб — от 0,3% до 1,1% по объёму.
- Сервисы рассылок генерируют готовые TXT-записи — руками остаётся только вставить их в DNS домена.
- Аутентификация — это не гарантия инбокса, а лишь допуск к проверке репутации. Чистая база и низкий спам-рейт решают не меньше.
Три записи — три разные задачи
SPF, DKIM и DMARC часто валят в одну кучу, но каждая отвечает за свой вопрос. SPF отвечает на вопрос «с каких серверов вообще можно слать почту от этого домена». DKIM — «не подделали ли письмо по дороге и действительно ли его подписал заявленный домен». DMARC — «что делать получателю, если проверки не сошлись, и куда прислать отчёт об этом». Работают они только вместе: по отдельности каждая закрывает лишь часть картины, а почтовики 2024–2026 годов смотрят на все три.
SPF — кто имеет право отправлять от вашего домена
SPF (Sender Policy Framework) описан в RFC 7208, опубликован в апреле 2014 года и заменил более ранний RFC 4408. Запись задаёт, каким серверам и IP-адресам разрешено отправлять почту от имени домена; при доставке проверяется идентичность в командах MAIL FROM и HELO. Технически это одна TXT-запись в корне домена, например:
v=spf1 include:_spf.google.com ~all
За результат отвечают квалификаторы механизмов: + — pass (разрешено), - — fail (запрещено жёстко), ~ — softfail (мягкий отказ), ? — neutral. По умолчанию действует +. Хвост ~all означает «всё, что не перечислено выше, — мягкий отказ».
Главная скрытая ловушка SPF — лимит на 10 DNS-запросов на одну проверку. В этот лимит входят механизмы include, a, mx, ptr, exists и модификатор redirect; прямые ip4: и ip6: НЕ считаются. Если превысить лимит, проверка вернёт результат PermError, и письмо рискует уйти в спам или быть отклонённым. Есть и второй порог — не более двух «void»-запросов (тех, что не дают ответа). Один-единственный include:_spf.google.com из-за вложенности съедает около четырёх запросов из десяти — это частая причина, по которой рабочий на вид SPF внезапно ломается после добавления ещё пары сервисов.
Второе правило: на домене должна быть ровно одна SPF-запись. Две TXT-записи SPF ломают проверку. Если вы подключаете несколько отправителей (свой сервер, сервис рассылок, CRM), их объединяют через include внутри одной записи, а не заводят вторую.
DKIM — криптографическая подпись письма
DKIM (DomainKeys Identified Mail) описан в RFC 6376, опубликован в сентябре 2011 года. Идея простая: отправляющий сервер подписывает письмо приватным ключом, а получатель проверяет подпись публичным ключом, который лежит в DNS отправителя. Если подпись сошлась — значит, письмо действительно от этого домена и его не изменили по дороге.
Подпись живёт в заголовке письма DKIM-Signature — это набор тегов вида tag=value. Основные:
a=— алгоритм подписи;c=— канонизация (как нормализуют текст перед подписью);d=— подписывающий домен (SDID);s=— селектор, по которому публичный ключ ищется в DNS.
Публичный ключ хранится в TXT-записи по адресу селектор._domainkey.вашдомен. По длине ключа: RFC 8301 требует минимум 1024 бита и рекомендует 2048, и 2048 бит — текущий практический стандарт. Yahoo прямо требует DKIM-ключ не короче 1024 бит — короткий ключ проверку не пройдёт.
DMARC — политика и отчёты поверх SPF и DKIM
DMARC (Domain-based Message Authentication, Reporting and Conformance) описан в RFC 7489 (Informational), опубликован в марте 2015 года. Эта запись связывает результаты SPF и DKIM с проверкой выравнивания (alignment) домена в поле From: и говорит получателю, что делать с письмами, которые проверку не прошли. Плюс DMARC настраивает отправку агрегированных отчётов владельцу домена — по ним видно, кто и от вашего имени рассылает почту.
У политики три значения тега p=:
none— ничего не делать, только мониторинг и отчёты;quarantine— считать письмо подозрительным (обычно попадает в папку «Спам»);reject— отклонять прямо на этапе SMTP-транзакции.
Ключевой момент, который многих путает: политика DMARC применяется, только если провалились ОБА выравнивания — и SPF-alignment, и DKIM-alignment. Если хоть одна из проверок прошла и домен выровнен с From:, письмо считается прошедшим DMARC. Поэтому безопасный порядок внедрения — от мягкого к жёсткому: сначала p=none (собираете отчёты, смотрите, что и откуда шлётся), затем quarantine, и только убедившись, что легитимная почта не страдает, — reject.
Что требуют Gmail, Yahoo и Mail.ru в 2024+
Раньше аутентификация была «хорошим тоном». С 2024 года это входной билет. Google, Microsoft и Яндекс фактически требуют все три механизма для массовых рассылок, а Gmail и Yahoo прописали требования явно.
| Почтовик | Что обязательно | Порог жалоб (spam rate) |
|---|---|---|
| Gmail (с 01.02.2024) | Всем — SPF или DKIM. Массовым (5000 и более писем/сутки на Gmail-адреса) — SPF и DKIM и DMARC (минимум p=none), выравнивание домена From: с SPF или DKIM, валидные прямые и обратные DNS (PTR), передача по TLS, one-click отписка (RFC 8058) | ниже 0,30% (Google советует держать ниже 0,10% и никогда не достигать 0,30%) |
| Yahoo (с 02.2024) | Всем — SPF или DKIM (как минимум один механизм). Массовым (значительный объём; конкретного числа Yahoo намеренно не публикует) — и SPF, и DKIM (ключ не менее 1024 бит), плюс DMARC (минимум p=none), выравнивание From:, рабочий List-Unsubscribe с one-click отпиской | ниже 0,3% |
| Mail.ru | SPF, DKIM и DMARC — каждый должен успешно проходить; осмысленный PTR/rDNS (правильно вида mail.domain.com, неправильно вида 231.2.53.243.domain.isp.com); заголовок Precedence: bulk; opt-in-согласие; в теле — не-электронный контакт (телефон и физадрес) и простой механизм отписки | от 0,3% до 1,1% в зависимости от объёма |
Пороги жалоб у Mail.ru зависят от месячного объёма рассылки:
- до 10 000 писем — 1,1%;
- до 500 000 — 1%;
- до 10 млн — 0,8%;
- до 50 млн — 0,5%;
- свыше 50 млн — 0,3%.
С ноября 2025 Gmail ужесточил обработку: несоответствующие письма получают уже не мягкие предупреждения, а временные или постоянные отклонения. То есть «настрою потом» превратилось в «не доставлю совсем». Подробнее про то, из чего вообще складывается попадание во «Входящие», — в разборе доставляемость email-рассылок.
Как добавить записи в DNS вручную
Если вы шлёте письма со своего сервера или хотите поставить записи руками, порядок такой:
- Зайдите в панель управления DNS вашего домена — у регистратора (reg.ru, Timeweb и т.п.) или у хостинг-провайдера, где делегирована зона.
- Добавьте одну TXT-запись SPF для корня домена (@) со списком разрешённых отправителей, уложившись в лимит 10 DNS-запросов.
- Добавьте TXT-запись DKIM по адресу
селектор._domainkey— публичный ключ выдаёт почтовый сервис или ваш сервер. - Добавьте TXT-запись DMARC по адресу
_dmarcс политикой (начните сp=none) и адресом для агрегированных отчётов (тегrua). - Подождите обновления DNS-зоны — от 30 минут до 24 часов — и проверьте записи валидатором.
Как это автоматизируют сервисы рассылок
Если вы отправляете через ESP, вам не нужно генерировать ключи руками: сервис при подключении домена сам показывает готовые TXT-записи, а вы копируете их в DNS. Разберём на трёх примерах. Полный обзор рынка — в подборке сервисы email-рассылок.
Unisender при аутентификации домена просит внести три TXT-записи. Значение SPF содержит include:spf.unisender.com ~all; если SPF на домене уже есть — нужно добавить этот include в существующую запись, а не создавать вторую. DKIM и DMARC генерируются в панели, а для Mail.ru потребуется ещё MX-запись (например, emx.mail.ru).
SendPulse даёт SPF для корня (@) вида v=spf1 include:mxsspf.sendpulse.com +a +mx ~all (при наличии SPF — добавить mxsspf.sendpulse.com в существующую запись). DKIM ставится TXT-записью с именем sign._domainkey и значением v=DKIM1; k=rsa; p=<публичный ключ>. Активация записей может занимать до 24 часов; проверить их можно в разделе Email → Настройки сервиса → Настройки домена кнопкой «Check DNS records».
UniOne при добавлении домена-отправителя показывает готовые записи SPF, DKIM и DMARC сразу, а вы вносите их в панель регистратора. Обновление DNS-зоны — от 30 минут до нескольких часов; заявляемая сервисом доставляемость — 99,8%.
Ориентир по тарифам этих трёх сервисов на дату публикации:
| Сервис | Бесплатно | Платно (от) | Нюанс |
|---|---|---|---|
| Unisender | «Фри» — до 1500 писем/мес на базу до 100 адресов | платные «Лайт» и «Стандарт» — цена зависит от размера базы (от сотен до десятков тысяч контактов); актуальные суммы на официальной странице тарифов | есть пакетный тариф «Оптом» — оплата за объём писем |
| SendPulse | до 15 000 писем/мес на базу до 500 подписчиков | платный Standard — цена растёт с числом подписчиков; актуальные суммы на официальной странице тарифов | сервис ограничил работу для пользователей из России |
| UniOne | trial — 6000 писем/мес на 4 месяца | Standard от $6/мес (50 000 писем/мес): SMTP + Web API, шаблоны, трекинг | перерасход $0,75/1000 писем; выделенный IP — $40/мес + $20 разово |
Честно про ссылку
Ссылки на Unisender, SendPulse и UniOne в этой статье — партнёрские: если вы перейдёте и оформите тариф, vakas.ru может получить комиссию. На выбор это не влияет — сервис ставит готовые SPF/DKIM/DMARC-записи одинаково, купите вы через нашу ссылку или напрямую. Мы включили их потому, что автоматическая генерация записей реально экономит время. А все факты и требования почтовиков выше — из RFC и официальных справок Gmail, Yahoo и Mail.ru, а не из рекламных материалов сервисов.
Почему письма всё равно уходят в спам
Самое неприятное открытие для новичков: даже когда SPF, DKIM и DMARC настроены идеально и все проверки проходят, письма всё равно могут падать в спам. Причина в том, что аутентификация — это не репутация. Три записи лишь подтверждают, что письмо действительно от вас и его не подделали, — то есть дают допуск к проверке репутации домена и IP. А дальше почтовик смотрит на спам-рейт, качество базы, наличие заголовка Precedence: bulk, удобство отписки и жалобы пользователей.
«Грязная» база, покупные адреса, отсутствие opt-in и высокий процент жалоб утопят даже безупречно подписанное письмо. Поэтому аутентификация — это необходимое, но не достаточное условие. Как выстроить рассылку так, чтобы не собирать жалобы, — в отдельном разборе как составить план рассылки, чтобы не попасть в спам.
О чём предупреждают отзывы
- SendPulse — медленная модерация и блокировки рассылок без предупреждения: при проверке спрашивают, откуда база, а одобрение даже добавленных адресов в старую рассылку может занимать до суток.
- SendPulse ограничил работу для пользователей из РФ, а доставляемость на российских почтовиках, по отзывам, чуть ниже, чем у Unisender.
- Unisender — жалобы на доставляемость с общих (shared) IP и урезанный функционал на дешёвых тарифах; первую рассылку иногда приходится ждать 1–2 дня из-за модерации шаблонов.
- Unisender — по отзывам, устаревший интерфейс и неудобное API.
- Общая для всех ESP боль: даже с настроенными SPF/DKIM/DMARC письма уходят в спам из-за репутации домена и IP, «грязной» базы и жалоб — сама аутентификация инбокс не гарантирует.
Практический вывод для 2026 года
Настраивайте все три записи сразу, даже если шлёте немного: Gmail требует минимум SPF или DKIM у всех отправителей, а полный набор SPF + DKIM + DMARC — 5000 и более писем в сутки. Начните DMARC с политики p=none, соберите отчёты, потом двигайтесь к quarantine и reject. Проверьте, что SPF укладывается в лимит 10 DNS-запросов и запись на домене одна. Но держите в голове главное: аутентификация — это пропуск на проверку репутации, а не гарантия «Входящих». Чистая база, opt-in и спам-рейт ниже порогов почтовиков решают не меньше, чем правильные DNS-записи.
Частые вопросы
Нужны ли SPF, DKIM и DMARC, если я отправляю меньше 5000 писем в день?
Да. Gmail с 1 февраля 2024 года требует у всех отправителей минимум SPF или DKIM. Полный набор SPF + DKIM + DMARC (минимум p=none) обязателен для массовых отправителей — 5000 и более писем в сутки на Gmail-адреса. Но настроить все три записи стоит сразу: это не сложнее, а требования почтовиков со временем только ужесточаются.
Можно ли иметь две SPF-записи на один домен?
Нет. На домене должна быть ровно одна TXT-запись SPF — вторая ломает проверку. Если вам нужно разрешить нескольких провайдеров (свой сервер, сервис рассылок, CRM), их объединяют внутри одной записи через механизм include, а не заводят отдельные SPF-записи.
Почему письма всё равно попадают в спам, хотя SPF, DKIM и DMARC настроены и проходят проверку?
Потому что аутентификация — это не репутация. Три записи лишь подтверждают, что письмо от вас и не подделано, то есть дают допуск к проверке репутации. А дальше на попадание во «Входящие» влияют спам-рейт, качество базы, заголовок Precedence: bulk, наличие простой отписки и жалобы получателей. С «грязной» базой и высоким процентом жалоб письма уходят в спам даже с идеальной аутентификацией.
Какую политику DMARC ставить — none, quarantine или reject?
Почтовики требуют минимум p=none. Безопасный путь — двигаться от мягкого к жёсткому: сначала none (только мониторинг и отчёты), затем, убедившись по отчётам, что легитимная почта проходит, — quarantine, и лишь потом reject. Более строгие политики защищают бренд от подделок, но на дату публикации не обязательны — обязательно лишь наличие DMARC.
Что такое ошибка «SPF PermError / too many DNS lookups» и как её избежать?
Это превышение лимита в 10 DNS-запросов на одну проверку SPF. В лимит входят механизмы include, a, mx, ptr, exists и модификатор redirect; прямые ip4 и ip6 не считаются. Один include:_spf.google.com из-за вложенности съедает около четырёх запросов, поэтому лимит легко превысить, добавив пару сервисов. Результат — PermError, и письмо рискует уйти в спам. Лечится сокращением и «уплощением» SPF-записи.
