Письма с сайта уходят в спам: почему это происходит и как починить

Письма попадают в спам тихо, и в этом вся беда: сервер отчитался «сообщение отправлено», в админке заявка есть, почтовая служба получателя молча положила письмо в папку «Спам» — и никто никому не сообщил. Через неделю выясняется, что клиент так и не увидел счёт, а вы не увидели три заявки. Ни ошибки, ни уведомления, ни строчки в логе, которую владелец сайта стал бы читать.

Ниже — разбор по шагам: почему так происходит, что означают три записи в настройках домена, как за пять минут прочитать служебную часть письма и узнать, прошло оно проверки или нет, и что сделать с формами, чтобы заявки перестали теряться. Если руки не доходят, есть продвижение и техническая поддержка сайта — почтовую часть я всегда проверяю первой, потому что от неё зависят деньги, а не позиции.

Две разные беды, которые путают

Беда первая: ваши письма не доходят клиентам. Сайт отправляет подтверждение заказа, счёт, ссылку на восстановление пароля, уведомление о статусе — и всё это оседает в спаме у получателя. Здесь проблема на вашей стороне: почтовые службы не верят, что письмо действительно отправлено от имени вашего домена.

Беда вторая: заявки с сайта не доходят вам. Человек заполнил форму, увидел «спасибо», а письмо с его телефоном не пришло или лежит в спаме вашего собственного ящика. Здесь виновата та же механика, но последствия дороже: вы не знаете, сколько обращений потеряли, потому что их просто нет ни в одном отчёте. Отдельный разбор, где именно теряются обращения на пути от кнопки до менеджера, есть в материале про то, как заявки с сайта теряются.

Проверить, какая у вас беда, можно за три минуты. Оставьте заявку на своём сайте на адрес в двух разных почтовых службах и посмотрите, куда придут письма. Потом отправьте себе письмо с адреса на своём домене из обычного почтового клиента. Если тестовая заявка легла в спам, а письмо из клиента дошло нормально — проблема в том, как отправляет сайт, а не в домене целиком.

Почему сайт отправляет письма «от себя» и им не верят

Стандартный движок сайта отправляет почту простой командой средствами сервера. Сервер честно формирует письмо, в поле «От кого» ставит адрес вида info@вашдомен.ру и отдаёт его дальше. Формально всё верно. Проблема в том, что принимающая сторона видит картину иначе: письмо от имени вашего домена пришло с сервера, который к вашему домену никакого отношения не имеет.

Для почтовой службы это ровно тот признак, по которому вычисляют подделку: мошенник делает то же самое — берёт чужой домен в поле отправителя и шлёт письмо со своего сервера. Отличить одно от другого можно только по тому, разрешил ли владелец домена этому серверу отправлять письма от его имени. Разрешение записывается в настройках домена. Нет записи — нет разрешения, и письмо уходит в спам не по злому умыслу, а по инструкции.

Отсюда вывод, который снимает половину вопросов: правка текста письма и отказ от картинок не помогут, пока принимающая сторона не может подтвердить, что письмо действительно ваше. Содержание проверяют вторым шагом, подлинность — первым.

SPF, DKIM и DMARC: что решает каждая запись

SPF — список серверов, которым разрешено отправлять почту от имени вашего домена. Вы перечисляете в записи адреса и сервисы, которые имеют право слать письма с вашего домена. Принимающая сторона смотрит, откуда пришло письмо, сверяется со списком и делает вывод. В конце записи стоит механизм all с квалификатором, и он задаёт, что делать с письмами со всех остальных серверов: знак + означает pass (разрешено), — — fail (не разрешено), ~ — softfail (вероятно не разрешено), ? — neutral (явного утверждения нет). Пример значения для домена, почта которого обслуживается почтовым сервисом: v=spf1 ip4:адрес-вашего-сервера include:_spf.имя-почтового-сервиса ~all.

