Письма с вашего домена
Бот может писать вашим клиентам по электронной почте — с адреса на вашем домене, вроде noreply@example.com. Само письмо при этом отправляет наш сервер. Из-за этого перед первой отправкой нужно один раз добавить три записи в DNS вашего домена. Ниже — зачем это нужно, что именно добавить и что происходит дальше.
Почему без DNS-записей письма не дойдут
Посмотрите на ситуацию глазами принимающей стороны — Gmail, Яндекс 360, Mail.ru или почтового сервера вашего клиента. К ним приходит письмо, которое представляется письмом с вашего домена, но приходит с сервера, который вашему домену не принадлежит. Это ровно та же картина, что и подделка от вашего имени: именно так выглядит фишинг.
Отличить одно от другого получатель может единственным способом — спросить у самого домена: «этот отправитель действительно действует от вашего имени?» Ответ вы публикуете в DNS своего домена: DNS — единственное место, которым распоряжаетесь только вы, и потому единственное, чему получатель верит.
Пока ответа нет, добросовестный почтовый сервер обязан считать письмо подозрительным. В лучшем случае оно уедет в «Спам», в худшем — будет отклонено, и получатель о нём никогда не узнает.
Поэтому три записи ниже — не формальность и не галочка в интерфейсе. Это и есть ваше разрешение.
Три записи и что делает каждая
DKIM — подпись, доказывающая подлинность
DKIM — криптографическая подпись, которой помечается каждое исходящее письмо. Платформа генерирует для вашего домена пару ключей: закрытый остаётся у нас и подписывает письма, открытый вы публикуете в DNS. Получатель берёт открытый ключ из вашего DNS и проверяет подпись. Сошлась — значит, письмо отправил тот, у кого есть закрытый ключ, и текст письма не подменили по дороге.
Чего не будет без DKIM: проверять подпись будет нечем. Письмо выглядит неподписанным, доверия к нему нет, и никакие остальные настройки этого не компенсируют. DKIM — самая важная из трёх записей.
SPF — список серверов, которым можно отправлять от вашего имени
SPF отвечает на другой вопрос: «с каких серверов вообще допустимы письма от этого домена». Это список источников — почтовые серверы вашего хостинга, сервисы рассылок, которыми вы уже пользуетесь, и, чтобы бот мог писать, наши серверы отправки.
Чего не будет без SPF: письмо приходит с сервера, которого ваш домен «не знает». Для фильтра это классический признак подделки, и он суммируется со всеми остальными подозрениями.
DMARC — что делать получателю, если проверки не прошли
DKIM и SPF отвечают на вопрос «настоящее ли письмо». DMARC отвечает на следующий: что делать, если нет. Это ваше указание получателю — ничего не делать и только прислать отчёт, отправить в спам или отклонить. Заодно DMARC — это адрес, на который получатели шлют сводные отчёты о почте от вашего имени, включая чужие попытки подделки.
Мы предлагаем начинать с самой мягкой политики — «только отчёты». Ужесточать её стоит позже, когда вы убедились, что все ваши настоящие отправители (бухгалтерия, CRM, рассылки, этот бот) проверки проходят. Строгая политика, включённая раньше времени, начинает резать вашу же собственную почту.
Чего не будет без DMARC: каждый получатель решает по-своему, а вы не узнаете, что происходит с почтой от вашего имени.
Какие записи добавить
Сначала заведите домен в кабинете: раздел Email → «Домены отправки» → кнопка «Добавить домен». В диалоге три поля: сам домен (например shop.example.com), локальная часть адреса (часть до @, обычно noreply) и имя отправителя — то, что получатель увидит вместо адреса. После сохранения на экране появятся ваши DNS-записи.
Все три — записи типа 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 — это ссылка на наш собственный, поддерживаемый нами список серверов отправки. Сегодня за этим именем стоит один сервер. Завтра их может стать больше, они могут переехать или смениться. Когда это произойдёт, мы обновим список у себя — и ваша запись продолжит работать, ничего трогать не придётся. В этом весь смысл: адрес меняется в одном месте, а не в 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.