Как создать почту на своем домене: полное руководство

Домен уже куплен. Теперь нужен почтовый ящик.

Создание почты на своём домене является одним из самых важных инфраструктурных решений для владельца бизнеса. Это разница между адресами someone@gmail.com и name@yourcompany.com. Первый выглядит как временный побочный проект, а второй как настоящий бизнес.

Дело также в контроле. Собственный домен и право менять MX помогают управлять адресами и выбирать провайдера. Это не означает владения его инфраструктурой или неограниченного контроля цен и данных. Договор, права доступа и возможности экспорта по-прежнему важны.

Создаёте ли вы первый ящик или как MSP переносите пятьдесят клиентов со старого cPanel, основные компоненты остаются доменом, почтовым сервисом и нужными записями DNS. Но объём переноса, шлюзы и порядок переключения могут различаться. Руководство объясняет основу процесса.

Перед началом: что действительно потребуется

Попытка настроить почту без этих трёх компонентов легко приводит к противоречивой конфигурации DNS и потере сообщений. Не начинайте, пока не подготовите все три.

1. Домен

Нужен разрешённый контроль домена, например yourcompany.com. Примерами регистраторов являются Namecheap, Cloudflare Registrar и Porkbun; сравните текущие условия. Отделение регистратора от веб-хостинга может уменьшить зависимости, но не гарантирует управление DNS при сбое. Также проверяйте независимую доступность DNS-провайдера, аккаунта, восстановления и полномочий.

2. Доступ к DNS

Вам нужен доступ на запись в зону DNS. В панели регистратора этот раздел обычно называется "DNS Management", "Zone Editor" или "Advanced DNS". Здесь предстоит редактировать записи TXT, MX и CNAME. Если такого доступа нет, остановитесь и получите его прежде, чем делать что-либо ещё.

3. Почтовый хостинг

Регистрация домена, обслуживание DNS и почтовый хостинг выполняют разные задачи. Одна регистрация не создаёт ящик; GoDaddy и другие сервисы могут предлагать почту отдельно или в составе пакета. Два распространённых варианта:

• Стандартный выбор: Google Workspace или Microsoft 365. $72-$144 с пользователя в год являются историческим примером. Для info@ и billing@ могут подойти псевдонимы, группы или поддерживаемые общие ящики вместо дополнительных пользовательских лицензий. Проверьте редакцию и характер использования.
• Выбор администратора: TrekMail. Сравните модель фиксированной оплаты и общего пула с задачами команды. Оплата за пользователя, доступная ёмкость и функции определяются текущими условиями тарифа.

Контрольный список на 10 минут

Если вы уже выполняли такую настройку, вот краткий маршрут. Время в заголовке служит ориентиром для планирования, а не сроком полной готовности DNS и почты. Пропущенная проверка может, например, потребовать ещё час диагностики.

Шаг 1: сначала создайте почтовые ящики (да, именно сначала)

Это распространённая ошибка новичков, из-за которой можно потерять реальные обращения клиентов.

После переключения MX отправители используют новый маршрут по мере обновления своих ответов DNS. Если contact@yourdomain.com не является допустимым получателем, сервер может ответить 550 User Not Found. Другие конфигурации могут вести себя иначе; проверяйте ответ, очередь и список получателей, не предполагая мгновенного отказа.

Создайте все нужные ящики до переключения MX. Запись TXT для проверки домена может потребоваться раньше.

Порядок действий в TrekMail:

1. Войдите в панель TrekMail.
2. Откройте вкладку Mailboxes для своего домена.
3. Создайте все используемые адреса.

Для малого и среднего бизнеса: как минимум создайте личный адрес (yourname@) и функциональный адрес (hello@ или info@).

Для агентств, переносящих клиента: полностью соберите допустимых получателей и их маршруты. Если у клиента был billing@, настройте billing@ как подходящего получателя до переключения MX. Проверьте ящики, псевдонимы и пересылку до планирования перехода. Пропуск адреса может вызвать отказ или неправильную маршрутизацию.

