Сайт на одном сервере, почта на другом: почему теряются заявки

Довольно распространённая схема: сайт компании лежит на одном хостинге, а корпоративная почта на домене работает через отдельный почтовый сервис. Схема правильная и в большинстве случаев предпочтительная — но именно на ней ломается едва ли не самая болезненная вещь для бизнеса: уведомления о заявках с сайта перестают приходить. Причём ломается тихо, и обнаруживают это, как правило, через недели.
Разберём, зачем вообще разводить сайт и почту, что при этом настраивается, где чаще всего возникают проблемы и как проверить, что письма с сайта действительно доходят.
Зачем разводить сайт и почту
Раньше почту обычно держали там же, где сайт, — на том же хостинге. Сегодня это делают всё реже, и на то есть причины.
Почта на хостинге обычно слабая. Небольшой объём ящиков, нет нормального веб-интерфейса, плохие фильтры нежелательной почты, нет календарей и совместной работы. Для одного ящика сойдёт, для команды — нет.
Доставляемость. Письма, отправленные с общего хостинга, чаще попадают в нежелательную почту. Причина в том, что на одном сервере сидят сотни сайтов, и репутация адреса отправителя общая: если сосед рассылает спам, страдают все.
Надёжность. Если хостинг лёг, у вас пропадает и сайт, и почта одновременно. При разведении вы теряете только одно.
Смена хостинга. Переезд сайта на другой хостинг не затрагивает почту, если она отдельно. Это заметно упрощает жизнь.
Возможности. Отдельные почтовые сервисы дают общие календари, диски, работу с телефона, антивирусную проверку вложений.
Поэтому нормальная схема сегодня выглядит так: домен зарегистрирован у регистратора, сайт лежит на хостинге, почта работает через отдельный почтовый сервис, а система доменных имён связывает всё это вместе.
Как это устроено технически, простыми словами
Чтобы понимать, что где ломается, нужно представлять общую картину. Постараемся без лишних подробностей.
У домена есть набор записей — это как справочник, который говорит всему интернету, куда обращаться по разным вопросам.
Записи адреса сайта говорят: если кто-то хочет открыть сайт по этому домену, вот адрес сервера, где он лежит.
Записи почты говорят: если кому-то нужно доставить письмо на адрес этого домена, вот сервер, который его принимает.
Записи отправителя говорят принимающим серверам: письма от имени этого домена имеют право отправлять вот эти серверы. Есть несколько таких записей, они работают вместе и определяют, поверят ли вашему письму или отправят в нежелательную почту.
Служебные записи используются почтовыми сервисами для подтверждения прав на домен и для настройки программ.
Все эти записи хранятся в одном месте — там, где обслуживается система доменных имён вашего домена. Обычно это панель регистратора, но может быть и панель хостинга, и панель почтового сервиса.
Ключевой момент, который порождает большинство проблем: записи должны редактироваться в одном месте. Если управление именами переключили на хостинг, а вы правите записи в панели регистратора, ваши правки просто ни на что не влияют. Это самая частая причина непонятных ситуаций «я всё настроил, но не работает».
Что ломается чаще всего
Проблема первая: сайт отправляет письма сам от себя. Форма на сайте отправляет уведомление, и сервер хостинга подписывает письмо вашим доменом. Но записи отправителя разрешают отправку только почтовому сервису, а не хостингу. Принимающая сторона видит несоответствие и отправляет письмо в нежелательную почту или отклоняет вовсе.
Это происходит сразу после того, как почту перевели на отдельный сервис, но обнаруживается позже — когда заметили, что заявки перестали приходить.
Проблема вторая: письмо себе же. Сайт отправляет уведомление на ящик, который находится на том же домене. Часть настроек в такой ситуации работает нестандартно, и письмо может остаться на локальном сервере хостинга вместо того, чтобы уйти на нормальный почтовый сервис. Ящик на хостинге при этом никто не читает — все читают почту в почтовом сервисе. Письма копятся в пустоте.
Проблема третья: остались старые записи почты. При переводе почты на новый сервис не удалили старые записи. В результате часть писем уходит на старый сервер, часть на новый. Заявки приходят через раз, и понять логику невозможно.
Проблема четвёртая: записи правят не в том месте. Об этом сказали выше. Признак — правки не вступают в силу вообще, сколько ни жди.
Проблема пятая: не настроены записи отправителя для сайта. Даже если сайт отправляет письма правильным способом, его надо явно указать среди разрешённых отправителей. Иначе всё уходит в нежелательную почту.
Проблема шестая: хостинг ограничил отправку. Многие хостинги ограничивают количество отправляемых писем или блокируют отправку, если заподозрили рассылку. Уведомления просто перестают уходить, часто без предупреждения.
Проблема седьмая: почта переехала, а на сайте старый адрес. В настройках сайта указан адрес получателя, которого больше нет.
Проблема восьмая: изменения ещё не вступили в силу. Записи системы доменных имён обновляются не мгновенно — от нескольких минут до суток и больше. Часть проблем «ничего не работает» решается ожиданием.
Как правильно организовать отправку писем с сайта
Практическая рекомендация, которая закрывает большинство проблем: сайт не должен отправлять письма самостоятельно средствами хостинга. Он должен отправлять их через ваш почтовый сервис, авторизуясь как обычный почтовый клиент.
Что это значит на практике. В настройках сайта указывается не «отправлять напрямую», а параметры подключения к почтовому серверу: адрес сервера, порт, имя пользователя, пароль, тип защищённого соединения. Для этого в почтовом сервисе заводится отдельный ящик — например, специальный адрес для уведомлений — и его данные прописываются в настройках сайта.
Что это даёт. Письма уходят от имени вашего домена через сервер, который имеет на это право. Записи отправителя совпадают. Письма нормально доходят и не попадают в нежелательную почту. При смене хостинга ничего не ломается. Ограничения хостинга на отправку перестают вас касаться.
В ХостСМС такая настройка делается в параметрах системы: указываются данные подключения к почтовому серверу, и все уведомления начинают уходить через него. Аналогичные настройки есть в большинстве систем управления.
Важная деталь: адрес отправителя должен принадлежать вашему домену и совпадать с ящиком, через который идёт отправка. Отправка от имени постороннего адреса — прямой путь в нежелательную почту.
Вторая важная деталь: адрес получателя уведомлений лучше делать не тем же самым, что и адрес отправителя. Письмо самому себе иногда обрабатывается странно.
Как проверить, что всё работает
Проверять надо не один раз при настройке, а регулярно. Порядок такой.
Отправьте тестовую заявку с сайта. Заполните форму как обычный посетитель и отправьте.
Проверьте, пришло ли письмо. Смотрите не только во входящие, но и в папку нежелательной почты. Если письмо там — настройки отправителя не в порядке.
Проверьте содержимое письма. Все ли поля читаются, нет ли нечитаемых символов вместо русского текста, виден ли номер телефона целиком.
Отправьте на внешний адрес. Продублируйте уведомление на ящик в другом почтовом сервисе — не на своём домене. Так вы увидите, как ваши письма выглядят со стороны. Часто оказывается, что внутри своего домена всё доходит, а снаружи попадает в спам.
Проверьте с задержкой. Иногда письма доходят, но через несколько часов. Для заявок это почти то же самое, что не дойти.
Проверьте все формы. Не только главную. Форма на странице услуги, форма обратного звонка, форма в всплывающем окне — каждая может быть настроена отдельно.
Проверьте уведомления в мессенджер, если они есть. Дублирование заявок в Телеграм — хорошая практика, но и оно ломается.
Заведите регламент: раз в месяц ответственный сотрудник отправляет тестовую заявку с каждой формы и отмечает результат. Две минуты работы предотвращают потери, которые измеряются месяцами выручки.
Что делать, если письма перестали приходить
Порядок диагностики.
Сначала выясните, отправляются ли письма вообще. В журнале сайта или в системе управления обычно видно, была ли попытка отправки и чем она закончилась. Если ошибка при отправке — проблема в настройках подключения к почтовому серверу или в блокировке со стороны хостинга.
Если отправка проходит успешно, а письмо не приходит — проблема на пути доставки. Проверьте папку нежелательной почты. Проверьте, тот ли адрес получателя указан в настройках. Проверьте, существует ли ящик получателя и не переполнен ли он.
Если письма доходят внутри домена, но не доходят на внешние адреса — дело в записях отправителя.
Если ничего из этого не помогло, проверьте, где вообще обслуживаются записи вашего домена, и посмотрите текущие почтовые записи. Часто обнаруживается, что там прописано что-то давно неактуальное.
И параллельно — обязательно: настройте дублирование заявок. Уведомление должно уходить не только письмом, но и в мессенджер или сохраняться в системе учёта клиентов на сайте. Тогда поломка почты не означает потерю заявок. Это самая надёжная страховка, и стоит она недорого.
Продвижение 3 в 1 и уведомления
Стоит сказать, как это связано с потоком обращений в целом.
Мы всегда выстраиваем работу так, чтобы обращения приходили из трёх точек: из поиска (обычного и нейропоискового), из карточки в Яндекс.Справочнике и из карточки в 2ГИС. У каждой точки свой способ обращения, и уведомления по ним устроены по-разному.
С сайта заявка приходит письмом или в мессенджер — и это то, что ломается чаще всего. С карточек люди обычно звонят напрямую, и здесь ничего сломаться не может, зато обращения нигде не фиксируются, если специально не считать.
Практический вывод: настройте учёт по всем трём каналам, а не только по сайту. Цели в Яндекс.Метрике на формы и на нажатие номера телефона, отдельные номера для карточек или коллтрекинг, регулярный просмотр статистики карточек в Яндекс Бизнесе и в кабинете 2ГИС. Тогда провал по одному каналу становится виден сразу — а не через два месяца, когда кто-то случайно заметит, что писем с сайта давно не было.
И не оценивайте ситуацию по позициям сайта в выдаче: они персонализированы, у разных людей разные, и о работе сайта не говорят ничего. Смотрите на обращения и их источники.
Дублирование уведомлений: страховка, которая стоит копейки
Раз почта — самое хрупкое звено, разумно не полагаться на неё одну. Правильная схема выглядит так: заявка с сайта попадает сразу в несколько мест.
Сохранение на сайте. Каждая заявка записывается в базу и видна в панели управления сайтом. Это самое надёжное: даже если все уведомления сломались, заявки не потеряны, их можно найти и обработать. В ХостСМС такая возможность есть штатно, и её обязательно нужно включить.
Уведомление в мессенджер. Сообщение в Телеграм в рабочий чат приходит мгновенно и не зависит от почтовых настроек. Для многих компаний это стало основным способом получения заявок, а почта — резервным.
Уведомление на несколько адресов. Не один ящик, а два-три — руководителя, менеджера, общий. Тогда отпуск или увольнение одного человека не приводит к потере обращений.
Передача в систему учёта. Заявка сразу создаёт запись в амоСРМ или БитриксФ24. Плюс не только в надёжности, но и в том, что ничего не теряется в переписке и видна вся история работы с клиентом.
Автоматическое письмо клиенту. Подтверждение о приёме заявки. Оно решает две задачи: снимает тревогу человека и заодно служит проверкой — если клиенты перестали получать подтверждения, значит, с отправкой писем что-то не так.
Настройка занимает несколько часов один раз. Стоимость потерянной за месяц заявки обычно выше.
Короткий перечень для проверки
Знаете ли вы, где обслуживаются записи вашего домена? Настроена ли отправка писем с сайта через ваш почтовый сервис, а не напрямую с хостинга? Совпадает ли адрес отправителя с ящиком, через который идёт отправка? Прописан ли сайт среди разрешённых отправителей? Не остались ли старые почтовые записи? Отличается ли адрес получателя уведомлений от адреса отправителя? Дублируются ли заявки в мессенджер или в систему учёта? Когда вы последний раз отправляли тестовую заявку с каждой формы?
Если хотя бы на три вопроса нет уверенного ответа — стоит проверить, не теряете ли вы заявки прямо сейчас.
Разобраться в настройках почты и уведомлений можно и самостоятельно, но проще, когда рядом есть человек, который делал это десятки раз. Специалисты компании «Сайты Профессионально» бесплатно проверят, доходят ли письма с вашего сайта, посмотрят настройки домена и почты и подскажут, что поправить, чтобы ни одна заявка не терялась по дороге.
Хотите получить бесплатную диагностику сайта?
Получите бесплатную экспресс-диагностику за 24 часа. Проверим ошибки, сбои, скорость, безопасность и скрытые ошибки — пришлём отчёт с рекомендациями.
- Скорость загрузки и мобильная версия
- Уязвимости, вирусы, взломы
- Битые ссылки, дубли, SEO-ошибки
- Статус домена, SSL, хостинга
Популярные решения наших клиентов:

До 10 часов работ в мес.
Ежедневная диагностика
Продление домена
Продление хостинга/сервера

До 40 часов работ в мес.

До 100 часов работ в мес.
