DKIM, SPF и DMARC: настраиваем за час, чтобы письма не падали в спам

Звонит клиент — юридическая фирма из Подольска — говорит: наши коммерческие предложения не читают, третий месяц шлём и тишина. Открываю DNS их домена: SPF нет, DKIM нет, DMARC нет. Письма улетали в спам ещё до того, как человек видел тему. За восемь лет в IT-аутсорсинге я видел эту картину у доброй половины клиентов — бухгалтерских фирм, медклиник, небольших производственников. Лечится за час.

Почему письма улетают в спам: что происходит на стороне почтовика

Любой человек может написать письмо с адресом From: director@вашдомен.ru — даже не имея никакого доступа к вашему серверу. Это называется spoofing, и это реальная, повседневная проблема. Почтовые серверы Gmail, Яндекс, Mail.ru, корпоративные Exchange и Outlook всё это понимают. Поэтому при получении письма они проверяют: а тот ли сервер его вообще отправил? Если у отправляющего домена нет никаких инструкций — нет SPF, нет DKIM — принимающий сервер просто не знает, доверять или нет. Результат в большинстве случаев один. Спам.

Три года назад ко мне обратилась торговая компания из Люберец. Менеджеры жаловались: коммерческие предложения не открывают. Когда я попросил одного менеджера прислать тестовое письмо и посмотрел на служебные заголовки — всё стало ясно. SPF-записи нет. DKIM нет. Домен зарегистрировали два года назад, почту настроили на хостинге за 200 рублей в месяц, и с тех пор в DNS-панель никто не заходил. Gmail ставил такие письма в спам автоматически, без разбора. Никакие пометки «важное» в теме не помогали.

SPF, DKIM и DMARC — это три TXT-записи в DNS вашего домена. Не программы. Не сервисы с оплатой. Просто текстовые строки, которые один раз добавляете в настройки домена. SPF говорит: «с этого домена письма могут слать только вот эти серверы». DKIM добавляет к каждому письму криптографическую подпись — её невозможно подделать без приватного ключа, который лежит на вашем сервере. DMARC объясняет принимающему серверу, что делать с письмом, которое не прошло проверку. Три записи. Один час работы. Дальше работает само.

SPF: объясняем почтовому миру, кто имеет право слать письма от вашего домена

Начнём с SPF — самой простой из трёх. Заходите в DNS-панель вашего домена: это может быть панель регистратора — RU-CENTER, Reg.ru, Timeweb, Selectel — или отдельный DNS-сервис вроде Cloudflare. Создаёте TXT-запись для корневого домена, хост @ или просто вашдомен.ru. Значение записи зависит от почтового сервиса. Яндекс 360: v=spf1 include:_spf.yandex.ru ~all. Google Workspace: v=spf1 include:_spf.google.com ~all. Собственный почтовый сервер с IP-адресом 5.100.200.50: v=spf1 ip4:5.100.200.50 ~all. Вот и всё.

Разберём структуру записи. v=spf1 — версия протокола, всегда так, не меняется. Дальше идут механизмы — кому разрешено слать. include:домен означает «доверяй серверам, перечисленным в SPF-записи вот этого домена». ip4: — конкретный IPv4-адрес. mx — серверы из MX-записей вашего домена. В конце обязательный финальный механизм: -all означает жёстко отклонять письма от всех неизвестных источников, ~all — принять, но пометить как подозрительное. Я обычно начинаю с ~all, слежу за отчётами DMARC две недели, убеждаюсь что всё в порядке и нет забытых отправителей — и только потом меняю на -all.

Критически важное правило, которое нарушают почти все: для одного домена должна быть ровно одна SPF-запись. Не две, не три. Одна. Это нарушение RFC 7208, и почтовые серверы при нескольких SPF-записях ведут себя непредсказуемо: одни игнорируют обе, другие выбирают случайную. Несколько записей чаще всего появляются когда компания меняла хостинг или подключала новые сервисы — старую не удалили, новую добавили рядом. Если используете и основной сервер, и SendPulse для рассылок — пишите всё в одну строку: v=spf1 ip4:5.100.200.50 include:spf.sendpulse.com ~all. Проверить количество записей: команда dig TXT вашдомен.ru или инструмент MXToolbox SPF Check.

DKIM: цифровая подпись, которую невозможно подделать

DKIM работает на криптографии с парой ключей. Приватный ключ хранится на вашем почтовом сервере и подписывает каждое исходящее письмо — невидимой строкой в заголовке. Публичный ключ вы публикуете в DNS. Когда принимающий сервер получает ваше письмо, он берёт публичный ключ из DNS и проверяет подпись. Всё сошлось — письмо точно с вашего сервера и не изменялось в дороге. Без приватного ключа подпись не подделать. Именно поэтому DKIM — главный аргумент в пользу легитимности письма перед любым спам-фильтром.