TrekMail позволяет создавать ящики вручную или отправлять приглашение для настройки почтового ящика. Уполномоченный пользователь задаёт пароль по защищённой одноразовой ссылке с ограниченным сроком действия; агентству не нужно собирать его постоянный пароль. Проверьте получателя и полномочия. Процесс описан в документации по приглашениям для настройки ящика.

Шаг 2: настройте записи MX и переключите доставку

Записи MX (Mail Exchange) задают предполагаемые серверы приёма и их приоритеты. Отсутствие MX не всегда делает почту невозможной: при определённых условиях SMTP может использовать адресные записи самого домена. Не полагайтесь на этот резервный механизм вместо документированной конфигурации сервиса.

Как настроить записи MX:

1. Откройте управление авторитетной зоной DNS у обслуживающего её провайдера; он может отличаться от регистратора.
2. Проверьте существующие записи MX. Записи "GoDaddy Secure Mail", "Google Workspace" или старого cPanel удаляйте только после проверки разрешённой схемы и плана перехода. Сохраните необходимые шлюзы и резервные маршруты, удаляя лишь подтверждённо устаревшие цели.
3. Добавьте актуальные записи из настройки своего домена. Нынешняя стандартная конфигурация указывает сервер mail.trekmail.net. Таблица TrekMail ниже является историческим примером, а не готовой конфигурацией для копирования:

О TTL: 300 секунд могут служить подготовительным значением. Это 5 минут срока хранения ответа, а не обязательная частота запросов. Ответы с прежней TTL 24 часа могут сохраняться до её истечения. Согласованно уменьшайте TTL заранее, а после проверки выберите, например, 3600 согласно плану эксплуатации DNS.

Снимки экранов и названия полей у разных регистраторов приведены в нашей инструкции по настройке DNS у популярных провайдеров.

Шаг 3: первый вход и проверка отправки и получения

15-30 минут могут быть интервалом проверки, а 24 часа не являются универсальным максимальным сроком. Видимость зависит от TTL, прежних кэшей и ответов авторитетных серверов. Не считайте всё исправным только потому, что завершили шаг 2.

Сначала войдите через веб-почту, затем настраивайте Outlook или iPhone. Здесь проверяются доступ по HTTPS и маршрут тестового письма, а не клиентское подключение IMAP или SMTP.

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

• Оно пришло?
• Оно попало в спам? Проверьте SPF и DKIM вместе с содержимым, репутацией и политикой получателя. См. шаг 4 ниже.

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

• Ответ появился во входящих веб-почты?
• Если да, этот проверенный маршрут сработал. Перед завершением перехода проверьте ответы DNS и остальные необходимые адреса.

После успешного прохождения обеих проверок можно настроить почтовый клиент. Параметры подключения IMAP приведены в документации TrekMail по настройкам IMAP и SMTP. Для подключения через Gmail есть отдельная инструкция по подключению Gmail.

Шаг 4: три основы доставляемости, SPF, DKIM и DMARC

MX определяет маршрут приёма, а SPF, DKIM и DMARC поддерживают аутентификацию. Требования Google и Yahoo в 2025-2026 годах различаются по типу отправителя и потоку писем. Настройте и проверьте применимые требования, не принимая их за гарантию отсутствия спама.

SPF: кому разрешено отправлять

SPF (Sender Policy Framework) разрешает передающие IP-адреса для фактической идентичности SMTP, обычно домена MAIL FROM или применимого HELO. Если проверяется yourcompany.com, получатель оценивает его SPF для IP соединения. Видимое поле From напрямую этой проверкой не подтверждается.

Следующий SPF является историческим примером. Сверьте его с актуальными параметрами своего TrekMail: нынешний стандартный include использует spf.trekmail.net. Также учитывайте остальные разрешённые сервисы отправки:

v=spf1 include:_spf.trekmail.net -all

Пример разрешает IP, определённые через include, и возвращает SPF-Fail для остальных. Отказ в приёме письма зависит от полной проверки и политики получателя, а не автоматически следует из этого результата.

