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

Почта на домене это когда адрес компании выглядит как hi@ваша-компания.ru, а не как ваша-компания@mail.ru. С точки зрения клиента разница в доверии. С точки зрения владельца разница в том, что почта на своём домене требует настройки, и если её не сделать до конца, письма с домена и с формы на сайте начинают исчезать: они либо не уходят, либо падают в спам, либо уходят, но не туда.

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

Как всё начиналось: почта у регистратора#

Когда регистрируешь домен, регистратор почти всегда предлагает почту в довесок. Так было и у нас: ящик hi@ на домене жил на почтовом сервере регистратора несколько лет. Работало, писем немного, никто не жаловался.

Проблемы такой схемы не видны, пока не начинаешь считать. Первая: ящик привязан к регистратору, и если домен когда-нибудь переедет, почту придётся переносить отдельно. Вторая: настройки доставляемости у таких почт минимальные, обычно только MX-запись, которую регистратор прописал сам. Третья, и она выстрелила: письма с сайта, то есть уведомления о заявках, шли совсем другим путём, и никто не сверял, доходят ли они вообще.

Для большинства компаний с одним-тремя ящиками я бы сейчас советовал не регистратора и не свой сервер, а готовый почтовый сервис: Яндекс 360 для бизнеса или VK WorkSpace. Там подтверждение домена, все записи и антиспам собраны в один мастер настройки. Но мы держим свой сервер для сайтов и ботов, и почту решили увести туда же, чтобы всё лежало в одном месте.

Переезд: 54 секунды на 373 письма#

Переезд ящика между серверами звучит страшно и занимает минуту. Пятнадцатого июля 2026 года мы перенесли hi@ с сервера регистратора на свой почтовый сервер утилитой, которая синхронизирует два ящика по IMAP. Итог из лога: 373 письма, 59,6 мегабайта, 54 секунды, ноль ошибок, три дубликата пропущены.

Сама миграция не проблема. Проблема в том, что происходит после: нужно переключить MX-запись домена на новый сервер, и с этого момента входящие письма идут туда. А исходящие письма и письма с сайта продолжают жить своей жизнью, о которой домен ничего не знает. Именно здесь начинается настоящая работа, и именно её пропускают.

Три записи, без которых почта на домене не почта#

Любой почтовый сервис при подключении домена выдаст список записей для DNS. Разберу на примере Яндекс 360 для бизнеса, потому что его справка самая подробная, но у других сервисов логика та же.

Значения первых трёх взяты из справки Яндекс 360 по состоянию на август 2026 года. Там же написано, что изменения расходятся по DNS до 72 часов, а если домен делегирован на серверы Яндекса, SPF и DKIM настроятся сами.

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

Почему это не формальность. В требованиях Яндекса к честным рассылкам DKIM-подпись и SPF-запись стоят с пометкой "обязательно", DMARC с пометкой "рекомендуется", и там же сказано прямо: Яндекс Почта оставляет за собой право отправлять в спам или не принимать совсем письма, которые обязательным пунктам не соответствуют. Формально документ про рассылки, но фильтр один и тот же для всех писем с домена.

Что мы нашли в своём DNS, когда наконец посмотрели#

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

SPF-запись на месте, но в ней хвост. Помимо нашего сервера, в списке доверенных до сих пор стоял почтовый сервер регистратора, с которого мы съехали, и сервис рассылок, которым пользовались пару лет назад. Это значит, что любой, кто получит доступ к ящику на том старом сервере, может слать письма от нашего имени, и проверка SPF их пропустит. Лишние включения в SPF это не мусор, это дыра.

Старые ключи в связке: лишние сервера в SPF-записи домена

DMARC-запись есть, но в режиме p=none, то есть только наблюдение: не прошедшие проверку письма всё равно доставляются, а нам приходят отчёты. Для старта это правильно, дальше нужно переводить в карантин. Мы застряли на старте.

Что дают отчёты DMARC, ради которых режим наблюдения и включают. Раз в сутки почтовики, принявшие письма от вашего домена, присылают на указанный адрес сводку: с каких IP-адресов шли письма, сколько прошло SPF и DKIM, сколько нет. Читать их в сыром виде неудобно, это XML в архиве, но есть бесплатные сервисы, которые собирают сводки в таблицу. Через две недели наблюдения в таблице видно всё: свой сервер, сервис отправки с сайта, сервис рассылок и, если повезёт, чужой сервер, который шлёт от вашего имени. Пока в списке есть что-то незнакомое, ужесточать правило нельзя, иначе отвалятся и свои письма.

DKIM для основного домена по стандартным селекторам не нашёлся вовсе. Значит, письма с нашего сервера уходили без подписи, и попадание во Входящие зависело от репутации IP-адреса и настроения фильтра.

Письма с сайта: отдельная история#

Здесь у нас была самая неприятная находка, и она же самая типичная.

