Внедрение DKIM на хостинге Beget: пошаговый опыт и шаблоны для техподдержки

Этот текст — не сухая инструкция из базы знаний, а разбор реального внедрения: что я кликал, где спотыкался, какие письма писал в поддержку Beget и какими командами проверял результат. К концу вы сможете повторить настройку на своём домене за вечер и вытащить письма из спама.

Почему письма уходят в спам и при чём тут три буквы: SPF, DKIM, DMARC

История началась прозаично. У 5на5 есть рассылка: подсказки по конвертации файлов, анонсы инструментов, реактивация неактивных пользователей. В какой-то момент я заметил, что открываемость просела вдвое. Полез смотреть — и обнаружил свои же письма в папке «Спам» Gmail. Классика: домен новый, репутация нулевая, аутентификации нет. Для почтовиков такое письмо выглядит как потенциальный фишинг, даже если внутри безобидный анонс.

В феврале 2024 года Google и Yahoo ужесточили правила для отправителей, а Mail.ru и Яндекс двигались туда же ещё раньше. Если коротко, требование такое: массовая рассылка без SPF, DKIM и DMARC либо режется в спам, либо отклоняется на входе с ошибкой 550 5.7.26. Это уже не «желательно» — это входной билет.

Эти три записи — разные слои одной защиты, и работают они только вместе. Чтобы дальше не путаться, разложу по полочкам, кто за что отвечает.

Сегодня говорим в основном про DKIM, потому что он самый «магический» и вокруг него больше всего вопросов в поддержку. Но SPF и DMARC я тоже покажу — без них DKIM половинчатый, и почтовики это видят.

Что такое DKIM простыми словами (но без вранья)

DKIM — это асимметричная криптография, натянутая на электронную почту. Механика такая:

1. На стороне почтового сервера (в нашем случае — Beget) генерируется пара ключей: приватный и публичный. Приватный ключ хранится на сервере и никуда не уезжает. 2. Когда сервер отправляет ваше письмо, он берёт часть заголовков и тело, считает от них хеш и подписывает его приватным ключом. Подпись вшивается в служебный заголовок DKIM-Signature. 3. Публичный ключ вы публикуете в DNS своего домена — в виде TXT-записи. 4. Почтовый сервер получателя видит подпись, идёт в DNS за публичным ключом, проверяет подпись. Сошлось — значит, письмо реально отправлено владельцем домена и не было изменено по дороге.

Ключевой момент, который многих путает: в DNS лежит только публичный ключ. Его видно всем, и это нормально — расшифровать им ничего нельзя, только проверить подпись. Поэтому DKIM-запись не секрет, её спокойно можно показывать в статье (что я и сделаю ниже на «скриншотах»).

Адрес, по которому почтовик ищет ключ, собирается из двух частей: селектор + домен. Выглядит он так:

# <селектор>._domainkey.<ваш домен>
beget._domainkey.example.ru

Селектор — это просто метка, позволяющая держать несколько ключей одновременно (удобно при ротации). У Beget селектор по умолчанию виден прямо в панели; у меня в зоне он назывался beget. У вас может отличаться — всегда смотрите фактическое имя записи, а не копируйте вслепую.

Особенность Beget: DKIM почти автоматический — но есть один нюанс

Главная хорошая новость про Beget: если почта вашего домена обслуживается на Beget и домен использует DNS-серверы Beget (ns1.beget.com, ns2.beget.com и их пары), то SPF и DKIM создаются автоматически при включении почты. Вам буквально не нужно ничего генерировать руками — ключи уже выпущены, записи уже в зоне.

А теперь нюанс, из-за которого половина людей и идёт в поддержку: автоматика работает только пока DNS-зоной управляет сам Beget. Как только вы переносите NS на Cloudflare, Reg.ru или любой внешний DNS (а это очень частый сценарий — ради проксирования, CDN или единого управления), Beget перестаёт быть хозяином зоны. Записи, которые он «нарисовал» у себя, в вашем внешнем DNS не появляются. Письма продолжают подписываться, но публичного ключа в реальной зоне нет — и проверка DKIM на стороне получателя падает.

Включаем почту и проверяем, есть ли DKIM

Заходим в панель управления Beget → раздел «Почта». Выбираем домен. Если для домена уже заведён хотя бы один почтовый ящик, прокручиваем к блоку настроек домена — там и живёт переключатель подписи. У меня это выглядело так:

Если тумблер DKIM серый — включаем и ждём пару минут, пока Beget сгенерирует ключ и пропишет запись. Если домен на DNS Beget, на этом для базовой настройки можно почти закончить. Но я рекомендую обязательно проверить, что запись реально появилась в зоне — потому что «включено в панели» и «опубликовано в DNS» это, как мы выяснили, не всегда одно и то же.

Находим DKIM-запись в DNS-зоне

Идём в раздел «DNS» (или «Управление DNS») для нужного домена. Здесь Beget показывает все записи зоны. Нас интересуют три строки — SPF, DKIM и (позже) DMARC:

Длинная строка после p= — это и есть публичный ключ в base64. Я её специально обрезал многоточием: у настоящей записи там 200+ символов. Если строка на месте — отлично, ключ опубликован. Проверим это ещё и снаружи, не доверяя одной панели, через обычный dig в терминале:

$ dig +short TXT beget._domainkey.example.ru
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7"
"…IDAQAB"
# ключ виден из внешней сети → DNS отдаёт запись. То, что нужно.

Если DNS на Cloudflare или внешних NS — переносим запись руками

Это тот самый случай-грабли. У меня домен 5на5 как раз сидел на внешнем DNS ради проксирования. В Beget DKIM был «зелёный», а письма продолжали падать в спам с пометкой dkim=none. Решение — скопировать TXT-запись из Beget в свой внешний DNS один в один.

Берём из панели Beget (шаг 2) две вещи: имя записи и её значение. Затем в Cloudflare → DNS → Records → Add record создаём TXT:

Аналогично переносим SPF (v=spf1 redirect=beget.com) и MX-записи, если их ещё нет во внешней зоне. После сохранения даём DNS прогреться (обычно минуты, изредка до пары часов) и снова проверяем через dig из шага 2. Как только ключ отдаётся из внешней сети — DKIM заработал по-настоящему.

Добавляем SPF и DMARC — без них DKIM работает вполсилы

DKIM сам по себе говорит «письмо подлинное». Но почтовики хотят полную картину. SPF подтверждает сервер-отправитель, а DMARC связывает SPF и DKIM в единую политику и включает отчётность. Вот что у меня в итоге оказалось в зоне:

# SPF — кто имеет право слать почту от домена (Beget создаёт сам)
@                  TXT   "v=spf1 redirect=beget.com"

# DKIM — публичный ключ подписи (Beget создаёт сам)
beget._domainkey   TXT   "v=DKIM1; k=rsa; p=MIGfMA0…IDAQAB"

# DMARC — политику добавляем РУКАМИ, Beget её не создаёт
_dmarc             TXT   "v=DMARC1; p=none; rua=mailto:postmaster@example.ru; fo=1; adkim=r; aspf=r"

Разберу DMARC по параметрам, потому что именно тут люди ломают копья:

• p=none — политика «ничего не делать, только наблюдать». На старте это правильный выбор: вы собираете отчёты и убеждаетесь, что легитимная почта проходит, прежде чем включать жёсткость.
• rua=mailto:… — адрес для агрегированных отчётов. На него почтовики раз в сутки шлют сводку: сколько писем прошло проверку, сколько нет и с каких IP.
• adkim=r / aspf=r — режим выравнивания «relaxed». Для большинства доменов на Beget подходит; s (strict) включайте только осознанно.

Что писать в техподдержку Beget: 4 готовых шаблона

Beget славится живой и быстрой поддержкой в чате — отвечают предметно, часто правят за вас. Но чтобы не уйти в переписку на три круга, формулируйте запрос конкретно: домен, что сделали, что видите, что ожидаете. Ниже — реальные формулировки, которые экономят время. Подставьте свой домен.

Шаблон 1. DKIM не включается / тумблера нет.

Шаблон 2. DNS внешний (Cloudflare) — прошу выдать значение записи.

Шаблон 3. Нужен ключ 2048 бит вместо 1024.

Шаблон 4. DKIM включён, но проверка падает (dkim=fail/none).

Как это выглядит в реальном чате — примерно так. Привожу сокращённый диалог из своей переписки (по сценарию с внешним DNS):

Проверяем результат: mail-tester, dig и «показать оригинал»

Настроить мало — надо убедиться, что почтовики видят подпись. Я использую три независимых способа проверки, и советую не лениться сделать все три.

Способ 1. mail-tester.com. Открываете сайт, копируете выданный одноразовый адрес, отправляете на него письмо из своей реальной рассылки/ящика, жмёте «проверить». Сервис показывает оценку из 10 и расшифровку по SPF/DKIM/DMARC. До настройки у меня было 6/10 с красным DKIM. После:

Способ 2. «Показать оригинал» в Gmail. Откройте полученное письмо → меню «⋮» → «Показать оригинал». Вверху Gmail прямо показывает результат по трём пунктам. Это самая честная проверка — её делает реальный почтовик на реальном письме:

SPF:    PASS  with IP 5.101.158.x
DKIM:   PASS  with domain example.ru  (selector=beget)
DMARC:  PASS  (policy applied: none)

Authentication-Results: mx.google.com;
  dkim=pass header.i=@example.ru header.s=beget;
  spf=pass; dmarc=pass

Способ 3. dig напрямую — уже показывал в шаге 2, повторю как часть финального чек-листа. Если все три способа дают «pass» — поздравляю, аутентификация настроена полностью.

Как читать DMARC-отчёты и не утонуть в XML

Как только в зоне появляется _dmarc с параметром rua=, почтовики начинают присылать вам агрегированные отчёты — обычно раз в сутки, на указанный адрес. Открываете такое письмо, а внутри — приложенный .xml.gz с сухой статистикой. Выглядит пугающе, но читается просто. Главное, что нужно вытащить из отчёта, — три числа: сколько писем прошло, с каких IP их слали и сошлись ли SPF/DKIM.