На Яндекс 360 и Google Workspace DKIM настраивается в административной панели. Яндекс: раздел «Почтовые серверы» — «DKIM-подпись» — нажать «Включить», скопировать готовую TXT-запись. Google: Admin Console — Apps — Google Workspace — Gmail — «Аутентификация электронной почты» — Generate new record. Оба сервиса выдадут строку вида mail._domainkey.вашдомен.ru со значением v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQ... (дальше длинная строка публичного ключа). Именно эту строку создаёте в DNS как TXT-запись. Имя записи — это «селектор»: у Google по умолчанию google, у Яндекса — mail.

На собственном сервере чуть сложнее — но ненамного. Если у вас mailcow — популярный Docker-стек для корпоративной почты — в веб-интерфейсе администратора заходите в «Управление почтой» — «Домены» — нажимаете иконку DKIM рядом с нужным доменом, выбираете длину ключа 2048 бит (1024 уже считается слабым, ряд серверов его отклоняет), копируете публичный ключ и вставляете в DNS. На классическом Postfix с OpenDKIM — установка пакета, генерация ключей через opendkim-genkey, правка /etc/opendkim.conf и /etc/postfix/main.cf. Занимает 20-30 минут, если делали хоть раз. Один раз настроил — работает годами.

DMARC: политика для чужих серверов и отчёты прямо на почту

DMARC — последний шаг. И самый умный из трёх. Эта запись говорит принимающим серверам: если письмо якобы от моего домена не прошло SPF или DKIM — вот что с ним делайте. Плюс — DMARC присылает вам отчёты о том, кто и откуда слал письма от имени вашего домена за последние сутки. Запись создаётся для хоста _dmarc.вашдомен.ru как TXT. Минимальный рабочий вариант: v=DMARC1; p=none; rua=mailto:dmarc@вашдомен.ru. Здесь p=none — режим мониторинга, письма не блокируются. rua — адрес, куда будут приходить агрегированные XML-отчёты.

Политик три. none — только мониторинг, ничего не блокируем. quarantine — письма без авторизации летят в папку спам у получателя. reject — принимающий сервер вообще не принимает такое письмо. Правильная последовательность: начинаете с p=none, даёте поработать две-три недели, смотрите отчёты, убеждаетесь что все легитимные сервисы прописаны в SPF. Только потом переходите к quarantine, ещё через две недели — к reject. Один мой клиент поставил p=reject сразу и заблокировал письма от собственной CRM, которую забыли добавить в SPF. Два дня разбирались.

В записи DMARC есть дополнительные полезные параметры. ruf=mailto:адрес — адрес для форенсик-отчётов с подробными данными по каждому письму, которое не прошло проверку. Очень помогает на этапе отладки. pct=100 означает применять политику ко всем письмам — можно начать с pct=10 для плавного перехода. sp= задаёт политику для поддоменов отдельно. Полная строка для строгого режима выглядит так: v=DMARC1; p=reject; rua=mailto:dmarc@вашдомен.ru; ruf=mailto:dmarc@вашдомен.ru; pct=100; adkim=r; aspf=r. Но я такую ставлю только после минимум месяца наблюдений. Не раньше.

Проверяем результат: три инструмента, которые всегда под рукой

Настроили — проверяем. DNS-записи обновляются от 15 минут до 48 часов, TXT-записи обычно подхватываются быстро. Первый инструмент — mxtoolbox.com. Бесплатный, без регистрации. Там отдельные проверки: SPF Lookup, DKIM Lookup, DMARC Lookup. Вводите домен — смотрите на зелёные галочки. Что-то красное — читаете описание ошибки, там написано конкретно: «duplicate SPF record», «DKIM record not found», «no DMARC record». Добавьте в закладки. Будете пользоваться часто.

Второй инструмент — mail-tester.com. Сервис оценивает отправку по десятибалльной шкале. Заходите, получаете одноразовый адрес вроде test-4f8ab12c@srv1.mail-tester.com, отправляете туда письмо со своего корпоративного ящика — обычное, как клиенту. Ждёте тридцать секунд, нажимаете «Check your score». Получаете подробный отчёт: SPF, DKIM, DMARC, репутация IP, содержимое письма, наличие в чёрных списках. 10/10 — идеал. 8-9 — хорошо. Ниже 7 — надо разбираться. Я прогоняю этот тест у каждого нового клиента сразу после настройки почты.

Третий способ — письмо на адрес check-auth@verifier.port25.com. Отправляете обычное письмо, в ответ приходит автоматический отчёт прямо в почту: строки DKIM check: pass, SPF check: pass, DMARC check: pass — или fail с описанием причины. Старый инструмент, существует лет пятнадцать, абсолютно надёжный. Работает без регистрации — просто шлёте письмо и читаете ответ. Удобно когда нет времени лезть в браузер. Сохраните адрес в контактах прямо сейчас.

Ошибки, которые я исправляю у каждого второго клиента

Ошибка первая — две SPF-записи на одном домене. Появляется когда компания переезжала с хостинга на хостинг или подключала новые сервисы: старую запись не удалили, новую добавили рядом. В итоге в DNS две строки v=spf1 — нарушение стандарта RFC 7208. Почтовые серверы ведут себя непредсказуемо: одни игнорируют обе записи, другие выбирают случайную. Лечение простое: удаляете обе, создаёте одну объединённую, которая включает все нужные источники. Проверить: dig TXT вашдомен.ru в терминале или MXToolbox.

