Корпоративная почта на домене компании: как подключить и настроить SPF, DKIM

Корпоративная почта на домене компании нужна не только для аккуратных адресов вида info@company.ru. Она влияет на доверие клиентов, доставку писем, безопасность переписки и контроль над рабочими аккаунтами. Если DNS-записи настроены неправильно, письма попадают в спам, не доходят до клиентов или отправляются от имени вашего домена злоумышленниками.

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

Что такое корпоративная почта и зачем ей домен компании

Корпоративная почта работает на адресах, связанных с вашим доменом: sales@company.ru, director@company.ru, support@company.ru. Доменная часть адреса совпадает с адресом сайта, поэтому клиенту проще понять, что письмо действительно принадлежит вашей организации.

Бесплатный адрес на стороннем сервисе может работать технически без проблем, но для деловой переписки он часто выглядит менее убедительно. Особенно это заметно в B2B, при отправке коммерческих предложений, договоров, счетов и уведомлений от интернет-магазина.

У корпоративной почты есть и управленческие преимущества:

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

Важно разделять две задачи. Создание почтового ящика отвечает за саму переписку, а DNS-настройки подтверждают, какие серверы имеют право отправлять письма от имени домена. SPF и DKIM относятся именно ко второй задаче.

Из каких частей состоит настройка почты на домене

Для работы корпоративной почты используются несколько типов записей DNS. Это не отдельная программа на компьютере, а параметры домена, которые сообщают почтовым системам, куда доставлять письма и каким отправителям доверять.

Кроме DNS, потребуется сама почтовая платформа. Это может быть сервис регистратора домена, отдельный корпоративный сервис или почтовая система на собственном сервере. Для малого и среднего бизнеса обычно разумнее использовать готовую платформу: она снижает затраты на обслуживание, обновления, фильтрацию спама и восстановление доступа.

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

Как выбрать почтовый сервис для бизнеса

Выбирайте сервис не только по цене одного ящика. Важнее оценить, сколько будет стоить вся система при росте команды и какие функции нужны администратору.

• Количество пользователей. Уточните, оплачиваются ли общие адреса вроде info@ и support@ отдельно или их можно создать как группы и переадресации.
• Объём ящика. Для менеджера, который хранит договоры и вложения, требования выше, чем для адреса, с которого отправляются только уведомления.
• Защита аккаунтов. Проверьте наличие двухфакторной аутентификации, журналов входа, ограничения по устройствам и централизованного сброса паролей.
• Перенос переписки. Если сотрудники уже работают в старых ящиках, заранее уточните, поддерживает ли сервис импорт сообщений и контактов.
• Работа с телефона. Важны удобные приложения, календарь, контакты и возможность быстро отключить доступ у утерянного устройства.
• Администрирование. Руководителю или ответственному сотруднику нужны понятные настройки ролей, алиасов, групп и правил хранения писем.
• Поддержка. При сбое почты важно понимать, куда обращаться и какие сроки реакции предусмотрены условиями сервиса.

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

Как подключить корпоративную почту на домене: порядок действий

Настройку лучше выполнять по плану. Самая частая причина проблем заключается не в сложности DNS, а в том, что записи добавляют в неправильной последовательности или одновременно меняют несколько сервисов.

1. Определите владельца домена. Найдите доступ к панели регистратора или DNS-хостинга. Доступ к сайту и доступ к DNS могут находиться в разных системах.
2. Выберите почтовый сервис. Получите у него точные значения MX, SPF, DKIM и, если предусмотрено, DMARC. Не копируйте записи из случайных инструкций, потому что значения зависят от поставщика.
3. Создайте организацию и пользователей. Заранее составьте список сотрудников, общих адресов, переадресаций и правил доступа.
4. Подтвердите домен. Обычно сервис просит добавить TXT-запись с уникальным кодом. Это доказывает, что вы управляете доменом.
5. Добавьте MX-записи. Они направят входящие письма на новую почтовую платформу.
6. Настройте SPF и DKIM. Эти записи отвечают за проверку исходящих сообщений и репутацию отправителя.
7. Добавьте DMARC. На первом этапе лучше использовать наблюдательную политику, чтобы собрать отчёты и не заблокировать легитимные письма.
8. Проверьте отправку и получение. Отправьте письма на разные адреса, ответьте на них, проверьте вложения, подпись, ссылки и попадание в спам.
9. Зафиксируйте настройки. Сохраните значения записей, дату изменений и данные администратора в защищённом месте.

После изменения DNS обновление данных может занять от нескольких минут до 24-48 часов. Точный срок зависит от времени жизни записей и особенностей DNS-провайдера. В этот период часть отправителей может видеть старые настройки, поэтому перенос почты лучше не планировать перед важной рассылкой или запуском рекламной кампании.