Окончание -all задаёт Fail для не подошедших IP. Используйте -all после проверки всех разрешённых потоков, включая транзакционную почту и CRM. Ограничение 10 относится к рекурсивно оцениваемым термам SPF, вызывающим обращения к DNS, а не к каждому пакету или только количеству include. Превышение приводит к SPF-PermError.

DKIM: пломба, показывающая вмешательство

DKIM (DomainKeys Identified Mail) подписывает выбранные части сообщения, если сервис отправки настроен соответствующим образом. Получатель криптографически проверяет подпись и открытый ключ. Изменение подписанной части может нарушить проверку, но изменение неподписанного заголовка не обязательно делает это. Результат сам по себе не определяет отказ или попадание во входящие.

Опубликуйте открытый ключ как запись TXT согласно ключу и селектору, указанным в панели TrekMail. Мастер помогает с настройкой, но скопированная запись DNS не подтверждает успешную криптографическую проверку подписи реального письма. Проверьте и фактическую отправку. Порядок действий приведён в документации об обязательных записях DNS.

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

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

Начните с политики только для наблюдения:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Эта политика не просит изолировать или отклонять письма по DMARC, но другие фильтры остаются активными. Изучите отчёты и проверьте все разрешённые потоки перед согласованным переходом к p=quarantine, а затем к p=reject.

Более подробные сведения о каждой записи приведены в наших статьях о настройке SPF, DKIM и DMARC. Полную картину можно найти в одном месте в руководстве о порядке настройки аутентификации электронной почты.

Почему не использовать обычный Gmail?

"Разве нельзя просто использовать mycompany@gmail.com?" Можно. Но помимо отправки и получения оцените, соответствуют ли задачам бизнеса администрирование, передача доступа и восстановление аккаунта.

Вот что на практике может пойти не так при использовании личных адресов для бизнеса:

Владение данными

Блокировка личного аккаунта может временно закрыть доступ к рабочим данным; процедуры восстановления и проверки зависят от сервиса. Создав почту на собственном домене, вы сможете лучше организовать рабочие полномочия. Планируйте разрешённый экспорт и резервные копии: переход требует совместимой передачи и проверки полноты, а контакты и календари могут переноситься отдельно.

Зависимость от одного сотрудника

Уход сотрудника, использующего john.sales@gmail.com, может осложнить доступ к рабочей переписке. Управляемый john@yourcompany.com позволяет организовать разрешённую передачу. Также проверяйте и отзывайте активные сеансы, токены и делегирование, где это поддерживается. Сохраните необходимые доказательства и согласуйте пересылку; смена пароля сама по себе не гарантирует непрерывной работы.

Потеря доступа к SaaS

Личная почта для восстановления может осложнить доступ к бухгалтерии, CRM и рекламным платформам после ухода сотрудника. Используйте подходящие контролируемые адреса, например billing@yourcompany.com, и документируйте одобрение бизнеса. При смене сотрудников проверяйте роли и восстановление: адрес сам по себе не сохраняет полный контроль аккаунта.

Как устроена почта на собственном домене

Адрес почты на собственном домене означает, что часть после @ совпадает с доменом сайта. Определение простое, но лежащая в основе инфраструктура существенно меняет то, как работает почта и от чего она зависит.

Отдельная платформа является разумным вариантом для снижения общих рисков отказа. Сравнивайте архитектуру, восстановление и стоимость эксплуатации; другие контролируемые модели также могут подходить бизнесу.

Простейшая настройка для 1-5 ящиков

Microsoft 365 или Google Workspace могут предлагать небольшой компании больше функций, чем ей требуется. Платформа, обслуживающая и предприятия из 500 человек, не обязательно подходит для почты трёх сотрудников и нескольких функциональных адресов. Сравните её возможности с реальными задачами.

Старый подход (ловушка оплаты за пользователя)

Исторический расчёт использует Google Workspace Starter за $6/user/month. Помимо трёх сотрудников нужны info@, sales@ и billing@. Только при создании дополнительных лицензируемых пользователей получится 6 лицензий, $36/month и $432/year. Псевдонимы или группы могут позволить другую схему; проверьте нынешние цены и права.

