Шаг №2

Здесь еще ничего нет, поэтому давайте заполним

Шаг №3

Шаг №4

Домен добавлен, но теперь вы видите, что в DNS-записях возникла какая-то ошибка. Что ж, давайте заглянем внутрь и посмотрим, что там происходит. Жмите прямо на ваш домен.

Шаг №5

Вот она причина всего квеста с настройками — подтвеждение домена.

У вас 3 пути:

1. Заглянуть в инструкцию и по ней внести нужные DNS записи в домен вашего сайта (Цифра 1 на скрине)
2. Получить ссылку на страницу с настройками и отправить разработчикам вашего сайта, чтобы настройки прописали они (Цифра 2 на скрине)
3. Написать на почту support@qwertymail.ru текст типа: «Нужны настройки домена». Будет здорово, если в письме вы так же укажете ваше имя и почту, по которой вы зарегистрировались на сервисе. Если есть возможность начать общение не с переписки, а с телефонного звонка, то напишите номер телефона и удобное вам время для связи (по Мск). Так проще всего! И это бесплатно! До связи!

Как настроить домен для email-рассылки: SPF, DKIM, DMARC и другие записи

Если вы отправляете коммерческие, информационные или триггерные письма через сервис email-рассылок, одной регистрации в сервисе недостаточно. Перед первой отправкой необходимо правильно настроить домен: добавить DNS-записи, подтвердить отправителя и убедиться, что почтовые системы могут идентифицировать ваши письма.

Основные технологии, о которых нужно знать, — SPF, DKIM и DMARC. В зависимости от сервиса также могут потребоваться CNAME, MX, Return-Path, а для массовых рассылок — корректная отписка через List-Unsubscribe.

Ниже разберём, какие записи нужны для рассылки, где их добавлять, как не ошибиться при настройке и как проверить результат.

---

Какие DNS-записи нужны для email-рассылки

В типичной конфигурации могут использоваться следующие записи:

Запись	Назначение	Нужна ли для рассылки
SPF	Указывает разрешённые серверы отправки	Да
DKIM	Подписывает письма криптографическим ключом	Да
DMARC	Определяет политику проверки SPF/DKIM	Рекомендуется
CNAME	Делегирует часть DNS-настроек сервису	Зависит от сервиса
MX	Указывает серверы входящей почты	В отдельных конфигурациях
TXT	Формат, используемый для SPF, DKIM, DMARC и других данных	Да
BIMI	Позволяет показывать логотип бренда в почтовом клиенте	Опционально

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

Например, Яндекс для собственных рассылок требует подтверждённый домен и настройку MX, SPF и DKIM. (Яндекс)

---

Где настраиваются SPF, DKIM и DMARC

Все эти записи добавляются в DNS-зону домена.

Например, если вы отправляете письма с адреса:

marketing@example.ru

то DNS-настройки находятся в панели, которая управляет DNS домена example.ru.

Это может быть:

• регистратор домена;
• хостинг-провайдер;
• Cloudflare;
• отдельный DNS-провайдер;
• корпоративная IT-инфраструктура.

Важно: место покупки домена и место управления DNS могут отличаться.

Если вы не знаете, где находится DNS-зона, сначала определите, какие DNS-серверы обслуживают домен.

---

SPF: как настроить разрешённых отправителей

SPF (Sender Policy Framework) — механизм, который позволяет владельцу домена указать, какие серверы имеют право отправлять почту от его имени.

Например:

example.ru
    ↓
SPF
    ↓
разрешённые серверы
    ↓
сервис email-рассылок

SPF обычно создаётся как TXT-запись.

Условный пример:

Тип: TXT
Имя: @
Значение: v=spf1 include:spf.example-mail.ru ~all

Но конкретное значение нужно брать из инструкции вашего сервиса рассылок. Не следует копировать SPF другого сервиса.

Самая распространённая ошибка — две SPF-записи

Если домен уже использует SPF, нельзя просто создать вторую запись:

v=spf1 include:service1.ru ~all

и отдельно:

v=spf1 include:service2.ru ~all

SPF-политику необходимо объединить.

Например:

v=spf1 include:service1.ru include:service2.ru ~all

Почему это важно

У одного домена может быть несколько легитимных отправителей:

• корпоративная почта;
• сервис email-рассылок;
• CRM;
• интернет-магазин;
• сервис транзакционных писем.

SPF должен учитывать все системы, которым разрешено отправлять почту от имени домена.

---

DKIM: как добавить электронную подпись

DKIM (DomainKeys Identified Mail) — технология криптографической подписи исходящих писем.

Она позволяет принимающему серверу проверить:

1. что письмо действительно подписано уполномоченной системой;
2. что содержимое письма не было изменено после подписания;
3. какой домен связан с подписью.

Принцип работы следующий:

Сервис рассылок
      │
      │ приватный ключ
      ↓
Подписывает письмо
      │
      ↓
Получатель
      │
      │ публичный ключ из DNS
      ↓
Проверяет DKIM

Приватный ключ остаётся у сервиса рассылок. В DNS публикуется соответствующий публичный ключ.

---

Как выглядит DKIM-запись

Сервис может попросить создать, например, такую запись:

Тип: TXT
Имя: selector._domainkey
Значение: v=DKIM1; k=rsa; p=MIIBIjANBgkqh...

Здесь:

• selector — селектор DKIM;
• _domainkey — стандартная часть имени;
• p= — публичный ключ.

Иногда сервис вместо TXT предлагает использовать CNAME:

Тип: CNAME
Имя: selector._domainkey
Значение: selector.provider.example

В этом случае нужно использовать именно тот тип записи, который указал сервис.

---

Что такое DKIM-селектор

Селектор позволяет использовать несколько DKIM-ключей для одного домена.

Например:

selector1._domainkey.example.ru
selector2._domainkey.example.ru

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

• корпоративная почта;
• сервис рассылок;
• CRM;
• отдельная транзакционная система.

Поэтому при ручной проверке DKIM важно знать точное имя selector, которое использует отправляющий сервис.

---

DMARC: защита домена от подделки

DMARC (Domain-based Message Authentication, Reporting and Conformance) связывает SPF и DKIM и позволяет владельцу домена сообщить почтовым системам, что делать с письмами, которые не проходят проверку.

DMARC также позволяет получать отчёты о попытках отправки писем от имени вашего домена.

Запись создаётся в DNS как TXT:

Имя:
_dmarc.example.ru

Тип:
TXT

Значение:
v=DMARC1; p=none

Самая простая политика:

v=DMARC1; p=none

означает: не блокировать письма, а только применять мониторинг согласно остальным параметрам политики.

Для получения агрегированных отчётов можно добавить:

v=DMARC1; p=none; rua=mailto:dmarc@example.ru

Что означают p=none, quarantine и reject

У DMARC есть три основные политики.

p=none

v=DMARC1; p=none

Режим мониторинга.

Подходит для первоначальной настройки, когда вы ещё хотите убедиться, что все легитимные источники отправки правильно настроены.

p=quarantine

v=DMARC1; p=quarantine

Сообщения, не прошедшие необходимые проверки, предлагается помещать в спам или другой карантин.

p=reject

v=DMARC1; p=reject

Сообщения, не соответствующие политике DMARC, должны отклоняться.

Не стоит без проверки сразу устанавливать p=reject.

Сначала нужно убедиться, что вы учли все реальные источники отправки: почту сотрудников, CRM, сайт, сервис рассылок, транзакционные письма и другие системы.

---

Что такое DMARC alignment

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

Представим письмо:

From: news@example.ru

При этом технический Return-Path может принадлежать другому домену:

Return-Path: bounce@mail-service.ru

SPF может пройти:

SPF: PASS

но это само по себе ещё не гарантирует прохождение DMARC.

DMARC проверяет соответствие домена отправителя результатам SPF и/или DKIM.

Поэтому важен alignment — согласованность доменов.

Упрощённо:

From
example.ru
   │
   ├── DKIM → example.ru
   │
   └── SPF → согласованный домен

