Почта на домене Tilda: как подключить корпоративную почту

Почта вида info@example.ru не является функцией Tilda. Tilda может обслуживать сайт и, при необходимости, DNS-зону домена, а сами почтовые ящики работают у отдельной почтовой службы. Это может быть Яндекс 360, VK WorkSpace, Google Workspace, Microsoft 365, Zoho Mail, почта регистратора или другой сервис с поддержкой собственного домена.

Поэтому настройка начинается не с выбора кнопки в Tilda, а с понимания архитектуры: где зарегистрирован домен, где находятся его NS-серверы, кто управляет DNS, какой сервис принимает входящую почту и какие системы отправляют письма от имени домена.

Как связаны домен, Tilda, DNS и почта

Сайт и почта не обязаны находиться у одного поставщика. Например, сайт может работать на Tilda, DNS - в Cloudflare или у регистратора, а почта - в Microsoft 365. Другой вариант: сайт и DNS работают через Tilda, а почта - в Яндекс 360. Оба сценария нормальны.

Сначала определите, где находится DNS-зона

Главная причина неудачной настройки - запись добавили не туда. Домен может быть куплен у Reg.ru, но его NS указывать на Tilda. В этом случае изменение MX в панели Reg.ru ничего не даст: интернет будет читать зону Tilda.

Если домен делегирован на Tilda, в активной зоне используются ns1.tildadns.com и ns2.tildadns.com. Дополнительные MX и TXT можно добавлять в управлении доменом Tilda. Инструкция Tilda по DNS.

Если DNS остается у регистратора, Cloudflare или другого DNS-хостинга, почтовые записи добавляются там. Сам сайт при этом продолжает работать на Tilda через записи, которые показаны в Настройки сайта → Домен. Способы подключения домена к Tilda.

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

Какие DNS-записи отвечают за почту

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

Ограничение DNS Tilda, которое влияет на выбор почтового сервиса

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

Если выбранный почтовый сервис требует CNAME или SRV, не нужно отказываться от Tilda как от платформы сайта. Оставьте сайт на Tilda, а DNS перенесите в службу, где доступны все нужные типы записей. Затем пропишите для сайта актуальные A-записи из настроек проекта Tilda.

Какие почтовые сервисы можно использовать с Tilda

Tilda не привязывает домен к одному почтовому поставщику. Выбор зависит от инфраструктуры компании и набора DNS-записей, который требуется конкретному сервису.

Яндекс 360 для бизнеса

Для Яндекс 360 стандартная схема состоит из подтверждения домена, MX для входящей почты, SPF и DKIM для исходящей. В текущей документации Яндекса для базовой настройки указаны MX mx.yandex.net., SPF и индивидуальный DKIM-ключ. Актуальная первоначальная настройка Яндекс 360.

Если DNS находится на Tilda, все необходимые базовые записи помещаются в поддерживаемые Tilda типы MX и TXT. После подключения создаются пользователи, адреса и, при необходимости, алиасы.

Не копируйте DKIM из чужого примера: публичный ключ создается для конкретного домена. SPF также нужно адаптировать, если кроме Яндекса от имени домена отправляют CRM, сервис рассылок или другая система.

VK WorkSpace

VK WorkSpace также использует MX, SPF, DKIM и рекомендует DMARC. Текущая документация сервиса ведет настройку по цепочке подтверждение домена → почтовые DNS-записи → пользователи. Настройка почтовых записей VK WorkSpace.

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

Google Workspace

Google Workspace можно использовать с сайтом на Tilda независимо от того, где расположен сам сайт. Для новых организаций текущая справка Google указывает один MX smtp.google.com с приоритетом 1. Старые аккаунты могут продолжать работать с прежним набором MX, начинающимся с aspmx, и Google не требует менять его, если почта работает. Текущая настройка MX Google Workspace.

Это хороший пример того, почему значения нужно сверять с первичным источником. На 2 октября 2026 года справка Tilda по почте все еще показывает прежний набор из пяти MX Google, тогда как актуальная документация Google для новых подключений использует smtp.google.com. Справка Tilda по доменной почте.

После MX настраиваются SPF и DKIM. Google отдельно рекомендует учитывать в SPF все системы, которые отправляют письма от имени домена, включая CRM, рассылки и автоматические отправители. Настройка SPF Google Workspace и настройка DKIM.

Microsoft 365 и Outlook на своем домене

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

Отдельный нюанс - DKIM. Для собственного домена Microsoft 365 использует CNAME-записи. Документация Microsoft по DKIM. Если DNS делегирован на Tilda и в панели доступны только MX/TXT, полноценную рекомендуемую конфигурацию Microsoft 365 лучше делать через внешний DNS-хостинг с поддержкой CNAME.