30GB на пользователя и $12/user/month являются историческими значениями для сравнения. Доступное хранилище Google Workspace зависит от редакции, общего пула и административных пользовательских лимитов. Заполнение одной квоты не обязательно требует повысить тариф всем. Проверьте хранение, очистку и допустимое перераспределение перед расширением.

Новый подход (общий пул TrekMail)

Исторический пример TrekMail Starter указывает $3.50/month или $42/year, 50 доменов, 100 ящиков на домен и 15GB общего места. Адреса info@, billing@ и support@ при соответствующих правах могут направлять почту в действительные ящики как псевдонимы. Проверьте текущие цены, правила псевдонимов и лимиты, не считая эти параметры неизменными.

В отличие от упрощённого сравнения с 2005 годом, общий пул может учитывать разный спрос на место. Пользователь с 12GB вложений всё равно занимает часть совокупной квоты и может иметь собственный лимит. Проверяйте объём и права: расширение может потребоваться, даже если оно оплачивается не за каждого сотрудника.

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

Полные сведения приведены на странице цен TrekMail, а сравнение планов доступно в обзоре тарифов. Для сопоставления с другими предложениями рынка прочитайте наш обзор вариантов деловой почты для малого бизнеса.

Записи MX без технического жаргона

DNS абстрактен, поэтому рассмотрим конкретную аналогию.

Представьте домен в виде офисного здания.

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

Когда кто-то отправляет вам письмо, его сервер ищет ваш домен в глобальном каталоге DNS. В частности, он запрашивает запись MX.

• Нет записи MX? При определённых условиях используется адресная запись самого домена; это не обеспечивает успешного приёма.
• Запись MX указывает на старый сервис? Он может принять, задержать или отклонить письмо. Проверьте фактический маршрут.
• Запись MX верна? Найден предполагаемый сервер, но допустимые получатели, состояние сервиса и фильтры всё ещё влияют на приём.

Работающий сайт (запись A) и полностью неработающая почта (запись MX) могут существовать одновременно. У служб разные функции DNS, но инфраструктура и доступ к управлению могут быть общими.

5 ошибок DNS, которые вредят доставляемости

Одни и те же ошибки встречаются постоянно. Если после настройки доменной почты что-то не работает, сначала проверьте эти пункты.

1. Сохранение "резервной MX"

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

2. Конфликт CNAME на корневом домене

Обычный CNAME на корневом домене (@) не может сосуществовать с необходимыми там SOA, NS и MX. Для Wix или Squarespace используйте документированную настройку. Функции Alias/ANAME или flattening не равнозначны публикации обычного CNAME в корне; выберите поддерживаемую провайдером конфигурацию.

3. Повторное изменение записей до окончания распространения

Ответы DNS могут временно различаться из-за распределённых кэшей. 24 часа служат примером для планирования, не максимальным сроком. Повторное изменение через 10 минут не перезапускает общую мировую шкалу времени, но может увеличить число разных сохранённых значений. До новых изменений проверяйте авторитетную зону и TTL.

4. Отсутствующая запись SPF

Без SPF для проверяемого домена SMTP не опубликовано разрешение передающих IP-адресов. Само по себе это не доказывает подделку или спам: другие проверки сохраняют значение. Настройте запись, учитывающую все разрешённые сервисы отправки. Если она ещё не настроена, обратитесь к нашему руководству по настройке SPF.

5. Неверное имя хоста в записи MX

При добавлении MX поле "Host" или "Name" почти всегда должно содержать @, обозначающий корневой домен. Если указать mail или www, вы настроите маршрутизацию для user@mail.yourcompany.com, а не user@yourcompany.com. Перепроверяйте это поле в каждой добавленной записи.

Какие адреса создать в первую очередь

Не создавайте ящики наугад. Сначала продумайте жизненный цикл каждого адреса. Кто им управляет? Что произойдёт, когда сотрудник уйдёт?

1. Аварийный адрес администратора (ops@ или admin@)

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

2. Функциональные псевдонимы (info@, support@, hello@)