Как настроить MX, чтобы письма приходили в нужный ящик

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

Конкретная схема зависит от выбранного сервиса. Один поставщик может попросить добавить две записи MX, другой пять. Иногда в панели уже есть старые записи от предыдущей почты. Их нельзя оставлять автоматически: если старый сервер имеет более высокий приоритет, часть писем будет уходить не туда.

Перед заменой MX проверьте:

• какие ящики существуют в старой системе и перенесены ли их данные;
• настроены ли переадресации, общие адреса и правила сортировки;
• не отправляет ли сайт письма через старый сервер;
• не используют ли CRM, интернет-магазин, формы сайта или сервис рассылок отдельные почтовые каналы;
• есть ли резервный план, если после переключения часть писем не будет доставляться.

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

Если настройки сайта требуют изменения, это относится к техническим работам, а не только к DNS. В таких случаях полезно подключить доработку сайта, чтобы проверить формы, SMTP-подключение и уведомления после перехода.

SPF: как разрешить отправку писем от имени домена

SPF, или Sender Policy Framework, представляет собой TXT-запись в DNS. В ней перечисляются серверы и сервисы, которым разрешено отправлять письма с адресами вашего домена.

Упрощённый пример выглядит так:

v=spf1 include:mail.example.ru -all

Здесь указывается версия правила, источник разрешённых серверов и действие для остальных отправителей. Значение -all означает жёсткий запрет для серверов, которых нет в списке. Но использовать его сразу безопасно только после проверки всех легитимных отправителей.

В реальном проекте письма могут отправляться не только из почтового интерфейса. Источниками бывают:

• основной корпоративный почтовый сервис;
• форма обратной связи на сайте;
• CRM или система автоматизации продаж;
• сервис массовых рассылок;
• платформа интернет-магазина;
• сервис транзакционных уведомлений, например о заказе или оплате.

Главное правило SPF, у домена должна быть одна итоговая SPF-запись. Нельзя просто создать несколько TXT-записей с началом v=spf1 для разных сервисов. Получатели могут считать такую конфигурацию ошибочной. Все разрешения объединяют в одну строку.

Есть и техническое ограничение: SPF допускает ограниченное число обращений к DNS при проверке, обычно говорят о лимите в 10 механизмов поиска. Если подключить много сервисов через include, правило может превысить лимит. Тогда часть проверок начнёт завершаться ошибкой. Для бизнеса это означает, что SPF нужно не копировать бесконечно, а периодически пересматривать при подключении новых систем.

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

DKIM: как работает цифровая подпись письма

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

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

DKIM-запись обычно создаётся с именем, в котором есть селектор, например selector1._domainkey. Селектор позволяет использовать несколько ключей для разных систем или менять ключ без остановки отправки. Значение записи может быть длинным, поэтому DNS-панель должна корректно поддерживать TXT-записи.

Включение DKIM обычно выглядит так:

1. в панели почтового сервиса открыть раздел домена или безопасности;
2. сгенерировать новый DKIM-ключ;
3. скопировать имя записи и значение открытого ключа;
4. создать TXT-запись в DNS без лишних кавычек и пробелов, если панель добавляет их автоматически;
5. вернуться в почтовый сервис и нажать кнопку проверки;
6. отправить тестовое письмо и убедиться, что подпись проходит проверку.

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

DMARC и защита домена от поддельных писем

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

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

Для внедрения используйте последовательность:

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

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

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

Защита домена не заменяет защиту аккаунтов. Даже идеальные SPF, DKIM и DMARC не спасут, если сотрудник передал пароль мошеннику. Включите двухфакторную аутентификацию, запретите повторное использование паролей и ограничьте число администраторов.

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

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

1. Отправьте письмо с корпоративного адреса на несколько почтовых сервисов.
2. Ответьте на него и проверьте, что ответ пришёл в правильный ящик.
3. Посмотрите, не попало ли сообщение в папку «Спам» или «Промоакции».
4. Проверьте технические заголовки письма, где видны результаты SPF, DKIM и DMARC.
5. Отправьте письмо с вложением допустимого размера и убедитесь, что оно открывается.
6. Проверьте письмо из формы сайта, CRM и других систем, если они отправляют сообщения.
7. Проверьте адреса info@, sales@ и support@, включая переадресацию и ответы группы.
8. Убедитесь, что после смены пароля и включения двухфакторной аутентификации старые сессии закрываются.

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

Сохраните результаты проверки в документе: дата, отправитель, получатель, статус доставки, найденная проблема и решение. Это пригодится при смене подрядчика, переносе сайта или подключении нового сервиса.