Две технические ловушки. Первая: у домена не должно быть нескольких SPF-записей — если проверка находит больше одной подходящей записи, результатом будет permerror, постоянная ошибка, требующая вмешательства того, кто управляет зоной. Подключая второй сервис рассылки, нельзя просто добавить вторую строчку: механизмы include объединяются в одну запись. Вторая: количество механизмов и модификаторов, требующих обращения к DNS (include, a, mx, ptr, exists, redirect), ограничено десятью. Превысили — снова permerror.

DKIM — цифровая подпись письма. Отправляющий сервер подписывает письмо закрытым ключом, а открытый ключ публикуется в настройках домена отдельной TXT-записью с именем вида селектор._domainkey и значением вроде v=DKIM1; k=rsa; p=…. Принимающая сторона берёт открытый ключ и проверяет подпись. Яндекс Почта формулирует это прямо: подлинность домена отправителя проверяется по наличию цифровой подписи DKIM, а сама подпись подтверждает, что письмо не было перехвачено и изменено после отправки. Установить подпись может только администратор сервера — из панели сайта это не делается.

DMARC — правило, что делать с письмами, не прошедшими проверку. Запись создаётся с именем _dmarc у вашего домена. В ней вы задаёте политику: p=none — владелец домена не просит принимающую сторону предпринимать каких-либо особых действий в отношении доставки; p=quarantine — владелец домена хочет, чтобы не прошедшие проверку письма считались подозрительными; p=reject — владелец домена хочет, чтобы такие письма отклонялись, причём отклонение должно происходить прямо во время SMTP-сессии.

Главное в DMARC — выравнивание идентификаторов. Сообщение проходит проверку DMARC, если хотя бы один из механизмов аутентификации даёт результат pass и делает это на идентификаторе, который выровнен с доменом из поля «От кого». То есть недостаточно, чтобы SPF просто прошёл: домен, на котором он прошёл, должен совпадать с доменом отправителя (в мягком режиме — по организационному домену, в строгом — точно). Именно поэтому письма через сторонний сервис могут иметь зелёный SPF и при этом валиться по DMARC.

И приятный бонус: в записи DMARC указываются адреса для отчётов — rua для сводных отчётов о потоках писем и ruf для подробных отчётов о письмах, не прошедших проверку. Даже политика p=none с адресом для отчётов даёт вам то, чего не даёт ничто другое: вы начинаете видеть, кто и откуда шлёт письма от имени вашего домена.

Как прочитать письмо и понять, прошло ли оно проверки

Теория закончилась, дальше практика. Отправьте письмо с сайта на свой ящик в любой крупной почтовой службе, откройте письмо и найдите пункт меню вроде «Свойства письма», «Показать оригинал» или «Исходное сообщение». Откроется служебная часть — та самая, которую обычно не видно.

Ищите строку Authentication-Results. Это стандартный заголовок, который принимающий сервер добавляет к письму после проверок. Внутри будут результаты по каждому методу: spf=pass, dkim=pass, dmarc=pass — и это то, что вы хотите увидеть. Значения расшифровываются так: pass — проверка пройдена, fail — не пройдена, softfail — мягкий отказ, neutral — политика ничего не утверждает, none — записи нет вообще, permerror — постоянная ошибка, temperror — временная.

Три самых частых диагноза по этой строке. spf=none — SPF-записи у домена нет, начинать нужно с неё. dkim=none — письмо не подписано, значит, отправка идёт мимо настроенного почтового сервиса. spf=permerror — записей несколько или превышен лимит обращений к DNS, надо чистить.

Симптом	Что проверить	Что настроить
Письма с сайта в спаме у всех получателей	Строку Authentication-Results в тестовом письме	SPF с адресом отправляющего сервера, затем DKIM
Письма из почтового клиента доходят, а с сайта — нет	Каким способом отправляет движок и от какого адреса	Отправку через почтовый сервис по SMTP с авторизацией
spf=permerror	Сколько TXT-записей начинается с v=spf1 и сколько в них include	Одна запись SPF, не больше десяти обращений к DNS
dkim=none	Есть ли TXT-запись с открытым ключом и подписывает ли сервер письма	DKIM на стороне почтового сервиса и запись в зоне домена
spf=pass, но dmarc=fail	Совпадает ли домен в поле «От кого» с доменом, на котором прошёл SPF	Выравнивание: отправка от адреса на своём домене, DKIM от своего домена
Заявки не приходят вообще, ни в спам, ни во «Входящие»	Логи отправки на сервере и адрес получателя в настройках формы	Дублирование заявок в базу сайта и в мессенджер

