Коротко: чтобы завести почту на своём домене, выберите способ — облачный сервис (Яндекс 360, VK WorkSpace) или собственный почтовый сервер, — подтвердите права на домен и добавьте в DNS четыре записи: MX, SPF, DKIM и DMARC. Настройка занимает от получаса до пары часов, у облачных сервисов есть бесплатные тарифы, а адрес вида info@ваш-домен.ru останется вашим при любой смене провайдера.

Что даёт почта на своём домене
Адрес info@company.ru выглядит убедительнее, чем company2020@gmail.com: получатель сразу видит, от кого письмо, а спам-фильтры больше доверяют домену с настроенной аутентификацией. Многие B2B-контрагенты и платёжные сервисы вовсе не работают с адресами на публичных доменах.
Главное — контроль: ящики создаёт и отключает администратор, уволившийся сотрудник не унесёт переписку на личный аккаунт. Домен принадлежит вам, поэтому провайдера можно сменить в любой момент — адреса сохранятся, поменяется только серверная часть.
Кроме того, только владелец домена настраивает SPF, DKIM и DMARC — механизмы, которые защищают от подделки отправителя и решают, попадут письма во «Входящие» или в спам.
Три способа создать почту на своём домене
Создать почту на своём домене можно тремя путями: подключить облачный сервис, взять корпоративную платформу или поднять собственный почтовый сервер. Различаются они ценой, трудозатратами и тем, где физически лежат письма.

Почта на своём домене через Яндекс 360
Самый быстрый вариант для рунета. Регистрируете организацию в Яндекс 360 для бизнеса, подтверждаете домен TXT-записью, меняете MX — и через час почта работает в привычном интерфейсе Яндекс Почты. SPF и DKIM сервис генерирует сам, остаётся добавить их в DNS. Инструкции по регистраторам — в официальной документации Яндекс 360.
VK WorkSpace
Корпоративная платформа VK (бывшая «Почта Mail.ru для бизнеса»). Схема та же: подтверждение домена, MX, SPF, DKIM. Плюс — календарь, документы и мессенджер в комплекте; вариант для команд, которым нужен офисный пакет от российского вендора и данные в дата-центрах РФ.
Свой почтовый сервер
Postfix + Dovecot на VPS дают полный контроль: свои лимиты, свои сроки хранения. Цена — ответственность за всё: обновления, бэкапы, антиспам, TLS и репутация IP-адреса. Если IP попадёт в чёрные списки, вытаскивать его придётся вам, а не поддержке провайдера.
| Критерий | Яндекс 360 | VK WorkSpace | Свой сервер |
|---|---|---|---|
| Цена | Бесплатный базовый тариф; платные — за пользователя в месяц | Бесплатный уровень для малых команд | VPS от сотен рублей в месяц плюс время администратора |
| Лимиты | Объём ящика зависит от тарифа | Лимиты хранилища на бесплатном уровне | Только диск и канал вашего сервера |
| Сложность | Низкая: мастер и готовые DNS-записи | Низкая: пошаговый мастер подключения | Высокая: установка, антиспам, мониторинг — всё на вас |
| Где данные | Дата-центры Яндекса (РФ) | Дата-центры VK (РФ) | Ваш сервер — в любой юрисдикции |
Совет: не поднимайте свой сервер «ради экономии». Пока сотрудников меньше пятидесяти, облачный тариф почти всегда дешевле, чем часы администратора на борьбу со спам-листами и мониторинг очереди Postfix.
Подтверждение домена: как доказать, что он ваш
Прежде чем принять почту вашего домена, провайдер требует доказать, что домен действительно под вашим контролем. Иначе любой желающий подключил бы к своему аккаунту чужой домен. Способ подтверждения выбираете вы — принимаются обычно четыре.
- TXT-запись в корне домена — самый частый и самый надёжный вариант: провайдер выдаёт строку, вы добавляете её в DNS.
- CNAME-запись на служебное имя провайдера — работает так же, но иногда конфликтует с уже существующими записями на том же имени.
- HTML-файл в корне сайта — удобно, когда доступ к DNS есть у подрядчика, а к сайту у вас. Файл нельзя удалять после подтверждения: провайдеры периодически перепроверяют.
- Делегирование домена на NS-серверы провайдера — самый радикальный путь: вся зона переезжает, и вместе с ней надо переносить все прочие записи.
Ошибки на этом шаге однотипны и стоят часа непонимания:
- Запись создалась в поддомене. Панели многих регистраторов подставляют домен автоматически, и введённое
example.ruпревращается вexample.ru.example.ru. Для корня в поле имени обычно ставят@или оставляют пустым. - Значение обрезано или искажено кавычками. Копируйте строку целиком и не добавляйте кавычки руками — панель проставит их сама.
- Проверку запустили раньше распространения. Запись появляется у резолверов не мгновенно; если TTL зоны был большой, ждать придётся дольше.
- Старая запись подтверждения от прежнего сервиса осталась в зоне и сбивает проверку. Записи закончившихся сервисов удаляйте.
# Убедиться, что запись подтверждения реально видна снаружи
dig example.ru TXT +short
dig _verification.example.ru TXT +short # если провайдер просит служебное имя
# Проверить, какой TTL у записей зоны — от него зависит, сколько ждать
dig example.ru TXT | grep -A1 'ANSWER SECTION'
Что домен видит из интернета, а не из вашей панели, покажет проверка DNS-записей; разброс между резолверами — проверка распространения.
Как сделать почту на своём домене: настройка DNS шаг за шагом
Какого бы провайдера вы ни выбрали, настройка сводится к четырём DNS-записям. Добавляются они в панели регистратора и применяются от нескольких минут до 24 часов. Состояние домена проверьте через DNS-чекер — он покажет, какие записи уже видны из интернета.