<record>
  <source_ip>5.101.158.x</source_ip>       # IP сервера Beget
  <count>412</count>               # столько писем с этого IP
  <policy_evaluated>
    <dkim>pass</dkim>
    <spf>pass</spf>
  </policy_evaluated>
</record>
# ↑ всё легитимно: ваш сервер, обе проверки pass

<record>  ← а вот это уже интересно
  <source_ip>185.x.x.x</source_ip>        # чужой, незнакомый IP
  <count>27</count>
  <policy_evaluated><dkim>fail</dkim><spf>fail</spf></policy_evaluated>
# ↑ кто-то слал письма «от вашего домена». Спуфинг.

Первая запись — норма: ваш сервер Beget, обе проверки прошли. Вторая — звоночек: с неизвестного IP кто-то отправлял почту от имени вашего домена, и проверки ожидаемо упали. Пока политика p=none, такие письма всё равно доходят до получателей — поэтому, убедившись по отчётам, что вся ваша легитимная почта проходит, и стоит ужесточать политику до quarantine, а затем reject. Тогда спуфинг под ваш домен начнёт отклоняться автоматически.

Бонус: BIMI — логотип бренда прямо в почте

Когда SPF, DKIM и DMARC настроены и политика дотянута до p=quarantine или p=reject, открывается следующий уровень — BIMI (Brand Indicators for Message Identification). Это стандарт, который показывает логотип вашего бренда рядом с письмом в списке входящих — в Gmail, Yahoo, Mail.ru. Тот самый кружок с фирменной иконкой вместо безликой буквы.

Важно понимать порядок: BIMI невозможен без работающего DKIM и строгого DMARC. Это его прямое продолжение, а не альтернатива. Чтобы его включить, понадобится: логотип в формате SVG Tiny PS, ещё одна TXT-запись (default._bimi) и — для Gmail — платный сертификат VMC, подтверждающий права на торговую марку. Сертификат недешёвый, поэтому BIMI обычно внедряют бренды, которым важна узнаваемость в почте. Но если вы дочитали до этого места и уже настроили аутентификацию — знайте, что половину пути к BIMI вы прошли. Это хороший ориентир «куда расти» после базовой настройки.

Грабли, на которые я наступил (чтобы вы не наступали)

Сама настройка не сложная — сложно отловить мелочи, из-за которых «всё включено, но не работает». Вот мой список собранных шишек:

• Внешний DNS — главная ловушка. 80% проблем с «не работающим DKIM на Beget» — это домен на чужих NS, куда запись не доехала. Всегда сверяйте, чья зона реально активна (проверка: dig NS example.ru).
• Полное имя записи вместо относительного. В Cloudflare и многих панелях имя достраивается доменом автоматически. Дубль beget._domainkey.example.ru.example.ru — типичная причина dkim=none.
• Проксирование TXT (оранжевое облако). TXT и DKIM нельзя проксировать через Cloudflare — только «DNS only».
• Разбиение длинного ключа на строки. Значение DKIM длиннее 255 символов DNS отдаёт частями. Большинство панелей склеивают строки сами, но если вставляете ключ вручную в «сырой» зоне (BIND), оборачивайте части в кавычки — иначе ключ побьётся.
• Ключ 1024 против 2048 бит. Beget по умолчанию выдаёт 1024 — этого хватает для прохождения проверок, но для аудитов безопасности лучше попросить 2048 (шаблон 3 выше).
• Нетерпение с TTL. После правки DNS дайте записи прогреться. Если у зоны большой TTL, изменения могут «доезжать» до получателей не мгновенно. Не делайте выводов через 30 секунд.
• Забыли DMARC. SPF+DKIM без DMARC проходят, но Gmail/Yahoo для массовых отправителей требуют именно DMARC-запись. Без неё рискуете попасть под ограничения 2024 года.
• Поддомены и сторонние сервисы. Если рассылку шлёте не через Beget, а через сторонний сервис (Unisender, SendPulse и т.п.), у него будет свой селектор и свой DKIM — настраивается отдельно, у Beget вы его не возьмёте.

Итоги: что дала настройка

Замеры до и после — самое наглядное. Цифры по моей рассылке за две недели после внедрения:

Главный вывод банален, но выстрадан: аутентификация почты — это не «галочка для галочки», а напрямую деньги и охват. Open Rate вырос вдвое не потому, что письма стали интереснее, а потому что они стали доходить. На хостинге Beget весь процесс занял один вечер: включить тумблер, перенести запись в внешний DNS, дописать DMARC, проверить. Если домен сразу живёт на DNS Beget — будет ещё быстрее, почти всё за вас сделает автоматика и поддержка.

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

⚡ Коротко: на Beget DKIM почти автоматический — включите тумблер в «Почте» и проверьте запись beget._domainkey в DNS. Если зона на внешнем DNS (Cloudflare) — перенесите TXT-запись руками как «DNS only». Добавьте SPF и DMARC, проверьте через mail-tester и «Показать оригинал» в Gmail. Весь процесс — один вечер, а доставляемость вырастает кратно.