Письма с вашего домена
Какой тариф нужен для email, зачем почте DNS-записи DKIM, SPF и DMARC, какие три записи добавить, почему в SPF нужен include, как проходит проверка домена, отписки, отказы доставки и статистика открытий.
На этой странице
Бот может писать вашим клиентам по электронной почте: с адреса на вашем домене, вроде noreply@example.com. Само письмо при этом отправляет наш сервер. Из-за этого перед первой отправкой нужно один раз добавить три записи в DNS вашего домена. Ниже: зачем это нужно, что именно добавить и что происходит дальше.
Сначала: тариф
Email доступен на платных тарифах конструктора ботов «Про», «Бизнес» и Enterprise. На бесплатном тарифе «Старт» и на всех тарифах линейки «Коммуникации с клиентами» его нет. См. Тарифы.
Проверьте тариф до того, как заходить в DNS. На тарифе без email закрыт весь раздел: домен отправки не добавляется, любой запрос отвечает 402. Записи SPF, DKIM и DMARC при этом настроить можно, они просто останутся никому не нужны: платформа не начнёт отправлять письма от того, что они появились.
Почему без DNS-записей письма не дойдут
Посмотрите на ситуацию глазами принимающей стороны: Gmail, Яндекс 360, Mail.ru или почтового сервера вашего клиента. К ним приходит письмо, которое представляется письмом с вашего домена, но приходит с сервера, который вашему домену не принадлежит. Это ровно та же картина, что и подделка от вашего имени: именно так выглядит фишинг.
Получатель может отличить разрешённую отправку от подделки, только проверив записи вашего домена. Ответ вы публикуете в DNS домена, которым управляете только вы. Именно этим записям доверяет почтовый сервер получателя.
Пока ответа нет, добросовестный почтовый сервер обязан считать письмо подозрительным. В лучшем случае оно попадёт в «Спам», в худшем будет отклонено, и получатель о нём никогда не узнает.
Три записи ниже подтверждают ваше разрешение отправлять письма с домена.
Три записи и что делает каждая
DKIM: подпись, доказывающая подлинность
DKIM добавляет к каждому исходящему письму криптографическую подпись. Платформа генерирует для вашего домена пару ключей: закрытый остаётся у нас и подписывает письма, открытый вы публикуете в DNS. Получатель берёт открытый ключ из DNS и проверяет подпись. Если она сошлась, письмо отправил владелец закрытого ключа, а текст письма не подменили по дороге.
Без DKIM проверять подпись будет нечем. Письмо выглядит неподписанным, доверия к нему нет, и никакие остальные настройки этого не компенсируют. Из трёх записей DKIM важнее всего.
SPF: список серверов, которым можно отправлять от вашего имени
SPF отвечает на другой вопрос: «с каких серверов вообще допустимы письма от этого домена». Это список источников: почтовые серверы вашего хостинга, сервисы рассылок, которыми вы уже пользуетесь, и, чтобы бот мог писать, наши серверы отправки.
Чего не будет без SPF: письмо приходит с сервера, которого ваш домен «не знает». Для фильтра это классический признак подделки, и он суммируется со всеми остальными подозрениями.
DMARC: что делать получателю, если проверки не прошли
DKIM и SPF помогают определить, настоящее ли письмо. DMARC указывает получателю, что делать, если проверки не прошли: только прислать отчёт, отправить письмо в спам или отклонить его. В записи DMARC также указан адрес для сводных отчётов о почте от вашего имени, включая чужие попытки подделки.
Мы предлагаем начинать с самой мягкой политики: «только отчёты». Ужесточать её стоит позже, когда вы убедились, что все ваши настоящие отправители (бухгалтерия, CRM, рассылки, этот бот) проверки проходят. Строгая политика, включённая раньше времени, начинает резать вашу же собственную почту.
Чего не будет без DMARC: каждый получатель решает по-своему, а вы не узнаете, что происходит с почтой от вашего имени.
Какие записи добавить
Сначала заведите домен в кабинете: раздел Email → «Домены отправки» → кнопка «Добавить домен». В диалоге три поля: сам домен (например shop.example.com), локальная часть адреса (часть до @, обычно noreply) и имя отправителя: то, что получатель увидит вместо адреса. После сохранения на экране появятся ваши DNS-записи.
Оба поля адреса проверяются при сохранении, и проверка строже привычной почтовой:
- Домен приводится к нижнему регистру и должен быть полным именем хотя бы из двух частей (
example.com,mail.example.com), не длиннее 253 символов. Каждая часть: латинские буквы, цифры и дефис, причём начинаться и заканчиваться она обязана буквой или цифрой:-mail.example.comиmail-.example.comне примут. Международные домены записывайте в punycode (xn--…). - Локальная часть приводится к нижнему регистру, не длиннее 64 символов, состоит из латинских букв, цифр и знаков
.,_,+,-, а начинаться и заканчиваться обязана буквой или цифрой. То естьnoreply,no-replyиnews.2026подойдут, аnoreply-,.noreplyиno..reply-: нет (последний символ не буква и не цифра). - Переводы строки и другие управляющие символы запрещены в обоих полях. Через них можно было бы подставить в письмо лишние служебные заголовки, а письмо это подписывается ключом вашего домена: то есть вашим именем.
Адрес, который эти правила не проходит, отклоняется с 400 при сохранении домена: раньше, чем что-либо будет отправлено. Правила для входящих адресов немного другие, они описаны в разделе Email-рассылки.
Все три записи имеют тип TXT и добавляются в DNS вашего домена. Сделать это можно в панели регистратора или DNS-провайдера.
Значения ниже показаны на примере домена example.com: подставьте свой. Точные значения для вашего домена показаны в кабинете на карточке домена: копируйте их оттуда, особенно DKIM: его значение содержит ваш собственный открытый ключ, у каждого домена он свой, и из документации его взять нельзя.
Каждая запись на экране разбита на два отдельных поля: «Хост» и «Значение», у каждого своя кнопка «Скопировать». Копируйте их по одному в соответствующие поля панели вашего DNS-провайдера: одним куском эти две части не вставляются.
| Тип | Имя записи (host) | Значение |
|---|---|---|
| TXT | mybot._domainkey.example.com | v=DKIM1; k=rsa; p= и следом длинный ключ из кабинета |
| TXT | example.com (корень домена) | v=spf1 include:esp.getmybot.dev ~all |
| TXT | _dmarc.example.com | v=DMARC1; p=none; rua=mailto:dmarc@example.com |
Две вещи, на которых спотыкаются чаще всего:
- Многие панели подставляют домен к имени записи сами. Если в поле имени уже написано «.example.com», вводите только
mybot._domainkey, а не полное имя: иначе получитсяmybot._domainkey.example.com.example.com. - Значение DKIM длинное и не должно содержать переносов и пробелов внутри ключа. Копируйте его кнопкой, а не выделением мышью.
Если SPF-запись у домена уже есть
У домена может быть только одна SPF-запись. Если вы уже отправляете почту через хостинг, CRM или другой сервис рассылок, такая запись у вас есть. Не добавляйте вторую: допишите в существующую ещё один include, перед завершающим ~all:
v=spf1 include:spf.вашпровайдер.ru include:esp.getmybot.dev ~all
Две SPF-записи на домене так же мешают проверке, как отсутствие записи: получатель не знает, какой из них верить.
Важно: «покрытия» через чужую запись недостаточно. Даже если ваш нынешний провайдер сам включает нас в свой SPF, наш include должен стоять в вашей записи напрямую: почему именно так, см. ниже в разделе о проверке домена.
Почему в SPF именно include, а не IP-адрес
Самая частая ошибка: вписать в SPF IP-адрес, подсмотренный в заголовках письма или в чьей-то переписке. Так делать не надо.
include:esp.getmybot.dev ссылается на список наших серверов отправки. Сегодня за этим именем стоит один сервер. Если серверов станет больше, они переедут или сменятся, мы обновим свой список. Вашу SPF-запись менять не придётся: адрес обновится у нас, а не в DNS каждого клиента.
Прописанный руками IP-адрес в момент такой смены просто перестанет соответствовать действительности. Письма начнут проваливать SPF без всякого предупреждения: ни ошибки в кабинете, ни уведомления не будет, вы узнаете об этом от клиентов, которые «ничего не получали».
Укажите ровно include:esp.getmybot.dev без дополнительных символов.
Проверка домена
При проверке домена платформа читает его DNS-записи. Если все три прошли проверку, домен получает статус «Проверен» и отправка разрешается. Пока хотя бы одна запись не прошла проверку, домен остаётся в статусе ожидания.
Проверяется не просто «запись существует»:
| Запись | Что именно проверяется |
|---|---|
| DKIM | Запись опубликована и содержит именно ваш открытый ключ. Чужой или устаревший DKIM проверку не пройдёт. |
| SPF | Запись существует и напрямую содержит include:esp.getmybot.dev. Похожие значения вроде include:esp.getmybot.dev.чужой-домен не считаются. |
| DMARC | Запись опубликована и начинается с v=DMARC1. Сама политика (p=, rua=) не проверяется: это ваше решение, а не разрешение для нас. |
Почему DMARC проверяется мягче: он говорит получателям, как поступать с результатами DKIM и SPF, но не даёт нам права отправлять от вашего имени. Это право дают ровно две первые записи, и они проверяются по содержимому полностью.
Чужой include не засчитывается
include:esp.getmybot.dev должен стоять в вашей собственной SPF-записи. Если вы включили в SPF стороннего провайдера, а уже его запись включает нас, проверка это не засчитает: платформа не разворачивает цепочки чужих include. Причина простая: так ответ на вопрос «разрешил ли нам именно этот домен» остаётся однозначным.
Поэтому, даже если вы уверены, что «покрыты через провайдера», добавьте наш include прямо в свою запись. Об этом же говорит постоянная подсказка на экране: если SPF-запись у домена уже есть, добавьте в неё include:..., не заменяя запись целиком. Домен может отправлять почту и через другие сервисы.
DNS обновляется не мгновенно. После сохранения записей у регистратора они расходятся по серверам имён. Обычно это занимает минуты, иногда часы, изредка до суток. Срок зависит от провайдера и TTL записей, а не от нас.
Ждать пассивно не нужно. Платформа сама перепроверяет ожидающие домены раз в час, но на карточке домена есть кнопка «Проверить сейчас»: это та же самая проверка, запущенная немедленно, с результатом сразу на экране. Нажимайте её сразу после сохранения записей: если где-то опечатка, вы узнаете об этом через секунду, а не через час. Нажимать можно сколько угодно раз.
Статус домена виден на карточке: «Ожидает проверки», «Подтверждён» или «Не подтверждён». Пока домен не подтверждён, там же висит предупреждение «Отправка с этого домена отключена, пока он не подтверждён».
Для каждой из трёх записей экран показывает статус «Пройдено», «Не пройдено» или «Ещё не проверено» и отдельное объяснение результата.
Для SPF экран различает две ситуации, и это главное различие во всём процессе:
- SPF-записи у домена нет вообще. Опубликуйте её: значением из таблицы выше.
- SPF-запись есть, но нашего include в ней нет. Допишите include в существующую запись: не создавайте вторую и не заменяйте её целиком. Тот же текст отдельно оговаривает и цепочку: если include доходит до нас только через SPF-запись другого провайдера, это не засчитывается: цепочки не разворачиваются.
Во втором случае запись у вас уже есть, но проверка всё равно не проходит. Сообщение об ошибке и постоянная подсказка рядом с записью предлагают одно и то же: добавить наш include в существующую запись.
Если проверка не проходит:
- Посмотрите, какая из трёх записей получила «Не пройдено», и следуйте объяснению рядом с ней.
- Убедитесь, что записи действительно опубликованы. Во многих панелях нужно отдельно нажать «Применить изменения».
- Проверьте имя записи на удвоенный домен (см. выше).
- Проверьте, что SPF-запись на домене одна и что наш include стоит в ней самой.
- Подождите и нажмите проверку ещё раз: возможно, изменения просто ещё не разошлись.
До проверки отправка не работает: так задумано
Пока домен не проверен, письма не отправляются. Попытка завершается ошибкой о неподтверждённом домене, которую видно в журнале.
Это ограничение защищает общую отправляющую инфраструктуру платформы. Письма с неподтверждённого домена могут вызвать жалобы на спам и испортить её репутацию. Поэтому отправка запрещена до проверки, а не просто сопровождается предупреждением.
Если вы видите такую ошибку, сначала проверьте DNS-записи и нажмите проверку ещё раз. В подавляющем большинстве случаев причина в опечатке в имени записи.
Отписки, жалобы и отказы доставки
При отправке почты действуют три правила.
В каждом рекламном письме есть отписка в один клик. Платформа сама добавляет ссылку отписки в подвал письма и служебные заголовки, по которым почтовый клиент рисует кнопку «Отписаться» рядом с адресом отправителя. Убрать это нельзя: ни настройкой, ни вёрсткой письма. Отписка срабатывает сразу, без открытия письма и без подтверждения. Это требование Gmail и остальных крупных почтовых сервисов к массовым отправителям: письмо без такой возможности едет в спам гарантированно.
Отписка окончательна, и отменить её из интерфейса нельзя. Отписавшийся адрес больше не получает писем этого бота. Нет ни кнопки «вернуть», ни обходного пути через повторный импорт списка: отписка не отменяется в обход человека. Вернуться человек может только сам: снова оставив свой адрес в вашей форме подписки.
Из этого правила есть ещё более жёсткое исключение: если человек нажал в почтовом клиенте «Это спам», адрес закрывается насовсем. Его не откроет даже повторная подписка через форму: потому что мы уже знаем, чем закончилась прошлая попытка, и повторная рассылка на такой адрес быстрее всего прочего уничтожает репутацию домена. Так же ведут себя адреса, закрытые вручную по юридическому требованию.
Жёсткий отказ доставки навсегда исключает адрес. Если почтовый сервер получателя ответил, что такого ящика не существует, адрес помечается как недоставляемый и в дальнейшие отправки не попадает. Это не временный статус: повторные попытки отправки на несуществующий адрес могут привести к блокировке всех писем спам-фильтрами.
Временные отказы (переполненный ящик, недоступный сервер) адрес не закрывают: по ним отправка продолжается.
Почему «Открытия» в статистике занижены
В статистике почты есть показатель открытий, и он всегда меньше реального. Дело не в ошибке подсчёта, а в том, как открытия вообще измеряются.
Открытие фиксируется по картинке-пикселю, которую почтовый клиент загружает с сервера при показе письма. Современные почтовые клиенты по умолчанию не загружают внешние картинки. Другие, например Apple Mail с защитой приватности, загружают их заранее, в том числе для писем, которые человек так и не открыл. В первом случае открытие не учитывается, во втором учитывается лишнее. Ни у нас, ни у других отправителей нет способа точно посчитать открытия писем.
Поэтому в интерфейсе рядом с открытиями стоит оговорка: это нижняя граница, а не точное число. Пользуйтесь им, чтобы сравнивать письма между собой (одна и та же погрешность у всех), но не как ответом на вопрос «сколько людей прочитали письмо».
Если нужна более надёжная метрика вовлечённости, смотрите «Переходы по ссылкам»: клик фиксирует действие человека, которое почтовый клиент не выполняет заранее. «Доставлено», «Отписки», «Жалобы» и «Возвраты» тоже считаются точно, поскольку сведения о них приходят от почтовых серверов, а не от картинки в письме. Все показатели находятся в блоке «Статистика отправки» на экране Email.