Доменная почта, включенная в общий веб-хостинг, представляет собой распространенный риск для доставляемости у небольших компаний. При регистрации пакет кажется удобным, но его архитектура часто неблагоприятна для попадания во входящие. Через шесть месяцев ответы клиентов могут начать поступать в спам, а администратор не поймет причину, поскольку репутация общего IP-адреса не видна изнутри.
Многие используют доменную почту при веб-хостинге потому, что регистратор предложил пакет непосредственно во время оформления. Ловушка срабатывает, когда один клиент на общем IP попадает в блок-лист и у всех клиентов на этом IP на несколько дней или недель ухудшается попадание во входящие. Перенос почты к специализированному провайдеру с сохранением сайта на прежнем месте может занять около 30 минут.
В этом руководстве описаны сценарии отказа и способ их устранения. Сравнение с учетом размера небольшой команды приведено в статье о почтовом хостинге для малого бизнеса.
Что представляет собой доменная почта при веб-хостинге
Это функция почтового хостинга, которая входит в тарифы общего веб-хостинга. Провайдеры на основе cPanel, включая Bluehost, HostGator, Hostinger, хостинг GoDaddy и аналогичные сервисы, продают домен, сайт и почту одним пакетом. Почтовый сервер использует тот же IP-адрес, что ваш сайт и сайты сотен других клиентов.
У пакета есть архитектурные слабости по важным для попадания во входящие направлениям: общая репутация IP, слабая аутентификация по умолчанию, отсутствие прозрачности DMARC и объединенный DNS, который привязывает все уровни к одному поставщику. Удобство при регистрации скрывает возможные издержки доставляемости, проявляющиеся спустя месяцы.
Четыре проблемы пакетного решения
На доменную почту, включенную в общий веб-хостинг, влияют четыре типа проблем. Они носят архитектурный характер, а не сводятся к одной исправляемой настройке. Каждый из них снижает доставляемость или затрудняет миграцию, что администраторы редко учитывают при оценке кажущейся экономии пакета.
- Испорченная репутация общего IP. Один активный нарушитель приводит IP в блок-лист, и у всех клиентов может ухудшиться попадание во входящие.
- Слабая аутентификация по умолчанию. SPF представлен единой общей записью, DKIM может отсутствовать, а отчеты DMARC редко направляются в нужный ящик.
- Отсутствие прозрачности DMARC. Нельзя увидеть, кто подделывает домен, если пакет не направляет отчеты в контролируемый вами ящик.
- Привязка к поставщику при миграции. DNS, регистратор и почтовый хостинг принадлежат одному поставщику, поэтому уход часто требует сменить все три компонента.
Проблемы усиливают друг друга. Слабая аутентификация усугубляет недостатки общего IP. Без отчетов DMARC проблема обнаруживается позже. Привязка к поставщику не позволяет быстро уйти. Вместе эти четыре фактора объясняют, почему по мере роста пакетная доменная почта при веб-хостинге нередко показывает более слабые результаты.
Проблема 1: испорченная репутация общего IP
Первый архитектурный недостаток связан с репутацией общего IP. Исходящие письма отправляются с IP-адреса, который используется еще 100-500 клиентами. Если один из них рассылает спам, адрес может попасть в крупные блок-листы. Тогда попадание ваших писем во входящие ухудшится до снятия записи, что иногда занимает дни или недели.
Ущерб распределяется неравномерно. Клиент, из-за которого появилась запись, редко несет расходы на устранение последствий. Остальные клиенты того же IP теряют ответы и получают жалобы пользователей. Большинство поставщиков веб-хостинга не уведомляет затронутых клиентов о попадании в блок-лист заранее. Обычно проблему замечают по сокращению числа ответов и начинают расследовать. К этому моменту последствия могут накапливаться несколько дней или недель важной деловой переписки.
Проблема 2: слабая аутентификация по умолчанию
Вторая проблема заключается в слабой аутентификации по умолчанию. SPF публикуется как единая общая запись для отправителей всей платформы, и ее нельзя сузить до фактических отправителей вашего домена. DKIM часто полностью отсутствует, а при наличии ключ может редко меняться. DMARC зачастую вообще не публикуется.
Даже при хорошей репутации общего IP исходящие письма проходят слабую аутентификацию. Современные принимающие системы, включая требования Gmail к массовым отправителям и более строгие проверки выравнивания Microsoft, при большом объеме хуже оценивают неаутентифицированную почту. Оценка применяется к домену независимо от репутации IP, поэтому пакетные решения могут уступать специализированным даже на чистом общем адресе.
Проблема 3: отсутствие прозрачности DMARC
Отчеты DMARC помогают узнать, кто отправляет письма от имени вашего домена. Это законные отправители, которым нужна аутентификация, и злоумышленники, пытающиеся выдать себя за бренд. Если отчеты не поступают в контролируемый вами ящик, обе категории остаются невидимыми.
Большинство платформ пакетного веб-хостинга не предоставляет пользователю управление маршрутизацией отчетов DMARC. Нельзя увидеть подделку домена, если поток отчетов идет провайдеру, а не вам. Из-за этого проблемы могут накапливаться месяцами до обнаружения. Специализированные почтовые сервисы обычно направляют отчеты в назначенный для каждого домена ящик, обеспечивая видимость по умолчанию. Общий подход к аутентификации рассмотрен в статье о почте на собственном домене.
Проблема 4: привязка к поставщику при миграции
В пакетном решении DNS, регистратор и почтовый хостинг находятся у одного поставщика. Смена одного компонента часто требует менять остальные, из-за чего простое изменение MX-записи превращается в многонедельный проект миграции. Некоторые поставщики также берут $50-200 за ящик за помощь с переносом с платформы.
Из-за такой привязки администраторы остаются на пакетных решениях дольше, чем следовало бы. Стоимость миграции в виде времени, денег и сбоев для клиентов оказывается выше дополнительных затрат еще на один квартал. Накопление проблем доставляемости все равно может привести к миграции, но позже, чем при меньших препятствиях. Любой пакет, в котором один поставщик контролирует все три уровня, создает подобный риск.
Исправление за 30 минут
Проблемы пакетной доменной почты можно устранить, перенеся почту к специализированному провайдеру ящиков и оставив сайт на прежнем месте. Записи A и CNAME сайта не меняются. Обновляются только MX-записи, которые должны указывать на нового почтового провайдера. Стоимость нового ящика составляет $0-51/year.
Пошаговый процесс: зарегистрируйтесь в TrekMail, выбрав бесплатный Nano или Starter за $4/month. Добавьте домен в панели управления. Найдите раздел DNS-записей в cPanel веб-хостинга, который обычно называется «Zone Editor» или «DNS Manager». Замените MX-записи, сообщающие интернету, куда доставлять почту домена, значениями TrekMail. Опубликуйте записи SPF, DKIM и DMARC, сформированные мастером TrekMail. Отправьте тестовое письмо из нового ящика в Gmail, Outlook и Yahoo. Проверьте, что во всех трех заголовках указано PASS. На этом базовая настройка завершена. Многие администраторы справляются менее чем за 30 минут.
Роль TrekMail в решении
TrekMail обслуживает уровень почтовых ящиков, не управляя DNS, веб-хостингом или регистрацией домена. Платформа создает DNS-записи, которые нужно опубликовать у действующего DNS-провайдера. Сайт продолжает работать на прежнем веб-хостинге, а домен остается у текущего регистратора. Перемещается только почтовый уровень.
Ротация DKIM отдельно для каждого клиента, автоматическое управление SPF и маршрутизация отчетов DMARC предусмотрены по умолчанию. Архитектурная защита от четырех проблем пакета заложена в платформу и не требует отдельной настройки каждого механизма администратором. Сравнение стоимости с пакетом приведено в статье о ценах на корпоративную почту.
Следующие шаги
Решение для доменной почты, включенной в общий хостинг, достаточно простое: оставить сайт на месте, а почту перенести к специализированному провайдеру. Обновить нужно только MX и записи аутентификации. Это устраняет архитектурные причины четырех проблем пакетной почты, не затрагивая DNS сайта и регистратора.
Бесплатно протестируйте TrekMail Nano на странице trekmail.net/pricing. Карта не требуется, а в опубликованных сейчас условиях не указано автоматическое завершение пробного периода. Nano включает 10 доменов × 10 ящиков. Starter за $4/month при росте объема отправки расширяет лимит до 50 × 100.
К этим проблемам редко возвращаются, поскольку их цена не видна напрямую. Она выражается в потерянных ответах и более медленном общении с потенциальными клиентами, а не в денежных счетах. Переход к специализированному провайдеру способен показать, что такие издержки существовали. Некоторые администраторы сообщают о росте доли ответов и ускорении продаж в течение нескольких недель после миграции, но результат зависит от профиля рассылок и аудитории.
Диагностика проста: проверьте, приходят ли в контролируемый вами ящик сводные отчеты DMARC, то есть ежедневная информация об отправителях, заявляющих ваш домен. Если нет, у вас присутствует проблема 3, а остальные три также встречаются довольно часто. Миграция к специализированному провайдеру может решить все четыре задачи одновременно. Поставщики пакетной регистрации редко предупреждают о доставляемости, поскольку пакет приносит им прибыль. Администраторам приходится самостоятельно выявлять проблему с помощью отчетов DMARC или снижения доли ответов.
Для администраторов нескольких сайтов в одной учетной записи общего хостинга вопрос более срочный. Исходящая почта каждого сайта использует тот же IP и имеет схожие слабые места аутентификации. Специализированный провайдер с отдельной ротацией DKIM для клиентов разделяет репутацию брендов и помогает предотвратить распространение инцидента одного бренда на остальные в той же учетной записи.
Последнее замечание: регистратор, изначально продавший пакет, редко сам указывает на проблему доставляемости. Пакет выгоден, а уход создает препятствия. Администраторы должны обнаружить проблему сами по отчетам DMARC или снижению доли ответов. Поэтому исправление обычно инициирует клиент, а не поставщик. Если вы еще этого не сделали, установите календарное напоминание о ежеквартальной проверке отчетов DMARC.