Для массовых отправителей Google требует, чтобы домен в From: был согласован с SPF или DKIM для прохождения DMARC. (Справка Google)

---

Нужна ли MX-запись для email-рассылки

Здесь часто возникает путаница.

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

Поэтому нельзя утверждать, что MX всегда необходим именно для отправки рассылок.

Но конкретный сервис может требовать MX в своей инфраструктуре.

Например, Яндекс Рассылки указывает MX среди требований к подтверждённому почтовому домену. (Яндекс)

Кроме того, сервисы email-маркетинга могут использовать отдельный MX для Return-Path.

Поэтому правильный подход простой:

Добавляйте MX в соответствии с требованиями используемого почтового или email-маркетингового сервиса и не меняйте существующие MX без понимания, какую почту они обслуживают.

---

Return-Path и bounce-домен

У письма есть не только адрес, который пользователь видит в поле «От кого».

Существует также технический адрес Return-Path, используемый для обработки служебных сообщений, в том числе:

• bounce;
• уведомлений о недоставке;
• некоторых технических ответов;
• жалоб на спам.

Сервис рассылок может предоставить отдельный поддомен:

bounce.example.ru

или:

mail.example.ru

для этой инфраструктуры.

---

Зачем нужен отдельный поддомен для рассылок

Для бизнеса часто удобно разделить обычную почту и маркетинговые отправки.

Например:

example.ru

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

ivan@example.ru
manager@example.ru

а отдельный поддомен:

news.example.ru

используется для рассылок:

hello@news.example.ru

Это позволяет структурировать почтовую инфраструктуру и отделить маркетинговую отправку от основной корпоративной почты.

Но важно понимать: сам по себе поддомен не гарантирует хорошую доставляемость. Репутация всё равно зависит от поведения отправителя, качества базы, количества жалоб, bounce rate и других факторов.

---

CNAME: зачем сервис рассылок просит его добавить

CNAME — ещё одна DNS-запись, которую можно встретить в инструкции сервиса.

Она позволяет связать имя вашего домена с инфраструктурой сервиса.

CNAME может использоваться, например, для:

• DKIM;
• tracking domain;
• отслеживания переходов;
• Return-Path;
• других технических функций.

Пример:

Тип: CNAME
Имя: click.example.ru
Значение: tracking.mail-service.ru

Важно точно соблюдать инструкцию сервиса.

Если DNS-панель автоматически дописывает домен к имени записи, не нужно вводить полный адрес второй раз. Например, вместо:

selector._domainkey.example.ru.example.ru

должно получиться:

selector._domainkey.example.ru

---

Как настроить домен для рассылки пошагово

Теперь соберём всё в практический алгоритм.

Шаг 1. Выберите домен отправителя

Определите, с какого адреса будут уходить письма:

marketing@example.ru

или, например:

marketing@news.example.ru

---

Шаг 2. Определите, где управляется DNS

Найдите панель управления DNS домена.

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

---

Шаг 3. Проверьте существующий SPF

Не создавайте новый SPF, пока не убедились, что его нет.

Если существующая запись выглядит так:

v=spf1 include:_spf.google.com ~all

а сервис рассылок требует:

include:spf.mail-service.ru

итоговая запись может выглядеть так:

v=spf1 include:_spf.google.com include:spf.mail-service.ru ~all

Конкретные значения должны соответствовать вашим сервисам.

---

Шаг 4. Добавьте DKIM

В кабинете сервиса найдите раздел вроде:

Настройки → Домен → DKIM

Сервис предоставит:

• имя записи;
• тип записи;
• значение.

Добавьте их в DNS без изменений.

---

Шаг 5. Добавьте DMARC

Для первоначального контроля можно использовать:

v=DMARC1; p=none

или вариант с агрегированными отчётами:

v=DMARC1; p=none; rua=mailto:dmarc@example.ru

После анализа трафика и исправления ошибок политику можно ужесточить.

---

Шаг 6. Настройте Return-Path, если его предоставляет сервис