Сам сайт от этого не переносится с Tilda. Меняется только место управления DNS.

Zoho Mail

Zoho Mail поддерживает почту на собственном домене и несколько способов подтверждения, включая TXT и CNAME. Подтверждение домена в Zoho Mail. Для приема почты после создания пользователей меняются MX-записи. Настройка доставки в Zoho Mail.

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

Как выбрать сервис, а не просто скопировать DNS

Для небольшого сайта на Tilda критерий выбора обычно не в том, у кого проще MX. Сравнивать нужно рабочий сценарий:

• сколько сотрудников и общих адресов нужно;
• нужны ли календарь, документы, видеовстречи и совместная работа;
• есть ли уже корпоративная экосистема Microsoft, Google, Яндекс или VK;
• какие CRM, системы поддержки и службы рассылок отправляют письма от имени домена;
• нужны ли архив, аудит, юридический поиск по данным или расширенное администрирование;
• какие типы DNS-записей требует выбранная служба;
• где юридически и технически доступен сервис для компании;
• как будет выполняться резервирование и перенос данных.

Если почта нужна только ради адреса info@domain.ru, сервис регистратора может быть достаточным. Если почта является рабочей инфраструктурой команды, имеет смысл выбирать весь набор инструментов и администрирования, а не только цену одного ящика.

SPF: перечислите всех реальных отправителей

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

Для одного домена не нужно публиковать несколько независимых SPF-записей. Разрешенные источники объединяются в одну корректную политику. Google и Microsoft отдельно указывают на это правило. Также SPF имеет ограничение на DNS-поиски, поэтому бесконечно добавлять include нельзя.

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

DKIM: подпись создается для конкретного сервиса

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

Не путайте это с SPF: несколько DKIM-записей с разными селекторами - нормальная ситуация, а несколько независимых SPF для одного домена - ошибка.

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

DMARC: не начинайте сразу с reject

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

Жесткая политика до инвентаризации всех отправителей может заблокировать нормальные письма из CRM, рассылки, система поддержки или другой системы. Сначала настройте SPF и DKIM, соберите данные, проверьте все источники и только после этого усиливайте политику. Microsoft прямо рекомендует постепенный переход к более строгому DMARC. Рекомендации Microsoft по DMARC.

Как менять MX без потери входящих писем

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

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

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

Почта на домене и формы Tilda - две разные системы

Создание адреса info@example.ru не подключает его к формам автоматически. В Tilda нужно отдельно выбрать приемщик данных формы и убедиться, что он активирован для нужного проекта.

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

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

Почему нельзя удалять все TXT-записи перед настройкой

В DNS одного домена TXT может использоваться сразу несколькими независимыми системами: SPF, DKIM, DMARC, подтверждением Google Search Console, Яндекс Вебмастера, CRM, платежного сервиса или другой интеграции.

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

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

Почему изменения видны не сразу

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

Если проверка не проходит сразу:

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

Диагностика по симптомам

Что настроить после запуска

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

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

Можно ли подключить к Tilda любую почту на своем домене?

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

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

Нет. Домен может оставаться у текущего регистратора, DNS - у него же или в Cloudflare, сайт - на Tilda, а почта - у отдельной почтовой службы.

Повредит ли смена MX сайту?

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

Можно ли одновременно использовать Яндекс 360 и Google Workspace на одном домене?

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

Нужно ли настраивать DMARC сразу?

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

Если домен куплен в Tilda, где добавлять почтовые записи?

Управление MX и TXT доступно в разделе домена Tilda. Если выбранный почтовый сервис требует дополнительные CNAME или SRV, DNS нужно перенести в службу DNS, которая поддерживает такие записи.

Итоговый проверочный список

1. Понятно, где зарегистрирован домен и где находятся его активные NS.
2. Сохранена копия текущей DNS-зоны.
3. Выбран почтовый сервис с учетом нужных функций и типов DNS-записей.
4. Домен подтвержден в почтовой службе.
5. Все пользователи и обязательные адреса созданы до смены MX.
6. MX взяты из текущей панели выбранной службы.
7. SPF содержит все реальные источники отправки и опубликован одной политикой.
8. DKIM включен и проходит проверку.
9. DMARC настроен с учетом всех отправителей.
10. Сайт продолжает открываться после изменений DNS.
11. Проверены входящие письма с нескольких внешних сервисов.
12. Проверена отправка на Gmail, Яндекс, Mail.ru/корпоративные адреса или другие реальные направления бизнеса.
13. Если идет перенос, старая служба не отключена до стабилизации маршрутизации и переноса данных.
14. Если доменный адрес получает формы Tilda, отправлена отдельная тестовая заявка.

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