Шаг 1. MX — куда доставлять письма
MX-запись указывает сервер, принимающий почту домена; чем меньше число приоритета, тем раньше сервер пробуют. Для Яндекс 360 запись выглядит так:
example.ru. 3600 IN MX 10 mx.yandex.net.
Старые MX-записи удалите, иначе часть писем уйдёт на прежний сервер. Типичные ошибки разобраны в статье о настройке MX-записей.
Шаг 2. SPF — кто вправе отправлять
SPF перечисляет серверы, которым разрешено отправлять письма от имени домена. Публикуется как TXT-запись в корне:
example.ru. IN TXT "v=spf1 redirect=_spf.yandex.net" ; вариант для собственного сервера: example.ru. IN TXT "v=spf1 ip4:203.0.113.10 -all"
SPF-запись должна быть ровно одна: две и больше — ошибка валидации, письма начнут отклоняться.
Шаг 3. DKIM — криптографическая подпись
DKIM добавляет к каждому письму подпись, которую получатель сверяет с открытым ключом из DNS. Ключ генерирует провайдер (или opendkim на своём сервере):
mail._domainkey.example.ru. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB...AQAB"
Шаг 4. DMARC — политика для подделок
DMARC сообщает чужим серверам, что делать с письмами, не прошедшими SPF и DKIM, и присылает отчёты о попытках подделки домена:
_dmarc.example.ru. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.ru"
Совет: начинайте с политики p=none и две-три недели читайте отчёты. Когда все легитимные источники — CRM, сайт, рассыльщик — учтены в SPF и DKIM, ужесточайте политику до quarantine, затем до reject.
Отправка писем с сайта: где всё ломается
Почта сотрудников и письма, которые шлёт сам сайт, — две разные задачи, и вторую обычно забывают. Форма обратной связи, уведомления о заказе, восстановление пароля уходят не из почтового клиента, а из кода сайта, и именно они чаще всего не доходят.
Путей три, и они не равнозначны:
- Функция отправки самого языка (в PHP это
mail()). Письмо уходит с сервера хостинга, от адреса видаwww-data@server123.hosting.ru, без подписи и без SPF вашего домена. Такие письма фильтры отбраковывают чаще всего. Способ годится только для внутренних уведомлений, которые не жалко потерять. - SMTP вашей почты. Сайт авторизуется на почтовом сервере тем же ящиком, от имени которого пишет. Тогда письмо проходит SPF и DKIM домена и выглядит для получателя так же, как письмо человека. Для большинства сайтов это правильный выбор.
- Транзакционный сервис. Отдельный провайдер для писем от системы: свои очереди, статистика доставки и вебхуки об отказах. Оправдан, когда писем много или доставка критична для бизнеса; детали — в материале про доставляемость транзакционных писем.
# Типовые параметры подключения сайта к почтовому серверу
SMTP host: smtp.<провайдер>
SMTP port: 587 (STARTTLS) или 465 (SSL/TLS)
Encryption: обязательно, без шифрования — никогда
Username: robot@example.ru # реальный существующий ящик
Password: пароль приложения # не основной пароль от аккаунта
From: robot@example.ru # адрес отправителя = этому же ящику
Три правила, которые закрывают большинство проблем с письмами сайта:
- Адрес отправителя должен существовать на вашем домене. Не
noreply@localhostи не адрес хостинга. Многие провайдеры отклоняют письмо с ошибкой вида «отправитель не подтверждён», если ящик, указанный в поле From, им не принадлежит. - Пароль приложения вместо основного. При включённой двухфакторной аутентификации обычный пароль на SMTP не сработает, а созданный отдельно можно отозвать, не меняя пароль сотрудника.
- Порт 25 для отправки не используем. У большинства хостеров исходящий 25 закрыт, и это не ошибка, а мера против спама; какой порт для чего предназначен, разобрано в материале про почтовые порты.
Проверяйте отправку с сайта отдельно от почты сотрудников. Ситуация «у людей почта работает, а письма с форм не приходят» — самая частая из всех: домен настроен верно, а сайт по-прежнему шлёт письма мимо него. Отправьте заявку через реальную форму и посмотрите заголовки полученного письма.
Почта на своём домене бесплатно: что реально
Почта на своём домене бесплатно — рабочий сценарий, а не маркетинговая ловушка. У Яндекс 360 для бизнеса есть бесплатный тариф с базовыми возможностями почты, у VK WorkSpace условия для малых организаций тоже начинаются с бесплатного уровня. Точные лимиты меняются — сверяйте их на сайте провайдера.
А вот «бесплатный» свой сервер — иллюзия: Postfix и Dovecot не стоят ничего, но VPS, бэкапы и время администратора стоят. Считайте полную стоимость владения, а не цену лицензии.
От бесплатных тарифов ждите скромный объём ящика и минимальную поддержку. Для старта этого хватает, а переход на платный тариф не потребует перенастройки DNS.
Переезд с другого провайдера без потери писем
Переключить MX — минутное дело; сложность в том, чтобы не потерять письма, пришедшие в момент переключения, и не оставить сотрудников без архива переписки.
- Снизьте TTL записей MX заранее — за сутки до переезда. Тогда чужие резолверы подхватят новое значение за минуты, а не за день; зачем это нужно, разобрано в материале про TTL DNS-записей.
- Создайте у нового провайдера все ящики с теми же именами. Ящик, которого нет, — это отказ доставки сразу после переключения.
- Перенесите архив по IMAP штатным мигратором нового провайдера. Перенос идёт по протоколу и не требует остановки старой почты — он просто копирует папки.
- Переключите MX и одновременно опубликуйте новые SPF и DKIM. Забытый DKIM нового провайдера — причина того, что письма после переезда начинают уходить в спам.
- Не удаляйте старые ящики несколько дней. Часть отправителей будет доставлять по закэшированной MX-записи; после переключения имеет смысл ещё раз догнать архив мигратором.
- Уберите старые записи — прежний MX, прежний SPF-include, прежний DKIM-селектор — только после того, как поток писем полностью перешёл.
Смена NS-серверов домена уносит почту целиком. Это отдельный от смены провайдера почты случай, и он бьёт неожиданно: переехали на DNS конструктора сайтов или нового хостинга, а MX, SPF, DKIM и DMARC в новой зоне никто не создал. Исходящие письма при этом продолжают уходить, поэтому проблему замечают через день-два. Порядок действий — в материалах про смену DNS-сервера и подключение домена к конструктору.
Проверка работоспособности
Настройка не закончена, пока письма фактически не ходят в обе стороны. «Молчащий» ящик обнаруживается в худший момент — когда клиент написал, а ответа нет.

