Когда не приходят уведомления с Тильды на почту, я в первую очередь смотрю не на текст письма, а на то, дошла ли заявка вообще до сервера. За полтора десятка проектов на Tilda эта жалоба клиентов встречалась чаще любой другой технической проблемы конструктора, и в подавляющем большинстве случаев причина одна из четырёх: письмо ушло в спам, в форме указан не тот адрес, почтовый сервер получателя блокирует домен Тильды или заявка вообще не отправилась из-за конфликта скриптов на странице. Разберу каждую причину по порядку и покажу, как проверить и починить без обращения в техподдержку.
Проверка на стороне Тильды: заявка дошла до сервера или нет
Первый шаг перед разборками с почтой: открыть страницу с формой в редакторе Тильды, зайти в настройки нужного блока и открыть вкладку «Заявки» (в некоторых версиях панели она называется «CRM»). Там хранятся все отправленные данные формы независимо от того, ушло письмо или нет, потому что Tilda сохраняет заявку на своих серверах отдельно от email-рассылки.
Если запись в списке есть, а письма нет, проблема в доставке письма, и дальше разбираем именно её. Если записи нет вообще, дело не в почте, а в самой форме. Чаще всего это конфликт кастомного JS-скрипта на странице: счётчик, виджет проверки телефона или сторонняя валидация перехватывает событие submit и не даёт форме уйти на сервер Тильды. Я видел такое на трёх проектах подряд, где в форму добавляли скрипт валидации номера без учёта того, что вызывать preventDefault нужно только при ошибке ввода, а не при каждой отправке.
Проверить легко: открыть консоль браузера (F12, вкладка Network) и отправить тестовую заявку. Должен уйти POST-запрос на forms.tildacdn.com с ответом 200. Если запроса нет вообще или он падает с ошибкой, значит проблема на уровне скриптов страницы, а не почты.
Спам-фильтры и почтовые сервисы: где чаще всего теряются письма
Tilda отправляет уведомления с системного адреса вида notifications@tilda.ws или form@tilda.cc, а не с домена вашего сайта. Почтовые сервисы видят несовпадение между именем отправителя и реальным отправляющим сервером и на автомате отправляют письмо в папку «Спам», особенно если получатель раньше никогда не переписывался с этим адресом.
На практике у клиентов на Яндекс 360 для бизнеса и Mail.ru письма с Тильды пропадают заметно чаще, чем на Gmail, из-за более жёстких антиспам-правил у этих провайдеров. Проверить стоит не только папку «Спам», но и «Промоакции» в Gmail, куда системные письма тоже иногда попадают.
| Почтовый сервис | Насколько агрессивно фильтрует письма Тильды | Что сделать |
|---|---|---|
| Gmail | Редко отправляет в спам | Добавить notifications@tilda.ws в контакты |
| Яндекс 360 для бизнеса | Часто, особенно на новых доменах | Добавить домен tilda.ws в белый список в панели администратора |
| Mail.ru | Часто | Создать правило фильтрации «никогда не в спам» |
| Корпоративная почта на своём домене (Exchange, Google Workspace) | Зависит от политики DMARC получателя | Обратиться к IT-администратору компании |
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Ошибки в настройках самой формы: пять типовых промахов
Настройки уведомлений в Тильде привязаны не к сайту целиком, а к конкретному блоку формы на конкретной странице. На сайте из 10-20 посадочных страниц с отдельными формами захвата это создаёт путаницу, и вот пять причин, которые я нахожу чаще всего:
- Опечатка в поле «Куда отправлять»: вместо info@company.ru стоит inbo@company.ru или лишний пробел в конце адреса
- Настроена одна форма, а клиент тестирует другую: форма в шапке сайта и форма в попапе на карточке товара это разные блоки с разными получателями
- Превышен лимит адресов в поле получателей: Tilda ограничивает 5 email на одну форму
- Переключатель отправки уведомлений случайно выключен при копировании блока с другой страницы
- На клонированной странице остался email сотрудника, который уже не работает в компании
При разборе жалобы на пропавшие уведомления я всегда прохожу по всем формам сайта вручную, а не только по основной форме обратной связи. На интернет-магазинах на Тильде отдельные формы «Купить в один клик» на карточках товаров нередко настроены на почту, которую никто не проверяет уже полгода.
SPF, DKIM и корпоративная почта: когда дело не в спаме, а в блокировке
Отдельная история, когда письмо не долетает вообще, даже до папки «Спам». Корпоративные почтовые серверы с жёсткой политикой DMARC могут молча отклонять письма с внешних доменов, если заголовок отправителя не совпадает с записью SPF. В этом случае письмо просто не появляется нигде, ни во «Входящих», ни в спаме, потому что сервер получателя отбрасывает его на своей стороне ещё до доставки в ящик.
Проверить это со стороны клиента Тильды невозможно, поэтому я прошу IT-администратора компании внести домены tilda.ws и tilda.cc вместе с диапазоном отправляющих IP в список разрешённых отправителей. Параллельно полезно временно указать в форме резервный адрес на Яндексе или Gmail и посмотреть, доходит ли письмо туда: если да, проблема точно на стороне корпоративного сервера.
Стоит иметь в виду, что у стандартных форм Тильды нет встроенного SMTP-реле для отправки с домена компании: письма всегда уходят с системного адреса конструктора. На тарифе Business доступны вебхуки, которые позволяют забирать данные заявки на свою сторону и уже оттуда отправлять письма через собственную почту.
Резервные каналы доставки заявок вместо одного email
После того как разобрались со спамом и настройками форм, я всё равно не советую клиентам полагаться на один email как единственный канал получения заявок: слишком многое здесь зависит от почтовых провайдеров, на которые повлиять нельзя. Схема, которую я обычно собираю на проектах с ощутимым потоком заявок, такая: форма Тильды отправляет данные через вебхук, дальше сценарий в n8n забирает их и разводит по нескольким каналам одновременно, уведомление менеджеру в Telegram через aiogram-бота, создание сделки в amoCRM или Bitrix24, и дублирующее письмо с домена компании вместо общего адреса Тильды, что само по себе снимает большинство проблем со спам-фильтрами.
Настройка такой связки требует доступа к вебхукам и написания кастомного скрипта под конкретную форму, я делаю такие интеграции под ключ, подробнее про разработку и доработку скриптов для Тильды можно посмотреть в разделе услуг. Даже без вебхуков вкладка «Заявки» в панели Тильды остаётся рабочим резервом: данные там сохраняются всегда, и менеджер может проверить их вручную, если письмо не пришло, хотя для потока в десятки заявок в день это, конечно, не решение, а временная подстраховка.
От лендинга до интернет-магазина
Сайт / Tilda
от 30 000 ₽
Подробнее →Частые вопросы
Как проверить, что заявка вообще пришла на сайт, если письма нет?
Откройте панель Тильды, перейдите на страницу с формой, зайдите в настройки блока и откройте вкладку «Заявки». Если запись там есть, значит форма отработала и проблема именно в доставке письма, а не в самом сайте.
Почему уведомления с Тильды попадают в спам?
Письма отправляются с системного адреса вида notifications@tilda.ws, а не с домена вашего сайта, и почтовые сервисы часто помечают такие письма как подозрительные из-за несовпадения отправителя. Помогает добавление этого адреса в белый список ящика.
Можно ли настроить отправку уведомлений через свою почту вместо адреса Тильды?
В стандартных формах встроенного SMTP-реле нет, письма всегда уходят с системного адреса. Отправку через собственный домен можно организовать через вебхук на тарифе Business и внешний сценарий, который заберёт данные и отправит письмо со своей почты.
Что делать, если ни один email не получает уведомления, а форма отправляется?
Проверьте вкладку «Заявки» в панели, чтобы убедиться, что данные сохраняются. Затем проверьте спам-папку и попробуйте временно указать резервный адрес на другом почтовом сервисе. Если и туда письмо не приходит, вероятна блокировка на стороне корпоративного сервера, и тогда стоит настроить резервное уведомление в Telegram или CRM, чтобы не зависеть от одного канала.