Почему отправка через сервер хостинга — частая причина

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

Второй слой проблемы — требования к отправителю. Принимающие службы ожидают, что рассылающий хост имеет постоянный адрес с корректно настроенным обратным DNS-запросом, то есть PTR-записью. На общем хостинге обратная запись указывает на служебное имя хостера, а не на ваш домен, и совпадения нет.

Третий слой — само поле «От кого». Требование почтовых служб формулируется однозначно: отправитель из поля «От кого» должен полностью соответствовать адресу пользователя, с данными которого производится авторизация на сервере. Сайт, отправляющий письма служебными средствами сервера, ни под каким пользователем не авторизуется вообще.

Правильное решение одно и оно недорогое: настроить отправку писем сайта через почтовый сервис по SMTP с авторизацией под реальным ящиком на вашем домене. Тогда письмо уходит с инфраструктуры, которая имеет и SPF, и DKIM, и нормальную репутацию, а поле «От кого» совпадает с тем, под кем авторизовались. Для сайтов на распространённых движках это делается настройкой, для самописных — правкой кода отправки; такие доработки входят в доработку сайта и занимают обычно час.

Что сделать с формами, чтобы заявки не терялись

Даже с идеальными записями остаётся риск: письмо — это единственный экземпляр заявки, и если он потерялся, восстановить нечего. Поэтому почта не должна быть единственным каналом.

Шаг	Что сделать	Как проверить, что работает
1	Включить сохранение всех заявок в базу сайта	В админке есть список обращений с датой и текстом
2	Настроить отправку писем сайта через SMTP с авторизацией	В тестовом письме dkim=pass и spf=pass
3	Добавить дубль заявки в мессенджер или таск-трекер	Тестовая заявка приходит двумя путями одновременно
4	Отправлять уведомления на ящик на своём домене, а не на бесплатный	Адрес получателя в настройках формы — корпоративный
5	Завести правило в почте: письма с сайта не попадают в спам	Фильтр создан на адрес отправителя, а не на слово в теме
6	Раз в месяц сверять число заявок в базе сайта и в почте	Цифры совпадают; расхождение — сигнал о потерях

Отдельно про сами формы. Чем больше полей, тем выше шанс, что человек бросит заполнение на середине, и тогда потеря произойдёт ещё до всякой почты. Какие поля действительно нужны, а какие только мешают, я разбирал в материале про то, что каждое лишнее поле формы заявки стоит вам клиентов.

Репутация домена и что её портит

Записи в домене — пропуск на входе. Репутация решает, пустят ли вас после проверки пропуска: она копится месяцами и рушится за день.

Рассылка по купленной базе. Самый быстрый способ угробить домен. Люди, которые не подписывались, жмут «Это спам», и дальше страдают уже все ваши письма, включая счета постоянным клиентам.

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

Отсутствие отписки. В массовом письме должен быть заголовок list-unsubscribe, оформленный по стандарту, а сама отписка должна отрабатывать быстро — в требованиях указано, что процесс не должен занимать более десяти минут.

Взломанный сайт. Классика: через дыру в движке ставят скрипт, который рассылает мусор с вашего сервера от вашего домена. Владелец узнаёт об этом, когда письма перестают доходить вообще. Как закрывать такие дыры, я описывал в материале про то, как защитить сайт от взлома.

Когда это не сработает и когда нужен специалист

Честный список ситуаций, в которых инструкция выше проблему не закроет.

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

Вы не управляете зоной домена. Без доступа к настройкам домена ни одна из трёх записей не появится. Бывает, что доступ остался у подрядчика, которого не найти. Заодно проверьте, все ли записи домена в порядке в принципе: как они роняют сайт целиком, разобрано в материале про то, почему домен не работает, а хостинг жив.