Ошибка вторая — забытые рассыльщики. Компания настроила SPF для основного сервера, но использует CRM — Bitrix24, AmoCRM, RetailCRM — которая тоже отправляет письма от имени корпоративного домена: уведомления, напоминания, счета. Или подключили DashaMail, Unisender, SendPulse. В SPF их нет. Письма от этих систем падают в спам. У каждого сервиса в документации написано что именно добавить в SPF — обычно строка вида include:spf.сервис.ru. Найдите, добавьте, проверьте. Занимает пять минут.

Ошибка третья — несколько доменов, DKIM только на одном. Компания работает с firma.ru, но есть ещё firma.com и поддомены — mail.firma.ru, info.firma.ru. Письма уходят с разных адресов. DKIM нужен для каждого домена и каждого поддомена, с которого реально отправляется почта. Отдельная пара ключей, отдельная DNS-запись для каждого. Пропустили один — письма с него без подписи. У меня был клиент — юридическое бюро — семь активных доменов, на трёх DKIM не настроен. Полкоманды слала договоры прямо в спам клиентов. Добавили DKIM на оставшиеся три домена — проблема ушла за день.

Когда трёх записей мало: что ещё влияет на доставляемость

SPF, DKIM и DMARC — необходимое условие. Но не всегда достаточное. Репутация IP-адреса вашего сервера тоже имеет значение. Если сервер стоит на дешёвом shared-хостинге, где ещё сотня сайтов, и кто-то из «соседей» рассылает спам — ваш IP может оказаться в чёрных списках. Проверить: MXToolbox Blacklist Check — вводите IP, смотрите по 100+ базам. Если попали — либо меняете провайдера, либо просите выдать выделенный «чистый» IP (обычно плюс 100-500 рублей к тарифу), либо смотрите в сторону SMTP-шлюзов с хорошей репутацией.

Новый домен — отдельная история. Домену меньше трёх месяцев или с него никогда раньше не слали писем — репутация нулевая. Gmail и Яндекс к таким относятся настороженно, даже если все три записи настроены идеально. Нужен прогрев: первые две недели слать по 20-50 писем в день реальным получателям, которые будут открывать письма и не жать «спам». Постепенно увеличивать объём. Через месяц-полтора репутация нарабатывается, доставляемость нормализуется. Один день с большим объёмом с нулевой репутацией может надолго испортить историю домена. Не торопитесь.

И про PTR-запись — её часто забывают. Это обратная DNS-запись: IP-адрес вашего почтового сервера должен разрешаться в hostname, соответствующий домену. Настраивается не в DNS-панели домена, а у интернет-провайдера — через техподдержку или в панели управления VPS. Если сервер с адресом 5.100.200.50 называется mail.firma.ru — провайдер должен настроить обратную запись так, чтобы этот IP указывал на mail.firma.ru. Без PTR корпоративные серверы на Exchange и Outlook смотрят на ваши письма с подозрением. Обращение по поводу PTR к большинству провайдеров бесплатно.

Частые вопросы

Нужно ли настраивать SPF, DKIM и DMARC, если я использую Яндекс 360 или Google Workspace?
Да, обязательно. Яндекс и Google сами по себе не добавляют эти записи в DNS вашего домена — это делаете вы вручную. Оба сервиса в административной панели прямо показывают, какие TXT-записи нужно добавить — просто копируете и вставляете. Без SPF и DKIM письма с вашего корпоративного домена доставляются хуже, особенно на Gmail и корпоративные Exchange-серверы. Первый раз занимает 20-30 минут.

Что будет, если поставить DMARC с политикой p=reject сразу, без двух недель мониторинга?
Рискуете заблокировать часть своих же легитимных писем. Если CRM, сервис рассылок или система бронирования отправляет письма от вашего домена и не прописана в SPF — её письма начнут отклоняться получателями. Я видел как компании случайно блокировали автоматические счета из 1С и уведомления из Bitrix24. Поэтому: начинайте с p=none, смотрите отчёты на rua-адрес, убеждайтесь что все отправители известны, и только потом ужесточайте политику.

Через сколько времени после настройки письма перестанут попадать в спам?
DNS-записи обновляются от 15 минут до 48 часов. После этого почтовые серверы начинают учитывать их немедленно. Но если ваш домен или IP уже попал в чёрные списки — одной настройки SPF/DKIM/DMARC недостаточно: нужно подавать заявки на delisting в каждом списке отдельно. Google Postmaster Tools и Яндекс Постмастер помогут отслеживать репутацию домена и разбираться с проблемами доставляемости.

Придётся ли переделывать настройки DKIM, если мы сменим почтового провайдера?
Да. DKIM-ключи привязаны к конкретному серверу или сервису — приватный ключ хранится там. При переезде новый провайдер генерирует новую пару ключей, и вы добавляете новую TXT-запись в DNS с новым публичным ключом. SPF тоже обновляете: убираете старого провайдера, добавляете нового. DMARC при этом трогать не нужно, если адрес для отчётов не меняется.