Если сервис предлагает выделенный технический поддомен, он может потребовать:

• MX;
• SPF;
• CNAME;
• другие DNS-записи.

---

Шаг 7. Добавьте CNAME для tracking, если требуется

Если сервис предоставляет CNAME для домена ссылок или других функций, добавьте его в DNS.

---

Шаг 8. Дождитесь обновления DNS

DNS-записи не всегда становятся доступными мгновенно.

---

Как проверить, что SPF, DKIM и DMARC работают

Проверить наличие записей можно через DNS-инструменты, но окончательную проверку лучше проводить на реальном тестовом письме.

Отправьте письмо на тестовый адрес Gmail или другой почтовый сервис.

Откройте исходные заголовки письма.

Ищите результаты примерно такого вида:

SPF: PASS
DKIM: PASS
DMARC: PASS

Также обращайте внимание на домен DKIM:

dkim=pass
header.d=example.ru

и домен Return-Path.

---

Почему DNS-запись есть, а сервис говорит, что её нет

Это довольно распространённая ситуация.

Возможные причины:

1. DNS ещё не обновился

Подождите некоторое время.

2. Запись добавлена не туда

Например, домен использует DNS Cloudflare, а запись добавили в панели регистратора, которая фактически не является авторитетной DNS-зоной.

3. Неправильное имя записи

Например:

selector._domainkey.example.ru.example.ru

вместо:

selector._domainkey.example.ru

4. Ошибка в значении

Даже один лишний символ в DKIM-ключе может привести к ошибке.

5. Создано несколько SPF-записей

Вместо одной объединённой SPF-политики опубликованы две.

6. DNS работает нестабильно

Если запись то появляется, то исчезает, проблему следует искать у DNS-провайдера.

---

Почему SPF = PASS ещё не означает, что всё настроено

SPF проверяет авторизацию отправляющего сервера.

Но для DMARC важна ещё и согласованность доменов.

Поэтому ситуация:

SPF = PASS
DKIM = FAIL
DMARC = FAIL

вполне возможна.

И наоборот:

SPF = FAIL
DKIM = PASS
DMARC = PASS

тоже возможна, если DKIM проходит проверку и соответствует домену отправителя.

Именно поэтому при диагностике нельзя ограничиваться только SPF.

---

Что делать, если SPF, DKIM и DMARC настроены, но письма попадают в спам

DNS-аутентификация — только одна часть deliverability.

Даже при:

SPF = PASS
DKIM = PASS
DMARC = PASS

письмо может оказаться в спаме.

Почтовые системы учитывают:

• репутацию домена;
• репутацию IP;
• историю отправок;
• количество жалоб на спам;
• bounce rate;
• качество базы;
• активность получателей;
• содержание писем;
• ссылки и домены, используемые в письме;
• резкие изменения объёма отправки.

Поэтому после технической настройки необходимо работать и с репутацией отправителя.

---

Прогрев нового домена

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

Например, неправильный сценарий:

Новый домен
    ↓
0 писем
    ↓
100 000 писем за один день

Лучше постепенно увеличивать объём отправки и начинать с аудитории, которая наиболее активно взаимодействует с письмами.

---

Отписка от рассылки: почему это тоже часть технической настройки

Для маркетинговых писем одной DNS-аутентификации недостаточно.

У получателя должна быть понятная возможность отказаться от дальнейших сообщений.

Для массовых рассылок используется заголовок:

List-Unsubscribe

и, где требуется, механизм one-click unsubscribe.

Яндекс в актуальных требованиях к массовым отправкам отдельно указывает list-unsubscribe и возможность оперативной отписки получателя. (Яндекс)

Google также включает простую отписку в требования к массовым отправителям. (Справка Google)

---

Что такое BIMI

BIMI (Brand Indicators for Message Identification) — дополнительная технология, которая позволяет отображать логотип бренда рядом с письмами в поддерживаемых почтовых сервисах.

BIMI не заменяет SPF, DKIM или DMARC.

Логика должна быть такой:

SPF
+
DKIM
+
DMARC
        ↓
