Артём Савельев 
SPF, DKIM и DMARC: почему письма с вашего домена падают в спам
Заявки с сайта не доходят, счета клиентам падают в спам, а рассылка «уходит в никуда» — в большинстве случаев дело не в текстах писем, а в трёх DNS-записях домена. С 2024 года крупнейшие почтовые сервисы сделали их фактически обязательными. Разбираем, как работают SPF, DKIM и DMARC, какие требования уже действуют и как эти записи незаметно ломаются.
Как почтовый сервис решает, что вы спамер
Протокол электронной почты доверчив: в поле «От кого» технически можно подставить любой адрес. Поэтому принимающий сервер задаёт три вопроса. Имел ли сервер-отправитель право слать письма от имени этого домена — на это отвечает SPF. Не подделано ли письмо по дороге — DKIM. И что делать, если первые две проверки провалены, — DMARC. Все три ответа лежат не в письме, а в DNS-записях вашего домена: их публикуете вы, а читает — каждый почтовый сервер мира при каждом входящем письме с вашего адреса.
SPF: кто имеет право отправлять
SPF — это TXT-запись со списком серверов, которым разрешено отправлять почту от имени домена. Выглядит так:
v=spf1 include:_spf.yandex.net ip4:192.0.2.10 -all
Читается просто: почту может слать инфраструктура Яндекса и сервер 192.0.2.10, всем остальным — отказ (-all). Мягкий вариант ~all помечает нарушителей как подозрительных, но не запрещает. У SPF два известных подводных камня. Первый: запись должна быть одна — вторая TXT-запись с v=spf1 делает результат проверки невалидным. Второй: стандарт разрешает максимум 10 DNS-обращений при проверке; каждый include — это обращение, и он может тянуть за собой свои. Подключили CRM, рассыльщик, хелпдеск и корпоративную почту — лимит кончился быстрее, чем кажется, и SPF молча перестал работать.
DKIM: цифровая подпись письма
DKIM решает другую задачу: доказать, что письмо не изменили по дороге и что его действительно отправил владелец домена. Отправляющий сервер подписывает каждое письмо закрытым ключом, а открытый ключ публикуется в DNS — в записи вида selector._domainkey.вашдомен.ru. Принимающий сервер сверяет подпись с ключом из DNS. Рекомендованная длина ключа сегодня — 2048 бит; старые 1024-битные ключи считаются слабыми, и почтовые сервисы относятся к ним всё строже. Практическая деталь: селекторов может быть несколько (у каждого сервиса рассылки — свой), и каждый из них — отдельная DNS-запись, которую можно случайно снести при переезде зоны.
DMARC: политика и обратная связь
DMARC связывает SPF и DKIM воедино: он говорит принимающему серверу, что делать с письмом, не прошедшим проверки, и куда присылать отчёты. Запись публикуется в _dmarc.вашдомен.ru:
v=DMARC1; p=quarantine; rua=mailto:dmarc@вашдомен.ru
Политика p бывает трёх уровней: none — только наблюдать и слать отчёты, quarantine — подозрительное в спам, reject — отклонять. Разумный путь внедрения — начать с p=none и читать отчёты (параметр rua): они покажут, кто на самом деле шлёт письма от вашего имени — включая забытый сервис уведомлений и, возможно, спамеров. Когда легитимные источники учтены в SPF/DKIM, политику ужесточают до quarantine, затем reject. Побочный бонус: с p=reject подделывать письма «от вашего банка/магазина» становится практически бессмысленно — фишинг от вашего имени просто не доставляется.
План внедрения DMARC: от наблюдения к защите
Резко включать строгую политику опасно — можно молча отрезать себе легитимную почту. У DMARC для плавного перехода есть параметр pct: он указывает, к какой доле писем применять политику. Практичный график выглядит так:
| Этап | Политика | Что делаете |
|---|---|---|
| Недели 1–2 | p=none + rua | Только собираете отчёты: кто шлёт от вашего имени |
| Недели 3–4 | p=none | Доводите SPF/DKIM у всех легитимных источников из отчётов |
| Недели 5–6 | p=quarantine; pct=25 | Карантин для четверти подозрительных писем, смотрите на эффект |
| Недели 7–8 | p=quarantine; pct=100 | Полный карантин; отчёты чистые — идём дальше |
| Итог | p=reject | Подделки от вашего имени перестают доставляться вовсе |
Для поддоменов есть отдельный параметр sp= — не забудьте про него, если с поддоменов почта не уходит вообще: sp=reject закрывает спамерам лазейку вида mail.вашдомен.ru.
Это уже не рекомендации: требования 2024 года
С февраля 2024 года Gmail и Yahoo перевели аутентификацию почты из разряда «хорошего тона» в обязательные требования. Для отправителей от 5 000 писем в день на адреса Gmail правила такие:
| Требование Gmail | Все отправители | Массовые (5 000+/день) |
|---|---|---|
| SPF и DKIM | Обязательны | Обязательны оба |
| DMARC | Минимум p=none | Обязателен |
| Доля жалоб на спам | — | Держать ниже 0,1%, порог отсечения — 0,3% |
| Отписка в один клик | Для маркетинговых писем | Обязательна, обработка за 48 часов |
| Обратная DNS-запись (PTR) | Обязательна | Обязательна |
С конца 2025 года Gmail ужесточил исполнение: письма без аутентификации не просто теряют в доставляемости, а начинают отклоняться. Российские почтовые сервисы двигаются в ту же сторону — в правилах для отправителей рассылок Яндекс и VK также требуют корректной аутентификации почты домена. Иными словами: у домена, с которого уходят письма, эти записи сегодня должны быть настроены по умолчанию — независимо от того, шлёте вы 50 писем в день или 50 000.
Как это ломается незаметно
Коварство почтовых DNS-записей в том, что ломаются они тихо. Письма продолжают отправляться — просто всё чаще не доходят, и заметно это становится через недели, по косвенным признакам: «клиент говорит, не получал счёт». Типовые сценарии из практики:
Переезд DNS или смена хостинга. Зону перенесли, A-записи скопировали, а TXT с SPF и записи селекторов DKIM — забыли. Сайт работает, почта деградирует. Как устроены DNS-записи и что в них проверять, мы разбирали в отдельной статье.
Подключение нового сервиса рассылок. Маркетинг подключил платформу, письма пошли «от вашего домена», но include в SPF не добавили — и с точки зрения DMARC ваша же рассылка выглядит подделкой. При p=reject она целиком уходит в отказ.
Превышение лимита в 10 DNS-обращений. Сервисов стало много, SPF распух — и проверка стала возвращать permerror. Внешне запись «на месте», по факту не работает.
Попадание IP в чёрные списки. Даже при идеальных записях письма не дойдут, если IP отправляющего сервера попал в DNSBL — например, после взлома соседа по shared-хостингу. Это отдельный контур контроля, о нём — в статье про DNSBL.
Три команды в терминале покажут текущее состояние: dig TXT вашдомен.ru (SPF), dig TXT selector._domainkey.вашдомен.ru (DKIM — селектор подскажет ваш почтовый сервис), dig TXT _dmarc.вашдомен.ru (DMARC). Нет записи в ответе — нет и защиты.
Мини-чек-лист владельца домена
| Запись | Что проверить | Чем грозит ошибка |
|---|---|---|
| SPF | Ровно одна запись; все сервисы-отправители в include; ≤10 DNS-обращений | Письма в спаме или отклонены; permerror при распухшей записи |
| DKIM | Ключ 2048 бит; селекторы всех сервисов на месте после переездов | Подпись не проверяется — репутация домена падает |
| DMARC | Запись есть (минимум p=none); rua-отчёты приходят и читаются | Не выполняются требования Gmail/Yahoo; фишинг от вашего имени доставляется |
| PTR (обратная запись) | IP отправляющего сервера резолвится в осмысленное имя | Отсев на первом рубеже антиспама |
| IP в DNSBL | Регулярная проверка отправляющего IP по чёрным спискам | Недоставка даже при идеальных SPF/DKIM/DMARC |
Разово настроить записи мало — они должны оставаться на месте после каждого переезда и изменения зоны. Пруфен ежедневно проверяет DNS-записи домена и сообщает, если они изменились или пропали, а проверка DNSBL следит, не попал ли ваш IP в чёрные списки. Обе проверки есть и на бесплатном плане.
Частые вопросы
У меня нет рассылок, только письма с сайта и рабочая почта. Мне это нужно? Да. Требование SPF/DKIM для всех отправителей в Gmail не зависит от объёма, а DMARC хотя бы с p=none — дешёвая страховка и от проблем доставки, и от фишинга под вашим именем.
Достаточно ли одного SPF без DKIM и DMARC? Нет. SPF ломается при пересылке письма и не защищает содержимое. Тройка работает как система: SPF отвечает за источник, DKIM за целостность, DMARC за политику и обратную связь.
Сразу поставить p=reject — плохая идея? Рискованная: если какой-то легитимный сервис не учтён в SPF/DKIM, его письма молча перестанут доходить. Стандартный путь — none с отчётами, затем quarantine, затем reject.
Как понять, что записи «отвалились» после переезда? Либо вручную командой dig после каждого изменения зоны, либо автоматически — мониторингом DNS-записей, который сравнивает текущие значения с эталонными и уведомляет при любом расхождении.
Почта на Яндекс 360 или VK WorkSpace — мне всё равно нужно это настраивать? Да, но проще: обе платформы генерируют готовые значения SPF и DKIM — их нужно один раз добавить в DNS вашего домена и следить, чтобы они не потерялись при переездах. DMARC-запись в любом случае публикуете и сопровождаете вы сами.
У меня есть домены, с которых почта не отправляется вообще. Их тоже настраивать? Обязательно — припаркованные и технические домены любимая мишень спамеров именно потому, что за их почтой никто не следит. Для домена без почты публикуется запретительный набор: SPF v=spf1 -all (отправлять не может никто) и DMARC v=DMARC1; p=reject. Две записи раз и навсегда закрывают домен для подделок.
Куда придут rua-отчёты и как их читать? На адрес, который вы укажете в записи; приходят они XML-файлами от каждого крупного почтовика раз в сутки. Читать их глазами тяжело — обычно используют любой агрегатор DMARC-отчётов или хотя бы раз в неделю просматривают сводку: главное, что вы ищете, — легитимные источники, у которых не сходится SPF или DKIM.