Сначала исходящие: отправьте письмо на внешний ящик в Gmail или Яндексе, откройте «Показать оригинал» и убедитесь, что в заголовках стоят spf=pass, dkim=pass и dmarc=pass. Затем ответьте на него и проверьте, что ответ дошёл.
Существование и доступность конкретного ящика проверьте через инструмент проверки email-адреса: он спрашивает у почтового сервера, готов ли тот принять письмо. Если письма не доходят — пройдитесь по чеклисту «почему письмо не дошло»; если доходят, но в спам, — поможет разбор типичных причин попадания в спам.
Типичные ошибки и что они означают
| Симптом | Причина | Что делать |
|---|---|---|
| Домен не подтверждается | Запись создана в поддомене или ещё не распространилась | Проверить dig … TXT +short, ставить @ в поле имени |
| Входящие не приходят вообще | MX отсутствует, указывает на старый сервер или на CNAME | MX обязан указывать на имя с A-записью, а не на псевдоним |
| Часть писем уходит на прежний сервер | Старая MX-запись не удалена или ещё в кэше | Удалить лишние MX, дождаться TTL |
| Письма от сотрудников доходят, от сайта — нет | Сайт шлёт через функцию языка с адреса хостинга | Перевести сайт на SMTP ящика домена |
| Ошибка «отправитель не подтверждён» (код 550) | В поле From стоит адрес, которого нет на вашем домене | Указывать реально существующий ящик |
| Всё настроено, но письма в спаме | Две SPF-записи, несовпадающий селектор DKIM или нулевая репутация домена | Оставить одну SPF, сверить селектор, наращивать объём постепенно |
| После переезда домена почта пропала | Сменили NS, а почтовые записи в новой зоне не создали | Перенести MX, SPF, DKIM, DMARC в новую зону |
Проверить, что домен отдаёт в мир именно то, что вы задумали, можно проверкой MX-записей и проверкой почтовых настроек домена: они показывают MX, SPF, DKIM и DMARC в одном месте и ловят самые частые расхождения.
FAQ
Сколько стоит почта на своём домене?
От нуля на бесплатных тарифах Яндекс 360 и VK WorkSpace до нескольких сотен рублей за пользователя в месяц на платных. Свой сервер — от стоимости VPS. Сам домен — несколько сотен рублей в год.
Можно ли сменить провайдера без потери писем?
Да: письма переносятся по IMAP штатными миграторами, после чего вы меняете MX-запись на нового провайдера. Адреса не меняются — в этом и смысл собственного домена.
Почему письма уходят в спам, хотя SPF и DKIM настроены?
Чаще всего дело в репутации: новый домен без истории отправки фильтры оценивают настороженно. Наращивайте объём постепенно, начинайте с деловой переписки и не шлите массовые рассылки в первый месяц.
Как проверить, существует ли адрес получателя?
Адрес можно проверить и без отправки письма — по ответу почтового сервера получателя. Как это работает и какие у метода ограничения, разобрано в статье о проверке существования email-адреса.
Можно ли держать почту у одного провайдера, а сайт у другого?
Да, и это обычная практика. За почту отвечает MX-запись, за сайт — A и CNAME: они независимы. Поэтому сайт может жить на конструкторе или у хостера, а почта — в облачном сервисе, и наоборот.
Что такое пароль приложения и зачем он нужен сайту?
Это отдельный пароль для программ, которые не умеют проходить двухфакторную аутентификацию. Сайту выдают именно его: при компрометации кода пароль отзывается за секунду, а сотрудник продолжает работать со своим обычным паролем.
Почему после смены хостинга перестали приходить письма?
Почти всегда потому, что вместе с хостингом сменили NS-серверы домена, а в новой зоне создали только A-запись сайта. MX, SPF, DKIM и DMARC остались в старой зоне, которую больше никто не спрашивает. Выпишите записи до переезда и перенесите их полностью.
Сколько ящиков заводить и что делать с адресами вроде info@?
Персональные ящики — по числу сотрудников, а общие адреса (info@, sales@, support@) удобнее делать алиасами или группами: письма падают нескольким людям сразу, и при увольнении никого не нужно перенастраивать.
Финальный чеклист
- Домен подтверждён у провайдера (TXT-запись или мета-тег).
- MX указывает только на актуальный сервер, старые записи удалены.
- SPF-запись одна и заканчивается строгим квалификатором.
- DKIM включён, открытый ключ опубликован в DNS.
- DMARC-политика опубликована, отчёты приходят на рабочий ящик.
- Тестовые письма проходят spf=pass, dkim=pass и dmarc=pass.
- Письма с внешних сервисов доходят во «Входящие», а не в спам.
- Запись подтверждения домена не удалена после проверки.
- Сайт отправляет письма через SMTP ящика на домене, а не через функцию языка.
- В поле отправителя у писем сайта стоит реально существующий ящик.
- Для сайта выдан отдельный пароль приложения, который можно отозвать.
- При переезде: TTL снижен заранее, ящики созданы, архив перенесён по IMAP, старые записи убраны после перехода потока.
- После любой смены NS-серверов проверено, что MX, SPF, DKIM и DMARC на месте.