Типичные ошибки при настройке корпоративной почты

Ошибочная SPF-запись

Частая проблема, несколько SPF-записей или случайное удаление разрешения для CRM и сайта. В результате обычная переписка работает, а автоматические уведомления перестают доходить. Исправление начинается с полного списка отправителей, а не с добавления очередного фрагмента вслепую.

Старые MX-записи

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

Неправильное имя DKIM-записи

Имя записи зависит от селектора и домена. Ошибка в одной части адреса, лишнее повторение домена или неверный тип записи приводит к тому, что сервис не видит ключ. Копируйте имя и значение из панели провайдера, а не набирайте их вручную.

Немедленное включение жёсткого DMARC

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

Публикация паролей в общем чате

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

Отсутствие плана при увольнении сотрудника

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

Игнорирование сайта и рассылок

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

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

Как связать корпоративную почту с сайтом и рабочими процессами

Почта на домене часто участвует в работе сайта: принимает заявки, отправляет уведомления, используется для восстановления доступа и отвечает клиентам. Поэтому её нельзя рассматривать как полностью отдельную настройку.

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

Для критичных писем настройте отдельный технический адрес, например no-reply@company.ru, если на него не должны приходить ответы. Для клиентской переписки используйте адрес, который регулярно проверяется. Не смешивайте автоматические уведомления и ручные ответы без необходимости, иначе важные сообщения легко потерять среди системных писем.

Если после перехода на HTTPS меняются формы сайта, это не означает, что почта настроена автоматически. HTTPS защищает соединение с сайтом, а SPF, DKIM и DMARC проверяют отправку писем. О различиях между этими задачами можно прочитать в материале о SSL-сертификате и подключении HTTPS.

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

Сколько времени занимает подключение и от чего зависит стоимость

Если домен и DNS доступны, почтовый сервис выбран, а количество ящиков небольшое, базовая настройка обычно занимает от нескольких часов до 1 рабочего дня. Перенос большой переписки, настройка CRM, сайта, мобильных устройств и правил безопасности увеличивает срок до 2-5 рабочих дней. При сложной инфраструктуре сначала проводят обследование, и только после него называют точный план.

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

Остерегайтесь оценки «настроим почту за пять минут», если в задачу входят сайт, CRM, рассылки и перенос данных. Добавить одну TXT-запись действительно можно быстро, но проверить все каналы отправки и обеспечить безошибочный переход требует больше времени.

Частые вопросы

Можно ли подключить почту, если сайт размещён у другого подрядчика?

Да. Для почты важен доступ к DNS домена, а не к серверу сайта. Сайт и почта могут работать у разных поставщиков, если записи A, CNAME, MX, TXT и другие параметры не конфликтуют между собой.

Нужно ли настраивать SPF и DKIM, если письма пока доходят?

Желательно настроить их заранее. Доставка отдельных писем сегодня не означает стабильную репутацию домена завтра. Фильтры меняют правила, а при росте объёма отправки отсутствие подтверждения может привести к спаму и блокировкам.

Можно ли использовать один адрес для сайта, сотрудников и рассылки?

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

Как понять, что DKIM работает?

Отправьте письмо на внешний ящик и откройте его технические заголовки. В результатах проверки должна быть отметка о прохождении DKIM с вашим доменом. Дополнительно проверьте статус в панели почтового провайдера.

Что делать, если письма попадают в спам после настройки?

Проверьте SPF, DKIM и DMARC, совпадение домена отправителя с доменом подписи, содержание письма, частоту рассылок и наличие жалоб получателей. Также убедитесь, что домен не отправляет сообщения через неизвестные или заброшенные сервисы.

Нужно ли делать резервную копию корпоративной почты?

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

Что делать: короткий план

1. Составьте список сотрудников, общих адресов, переадресаций и внешних сервисов, которые отправляют письма.
2. Проверьте, у кого находится доступ к домену и DNS-панели.
3. Выберите почтовый сервис с учётом числа пользователей, объёма ящиков, безопасности и переноса данных.
4. Создайте пользователей и подтвердите владение доменом.
5. Добавьте MX-записи и проверьте входящую доставку.
6. Соберите одну корректную SPF-запись с учётом сайта, CRM и рассылок.
7. Создайте DKIM-запись для каждого сервиса, который отправляет письма от имени домена.
8. Добавьте DMARC сначала в режиме мониторинга, изучите отчёты и только потом ужесточайте правило.
9. Проверьте формы сайта, уведомления, CRM, вложения, мобильный доступ и работу общих адресов.
10. Зафиксируйте настройки, включите двухфакторную аутентификацию и определите порядок передачи доступа при увольнении.

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