Заявки с сайта отправляются не почтовым сервером, а сервисом транзакционной почты: сайт дёргает его по API, сервис шлёт письмо. Так делают почти все современные сайты, и это правильно, потому что сервер сайта не должен заниматься почтой. Но у сервиса есть условие: домен, от имени которого он шлёт, нужно подтвердить теми же записями SPF и DKIM. Пока домен не подтверждён, сервис работает в тестовом режиме и доставляет письма только на адрес владельца аккаунта.

Так у нас и было. Уведомление о заявке приходило на личный адрес, а копия на hi@ отбивалась с ошибкой доступа, и в логе сайта при этом стояло "письмо отправлено", потому что сервис принял запрос. Заявки не терялись, они шли ещё и в Телеграм, но почтовый канал молча не работал.

Отсюда правило, которое я теперь проговариваю на каждом запуске сайта: у письма с формы три точки, где оно может умереть, и проверять нужно все три. Лог сайта показывает, что запрос на отправку ушёл. Лог сервиса отправки показывает, что письмо принято и доставлено, а не отклонено. Папка Спам у получателя показывает, куда оно легло. "У нас в логе всё ок" это ответ только на первый вопрос из трёх.

Три точки, где письмо с сайта может потеряться: лог сайта, сервис отправки, папка Спам

Вторая ловушка того же рода. Если сайт отправляет письма сам, со своего сервера, а сервер не вписан в SPF домена, письма формально идут от домена, которому этот сервер не доверен. У Яндекса и Mail.ru такие письма первые кандидаты в спам. Особенно это касается сайтов на хостинге, где форма шлёт через функцию отправки почты самого сервера: адрес хостинга в SPF есть, а вот подписи DKIM нет почти никогда.

Почему письма попадают в спам, если записи в порядке#

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

Получатели жаловались. В Яндекс Почте фильтр учится на кнопке "Это спам!", причём справка уточняет, что нужно несколько жалоб на однотипные письма, и что все письма одного отправителя, отправленные в спам разом, считаются одной жалобой. Если вы рассылали что-то без явного согласия, несколько нажатий на кнопку у разных людей, и домен помечен.

Обратный DNS у сервера не настроен. В требованиях к честным рассылкам это обязательный пункт: у отправляющего хоста должен быть постоянный IP-адрес с корректной обратной записью. На своём сервере это одна строка в панели хостинга, о которой не знают.

Письмо похоже на рассылку, но не оформлено как рассылка. Для массовых писем Яндекс требует заголовок отписки и стандартные служебные заголовки, а рекламные письма советует слать с отдельного домена или поддомена, не с того, с которого идёт переписка. Уведомления о заявках и переписка с клиентами на этот раздел не попадают, но если с того же hi@ раз в месяц уходит акция на всю базу, репутация домена одна на всё.

Письмо в спаме удаляется через 10 дней. Это тоже из справки Яндекса и это ответ на вопрос "почему клиент не нашёл письмо, когда я сказал посмотреть в спаме": прошло больше десяти дней.

Что мы сделали и что советуем делать вам#

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

1. Решить, где живёт почта: сервис вроде Яндекс 360 или свой сервер. Для компании без администратора первое.
2. Подтвердить домен в сервисе и прописать MX, SPF, DKIM по его инструкции. Подождать до 72 часов, проверить статус в кабинете.
3. Почистить SPF: в нём должны быть только те, кто реально шлёт письма сейчас. Старый регистратор, старый сервис рассылок, старый хостинг из записи убрать.
4. Добавить DMARC в режиме наблюдения с адресом для отчётов. Через две-четыре недели, когда в отчётах только свои сервера, перевести в карантин.
5. Подтвердить домен в сервисе транзакционной почты, через который шлёт сайт, и отправить тестовую заявку на три адреса: Яндекс, Mail.ru, Gmail. Проверить папку Спам во всех трёх.
6. Настроить обратный DNS на своём сервере, если почта на нём.
7. Раз в квартал повторять шаги 3 и 5. Сервисы меняются, записи остаются.

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

Про свой сервер скажу честно. Он у нас есть, почта на нём работает, но требует внимания: обновления, спам-фильтр, репутация IP-адреса, который делит с сайтами. Компании, где нет человека, который раз в месяц заглянет в логи, я бы на свой сервер почту не ставил. Разница в цене между сервисом и самообслуживанием заметно меньше, чем цена одной потерянной заявки.

Если почта и уведомления с сайта у вас настроены давно и "вроде работают", это как раз тот случай, который стоит проверить. Мы делаем это в рамках поддержки сайта: снимаем записи домена, прогоняем тестовые письма по трём почтовикам и сверяем логи. Обычно находится минимум одна из трёх проблем, описанных выше, и чаще всего это хвост в SPF. А если сайт только запускается, проверка доставляемости входит в базовый чек-лист рядом с SSL-сертификатом и Метрикой: без неё форма заявки существует, но не работает.