У компании есть сайт example.ru, но на странице контактов указан адрес вроде company2024@yandex.ru или название фирмы с набором цифр на одном из бесплатных почтовых сервисов. Технически в этом нет ничего страшного. Письма отправляются и приходят.
Но собственный домен позволяет сделать гораздо аккуратнее: info@example.ru, order@example.ru, support@example.ru или ivan@example.ru.
Такая почта называется доменной или корпоративной. Причем для ее работы совсем не обязательно держать почтовый сервер рядом с сайтом. Домен может быть зарегистрирован у одной компании, сайт размещаться у второй, DNS обслуживаться у третьей, а электронная почта работать через четвертый сервис.
Именно это поначалу сбивает с толку. Кажется, что раз сайт уже работает на хостинге, то и почтовый ящик обязан находиться там же. На самом деле DNS позволяет независимо указать, куда направлять веб-трафик и куда доставлять электронные письма.
Разберемся, как это устроено, что потребуется настроить и почему одной MX-записи сегодня уже мало.
Что значит почта на своем домене
В обычном адресе user@yandex.ru доменная часть после символа @ принадлежит Яндексу. В адресе user@example.ru домен example.ru контролирует владелец сайта или компании.
Он сам решает, какие адреса создавать.
Можно завести отдельные ящики для сотрудников, например n.ivanov@example.ru и a.petrov@example.ru. Можно использовать функциональные адреса support@example.ru, sales@example.ru, documents@example.ru. Можно настроить псевдонимы и группы, если выбранный почтовый сервис это поддерживает.
Для клиента такой адрес сразу связывает письмо с сайтом и названием организации.
Это особенно удобно, когда сотрудники меняются. Адрес sales@example.ru принадлежит не конкретному менеджеру, а функции внутри компании. Его не придется печатать заново на визитках после кадровых изменений.
Но самое интересное находится за самим адресом.
Чтобы другие почтовые системы понимали, куда доставлять письма для example.ru и каким отправителям можно доверять при получении сообщений от этого домена, используются DNS-записи.
MX сообщает интернету, куда доставлять вашу почту
Допустим, кто-то отправляет письмо на info@example.ru.
Почтовой системе отправителя нужно выяснить, какой сервер принимает электронную почту для example.ru. Для этого она обращается к DNS и ищет MX-записи домена.
MX расшифровывается как Mail Exchange.
Это означает, что веб-сайт и почта легко могут находиться в разных местах.
A-запись домена направляет посетителей сайта на IP веб-сервера. MX-запись сообщает почтовым системам, куда отправлять письма.
Перенос сайта с одного хостинга на другой поэтому не обязательно затрагивает почту. Если MX и остальные почтовые записи не меняются, электронная почта продолжает работать у прежнего поставщика.
И наоборот, можно перенести почту, не перемещая сам сайт.
Где можно разместить доменную почту
Самый очевидный вариант предлагает сам хостинг.
На многих тарифах виртуального хостинга можно создать ящики прямо в панели управления. Владелец добавляет info@domain.ru, задает пароль и подключает адрес к почтовой программе или веб-интерфейсу.
Для небольшого сайта это удобно: все находится в одной панели и может входить в стоимость тарифа.
Есть специализированные корпоративные почтовые сервисы. Они позволяют подключить собственный домен и создавать адреса сотрудников вида login@example.ru.
Есть российские и зарубежные поставщики. Конкретный выбор зависит от количества пользователей, объема ящиков, требований к хранению данных, календарям, совместной работе, администрированию и стоимости.
Третий путь состоит в самостоятельном почтовом сервере на VPS или физической машине.
Он дает максимальный контроль и одновременно максимальную ответственность. Нужно настроить SMTP, IMAP, TLS, антиспам, DNS, обратную DNS-запись, защиту от перебора паролей, обновления, резервное копирование и репутацию IP-адреса.
Поэтому поднимать собственный почтовый сервер только ради одного адреса info@domain.ru обычно нет смысла. Самостоятельная почта оправдана тогда, когда вы понимаете, зачем вам именно собственная инфраструктура и кто будет ее обслуживать.
SPF объясняет, кто имеет право отправлять письма от имени домена
Представим, что компания отправляет почту через один сервис, уведомления интернет-магазина через второй, а рассылку через третий.
Получателю нужно понять, действительно ли сервер, приславший письмо от example.ru, имеет отношение к этому домену.
Для этого используется SPF.
SPF публикуется в DNS и описывает серверы или инфраструктуру, которым разрешено отправлять почту от имени домена.
Здесь встречается типичная ошибка.
Владелец сначала настраивает корпоративную почту и создает SPF. Через несколько месяцев подключает сторонний сервис рассылок или CRM, которая тоже отправляет сообщения с адреса компании. Новый отправитель в SPF не добавляется.
В результате часть почты проходит проверку, а часть нет.
При этом не стоит создавать несколько независимых SPF-записей для одного домена в надежде, что получатель сам их объединит. Если почту отправляют разные системы, их нужно корректно учесть в общей политике SPF согласно документации используемых сервисов.
DKIM добавляет к письму цифровую подпись
SPF отвечает на вопрос о допустимом источнике отправки. DKIM решает другую задачу.
Почтовый сервер отправителя подписывает сообщение закрытым криптографическим ключом. В DNS домена публикуется соответствующий открытый ключ. Получающая сторона может проверить подпись.
Это помогает подтвердить связь сообщения с доменом и обнаружить определенные изменения письма после подписания.
Пользователю обычно не нужно самостоятельно генерировать все параметры DKIM. Почтовый сервис создает ключ или дает готовое значение DNS-записи, которое нужно добавить в управление доменом.
После этого сервис проверяет наличие записи и начинает подписывать исходящие сообщения.
DMARC связывает проверки в единую политику
SPF и DKIM появились раньше DMARC и могут использоваться самостоятельно. Но современная почтовая аутентификация на них не заканчивается.
DMARC позволяет владельцу домена задать политику обработки сообщений, которые не проходят необходимые проверки, а также получать отчеты.
Очень упрощенно логика выглядит так: домен сообщает получающей почтовой системе, как относиться к сообщениям, которые заявляют его в поле From, но не подтверждаются ожидаемым способом.
Политика может начинаться с режима наблюдения. Затем, когда владелец убедился, что все законные источники отправки настроены правильно, требования можно ужесточать.
Это важно делать аккуратно.
Если сразу включить строгую политику, забыв про интернет-магазин, CRM, форму обратной связи или сервис рассылок, можно начать блокировать собственную легитимную почту.
Почему письма с нового домена все равно могут попадать в спам
Настроили MX, SPF, DKIM и DMARC. Значит каждое письмо гарантированно попадет во входящие?
Нет.
Почтовая аутентификация является важным условием нормальной доставки, но не единственным.
Почтовые системы оценивают репутацию отправителя, жалобы пользователей, характер сообщений, техническое оформление, объемы и динамику отправки. Для собственного SMTP-сервера имеет значение репутация IP и корректная обратная DNS-запись.
Поэтому новый собственный почтовый сервер на дешевом VPS не обязательно будет доставлять письма лучше крупного специализированного сервиса.
Можно идеально настроить SMTP и получить IP-адрес с плохой предыдущей репутацией. Можно отправить десять тысяч одинаковых рекламных сообщений с совершенно нового домена. Можно купить сомнительную базу адресов и быстро испортить репутацию.
SPF и DKIM не превращают нежелательную рассылку в желательную.
Почта сайта и почта сотрудников не всегда должны отправляться одинаково
Сотрудник пишет клиенту из обычного почтового интерфейса. Это человеческая переписка.
Интернет-магазин отправляет подтверждение заказа. Сайт отправляет ссылку восстановления пароля. CRM рассылает уведомления. Маркетинговая система отправляет рекламную кампанию.
Все эти сообщения могут использовать один домен, но технически являются разными потоками почты.
На маленьком сайте допустимо отправлять системные уведомления через тот же почтовый сервис. По мере роста проекта становится полезно разделять транзакционную, корпоративную и маркетинговую отправку.
Это упрощает контроль репутации и диагностику. Если рекламная кампания вызвала много жалоб, она не должна по возможности мешать доставке критичного письма со ссылкой восстановления пароля.
Для небольшого бизнеса не нужно сразу строить сложную инфраструктуру. Но полезно понимать разницу между почтовым ящиком сотрудника и сервисом массовой или транзакционной отправки.
Можно ли создать адрес без отдельного почтового ящика
Да, если почтовый сервис поддерживает алиасы или переадресацию.
Например, сообщения на director@example.ru можно направлять в существующий ящик ivan@example.ru. Пользователю не обязательно проверять два отдельных входящих ящика.
Но переадресация и полноценный почтовый ящик не одно и то же.
Если нужно не только получать, но и постоянно отправлять письма с определенного адреса, лучше убедиться, что выбранный сервис корректно поддерживает такой сценарий и аутентификацию исходящей почты.
Особенно осторожно стоит относиться к схеме, когда письма принимаются на домен, пересылаются на бесплатный ящик, а ответы пытаются отправлять от имени домена через случайный SMTP. Такая конструкция может работать, но часто создает лишние сложности с SPF, DKIM и отображением отправителя.
Для бизнеса проще, когда корпоративные адреса обслуживаются одной понятной системой.
Что произойдет с почтой при переносе сайта на другой хостинг
Один из самых частых страхов при переезде: сейчас поменяем хостинг и перестанут приходить письма.
Если почта размещена отдельно, этого можно избежать.
Предположим, сайт example.ru находится на старом сервере, а почта работает через внешний корпоративный сервис. Для переноса сайта меняются A или AAAA-записи, которые направляют веб-трафик.
MX, SPF, DKIM и остальные почтовые записи при этом трогать не нужно.
После обновления DNS посетители начнут попадать на новый веб-сервер, а почта продолжит идти туда же, куда шла раньше.
Проблемы возникают, когда владелец при переезде не редактирует отдельную запись, а полностью заменяет DNS-зону или меняет NS-серверы и забывает перенести почтовые записи.
Сайт начинает работать, а MX исчезает.
Поэтому перед сменой DNS-провайдера полезно сохранить список всех существующих записей и воспроизвести нужные записи на новой стороне до переключения.
Нужно ли покупать отдельный домен для корпоративной почты
Обычно нет.
Если компания работает на example.ru, адрес name@example.ru выглядит естественно. Отдельный домен только для обычной переписки чаще добавляет путаницу.
Но крупные проекты иногда используют поддомены или отдельные домены для определенных потоков массовой почты. Это уже вопрос архитектуры и управления репутацией.
Для малого бизнеса важнее другое: зарегистрировать основной домен на надежный аккаунт, включить двухфакторную аутентификацию у регистратора и не допустить случайного окончания регистрации.
Потеря домена означает проблему не только с сайтом.
На этом домене находятся адреса электронной почты. Через них могут восстанавливаться пароли от CRM, социальных сетей, рекламных кабинетов и других сервисов.
Поэтому домен с корпоративной почтой становится частью системы доступа компании и требует соответствующего отношения к безопасности.
Как настроить доменную почту без лишней сложности
Для небольшой компании я бы не начинала с аренды VPS и установки собственного почтового сервера.
Сначала выбрала бы готового почтового поставщика или проверила возможности текущего хостинга.
Затем добавила домен в почтовый сервис и прошла подтверждение владения, если оно требуется.
После этого сервис выдаст необходимые DNS-записи. MX направит входящую почту на нужные серверы. SPF укажет разрешенные источники отправки. DKIM добавит механизм цифровой подписи.
DMARC лучше настраивать после того, как понятны все легитимные источники исходящих сообщений. Если письма отправляет не только почтовый ящик, но и сайт, CRM или рассылочный сервис, их нужно учесть.
После обновления DNS следует проверить не только входящую почту.
Отправьте сообщения на несколько внешних сервисов. Ответьте обратно. Проверьте папку со спамом. Посмотрите технические заголовки тестового письма и убедитесь, что SPF и DKIM проходят проверку.
Если сайт отправляет формы или уведомления, протестируйте их отдельно.
И только после этого переносите реальную рабочую переписку или объявляйте новые адреса клиентам.
Почему адрес на своем домене нужен не только ради солидности
Внешний вид действительно имеет значение.
Письмо с адреса manager@названиекомпании.ru проще связать с организацией, чем сообщение с бесплатного ящика, особенно если получатель впервые общается с компанией.
Но собственный домен дает не только красивую подпись.
Он позволяет сменить почтового поставщика, сохранив адреса сотрудников.
Сегодня example.ru обслуживает один сервис. Через три года компания решила перейти на другой. Меняются технические настройки DNS, но клиент продолжает писать на ivan@example.ru.
Если рабочая идентичность построена на адресе, принадлежащем стороннему бесплатному сервису, такой независимости нет.
Именно контроль над адресным пространством является главным преимуществом доменной почты.
Чего лучше не делать
Не используйте один общий пароль от info@domain.ru для десяти сотрудников.
Не отправляйте массовую рекламу через обычный корпоративный ящик.
Не удаляйте старые DNS-записи вслепую при переносе сайта.
Не создавайте собственный SMTP-сервер на VPS только потому, что кажется, будто так будет бесплатно.
Не оставляйте SPF и DKIM на потом, если сервис уже предоставляет готовые значения для настройки.
И не считайте успешную отправку одного тестового письма доказательством того, что корпоративная почта полностью настроена.
Нормальная почтовая система должна принимать сообщения, стабильно отправлять их крупным получателям, проходить аутентификацию и не зависеть от одного случайного пароля или человека.
Почта на своем домене проще, чем кажется
Для владельца небольшого сайта вся технология может свестись к нескольким действиям в панелях.
Вы выбираете почтовый сервис, подтверждаете домен, добавляете предложенные DNS-записи, создаете ящики и проверяете отправку.
Под капотом работают MX, SPF, DKIM, DMARC, SMTP, TLS и другие технологии. Знать каждую строку протокола не требуется.
Но понимать назначение основных элементов полезно.
MX отвечает за маршрут входящей почты. SPF сообщает о разрешенных отправителях. DKIM помогает проверить цифровую подпись сообщения. DMARC задает правила проверки домена отправителя и позволяет контролировать проблемы аутентификации.
Именно поэтому современная настройка корпоративной почты не заканчивается созданием адреса info@domain.ru.
Хорошая новость в том, что крупные почтовые сервисы большую часть сложности уже автоматизировали. Владельцу сайта остается правильно настроить DNS и не ломать эти записи при следующем переезде.
А собственный домен после этого становится не только адресом сайта. Он превращается в постоянную цифровую идентичность компании, которую можно переносить между хостингами и почтовыми платформами, не заставляя клиентов каждый раз запоминать новый электронный адрес.