Изменения ещё не разошлись. После правки записей нужно подождать: в документации почтовых сервисов прямо указано, что обмен данными о новых записях между серверами в интернете может занять до 72 часов. Проверять результат через десять минут бессмысленно.

Инструкция закрывает типовой случай: один домен, один сайт, одна почта. Сложности начинаются, когда писем несколько потоков — сайт, бухгалтерия, рассылка, CRM, — и каждый идёт со своей инфраструктуры. Тогда SPF упирается в лимит обращений к DNS, выравнивание DMARC ломается на одном из потоков, а ужесточение политики до p=reject без предварительного разбора отчётов просто перестаёт доставлять часть вашей же переписки. Цена ошибки тут высокая и мгновенная: не «просели позиции», а «клиенты не получают счета». Если у вас именно такая картина, разбирать её лучше с человеком, который видел десятки таких конфигураций, а не методом подбора на живой почте.

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

Можно ли обойтись одной записью SPF и не возиться с остальными

Частично поможет, но этого мало. Требования почтовых служб к массовым отправкам формулируются жёстче: все сообщения должны быть подписаны с помощью DKIM, и также для домена должна быть настроена SPF-запись. DMARC при этом рекомендуется как дополнительная мера, которая проверяет, что DKIM и SPF принадлежат отправителю, и формирует отчёты о попытках подделки.

Что ставить в DMARC для начала

Начинайте с p=none и адресом для сводных отчётов. Эта политика не просит принимающую сторону предпринимать особых действий по доставке — она нужна, чтобы месяц-другой посмотреть, откуда реально уходят письма от вашего домена. Ужесточать до quarantine и reject имеет смысл, только когда в отчётах не осталось легитимных потоков, которые не проходят проверку.

Нужно ли что-то менять, если почта и сайт на разных сервисах

Это как раз правильная схема. Важно, чтобы в SPF были перечислены все серверы, которые реально отправляют письма от имени домена: и почтовый сервис, и сервер сайта, если он шлёт напрямую. И чтобы записей SPF при этом осталась ровно одна.

Где посмотреть, не рассылает ли мой домен спам без моего ведома

В отчётах, которые приходят на адрес из записи DMARC. Сводные отчёты показывают потоки писем от имени вашего домена, включая те, о которых вы не знали. Это единственный способ увидеть подделку до того, как о ней сообщат клиенты.

Коротко

Сначала определите, какая у вас беда: ваши письма не доходят клиентам или заявки с сайта не доходят вам. Лечение разное, а жалоба звучит одинаково.

Почтовая служба сначала проверяет подлинность и только потом содержание: пока не подтверждено, что письмо от вашего домена, переписывать текст бессмысленно.

SPF отвечает на вопрос «кому разрешено слать письма от моего имени», DKIM — «действительно ли письмо не подменили по дороге», DMARC — «что делать, если проверки не прошли, и куда прислать отчёт».

Запись SPF у домена должна быть ровно одна, а обращений к DNS внутри неё — не больше десяти. Нарушение любого из двух условий даёт permerror, и проверка не проходит.

Откройте служебную часть тестового письма и найдите строку Authentication-Results. Три слова pass в ней стоят дороже любых догадок о том, почему письма не доходят.

Заявка не должна существовать в одном экземпляре. Сохраняйте обращения в базу сайта и дублируйте в мессенджер — тогда потеря письма перестаёт быть потерей клиента.

Если писем несколько потоков, записи правились несколько раз разными людьми, а отчёты DMARC показывают отправителей, которых вы не узнаёте, — это уже не настройка на вечер, а разбор инфраструктуры. Приходите на консультацию: посмотрим вашу зону домена, тестовые письма и логи отправки и составим порядок действий, при котором ничего не отвалится по дороге.

Официальные источники: требования Яндекс Почты к рассылкам, RFC 7208 (SPF), RFC 7489 (DMARC).