надёжная аутентификация
        ↓
BIMI
        ↓
визуальная идентификация бренда

Поэтому BIMI имеет смысл настраивать после того, как базовая email-аутентификация уже работает.

---

Частые ошибки при настройке домена

Ошибка №1. Создать два SPF

Неправильно:

v=spf1 include:service1.ru ~all
v=spf1 include:service2.ru ~all

Правильно:

v=spf1 include:service1.ru include:service2.ru ~all

---

Ошибка №2. Скопировать DKIM другого домена

DKIM-ключ генерируется для конкретной почтовой инфраструктуры.

Используйте ключ, который предоставил ваш сервис.

---

Ошибка №3. Сразу включить p=reject

Сначала убедитесь, что все легитимные письма проходят аутентификацию.

Иначе DMARC может начать блокировать ваши собственные письма.

---

Ошибка №4. Изменить MX, не понимая последствий

MX отвечает за входящую почту.

Если домен уже используется для корпоративной почты, изменение MX может нарушить её получение.

---

Ошибка №5. Добавить DNS-записи не в ту панель

У домена может быть несколько панелей, связанных с хостингом, сайтом и регистрацией.

Добавлять записи нужно в авторитетную DNS-зону.

---

Ошибка №6. Проверить только DNS, но не письмо

Наличие DKIM-записи в DNS ещё не означает, что ваш сервис действительно подписывает письма правильным ключом.

Всегда отправляйте тестовое письмо и проверяйте Authentication-Results.

---

Нужно ли настраивать SPF, DKIM и DMARC для рассылки

Да.

Для профессиональной email-рассылки правильная базовая конфигурация выглядит так:

Домен
  │
  ├── SPF
  │
  ├── DKIM
  │
  └── DMARC
       │
       └── alignment

А в зависимости от используемого сервиса добавляются:

CNAME
MX
Return-Path
tracking domain

И поверх технической инфраструктуры необходимо обеспечить:

корректную базу
      ↓
минимум жалоб
      ↓
низкий bounce rate
      ↓
постепенный рост объёма
      ↓
репутация домена
      ↓
хорошая доставляемость

Google в актуальных рекомендациях для отправителей также делает акцент на аутентификации домена, DNS, репутации и соблюдении требований к массовым отправкам. (Справка Google)

---

Чек-лист перед первой рассылкой

Перед запуском рассылки проверьте:

• DNS домена доступен для редактирования.
• Определён основной домен отправителя.
• Проверена существующая SPF-запись.
• SPF не дублируется.
• В SPF добавлен используемый сервис рассылок.
• Настроен DKIM.
• DKIM использует ключ, предоставленный сервисом.
• Настроен DMARC.
• Проверен DMARC alignment.
• Настроен Return-Path, если его предоставляет сервис.
• Добавлены необходимые CNAME.
• Проверены MX-записи.
• Отправлено тестовое письмо.
• SPF = PASS.
• DKIM = PASS.
• DMARC = PASS.
• Проверен домен в header.d.
• Проверен Return-Path.
• В рассылке работает отписка.
• Настроен List-Unsubscribe, если он необходим для типа отправки.
• Для нового домена предусмотрен прогрев.
• Перед массовой отправкой проверены база и репутация.

Итог

Настройка домена для email-рассылки — это не просто добавление одной записи DKIM.

Минимальная современная схема выглядит так:

SPF определяет, кто может отправлять письма от имени домена.

DKIM подписывает письма и позволяет проверить их подлинность.

DMARC определяет правила обработки сообщений, не прошедших аутентификацию, и помогает контролировать попытки подделки домена.

Return-Path используется для технической обработки недоставленных сообщений и других служебных ответов.

CNAME и MX могут потребоваться для отдельных элементов почтовой инфраструктуры.

А List-Unsubscribe, репутация домена, качество базы и корректная частота отправок непосредственно влияют на доставляемость.

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

DNS → SPF → DKIM → DMARC → alignment → Return-Path → проверка тестового письма → отписка → прогрев → массовая отправка.