Нет смысла проверять пять отдельных ящиков. При подходящих тарифных правах создайте info@ как псевдоним основного ящика. Отправка от имени info@ требует разрешённой идентичности отправителя и поддерживаемой настройки SMTP и клиента: пересылка входящих сама по себе её не создаёт. Документация по настройке переадресации описывает маршрут приёма.

3. Ролевые адреса для инфраструктуры (billing@, marketing@)

Для подписок SaaS, рекламных платформ и финансовых сервисов используйте подходящие контролируемые ролевые адреса. Если уходящий менеджер по маркетингу связал Facebook Ads с sarah@yourcompany.com, проверьте роли и восстановление, отзовите поддерживаемые сеансы и полномочия и измените необходимые учётные данные. Пересылку согласуйте отдельно. При личном Gmail разбирательство с поддержкой Facebook может, например, занять три недели; фактическая длительность зависит от случая.

Соглашения об именах и выбор формата

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

Практическая рекомендация: в небольшой компании, где все знают друг друга, начните с firstname@. После роста до 5-10 человек запланируйте переход на first.last@. При поддерживаемой настройке псевдонима john@ может направлять письма на john.doe@. Проверьте приём и разрешённую отправку обоих адресов: один псевдоним не гарантирует перехода без потерь.

Устранение неполадок

Вы выполнили все шаги, но что-то всё равно не работает. Ниже перечислены распространённые сценарии и необходимые проверки.

"Я могу отправлять, но не могу получать".

Возможная причина: маршрут MX или сохранённые ответы DNS; также проверяйте получателя, очередь и фильтры.
Проверка: сравните выбранные ответы whatsmydns.net с авторитетной зоной. Старый сервис может означать кэш или всё ещё неправильные данные зоны. Проверьте TTL, сохранённые записи и фактический маршрут, а не просто ждите.

"Я могу получать, но мои письма попадают в спам".

Возможная причина: аутентификация, репутация, содержимое или политика получателя.
Проверка: тест в mail-tester.com даёт сведения о проверенном письме, но не моделирует каждого получателя. При подтверждённом домене и доступном объёме данных Google Postmaster Tools показывает агрегированные показатели для личных адресов Gmail, не для всей почты. Дополните анализ исходным ответом сервера и проверкой подписи.

"Outlook постоянно запрашивает пароль".

Возможная причина: порт, режим TLS, учётные данные, политика аккаунта или неподдерживаемый способ аутентификации.
Проверка: сверяйте параметры ниже с актуальной инструкцией сервиса, проверяя имя хоста и сертификат. SSL/TLS здесь является историческим названием настройки современного TLS, а не рекомендацией устаревшего SSL:

• IMAP (входящие): порт 993, SSL/TLS
• SMTP (исходящие): порт 465 (SSL/TLS) или 587 (STARTTLS)
• Имя пользователя: полный адрес с @domain, а не только часть перед ним

Полная настройка клиента описана в руководстве по подключению к Outlook и в справочнике параметров IMAP и SMTP.

"Я получаю ошибку доставки 550".

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

Заключение

Создать почту на своём домене означает принять эксплуатационную ответственность за своё цифровое присутствие. Вы переходите от аренды к владению.

Цель состоит в документированной, проверяемой настройке, а не в системе без дальнейшего обслуживания. Регулярно оценивайте MX, разрешённые сервисы отправки и доступные отчёты DMARC. Аутентификация важна, но не гарантирует приёма или попадания во входящие.

Если пользовательские лицензии перегружают бюджет, а Google Calendar или SharePoint не нужны, рассмотрите TrekMail. Права тарифа, общий объём и совместимые IMAP/SMTP-клиенты должны соответствовать задачам. Только описанный вариант Nano требует собственный SMTP для всех исходящих, включая ответы; управляемая платная отправка зависит от прав и настройки. Проверяйте нынешние бесплатные предложения и расширения по ёмкости и потребностям пользователей.

Ваш домен. Ваши записи. Ваши данные.

Попробуйте TrekMail бесплатно, trekmail.net