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

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

В такой ситуации хочется переписать тему письма, убрать ссылки, попросить оператора писать «живее». Иногда это помогает. Но сначала стоит проверить скучные вещи: SPF, DKIM, DMARC и обратный адрес.

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

Письмо может быть полезным и всё равно выглядеть как подмена

Для клиента письмо выглядит просто: от кого, тема, текст, кнопка «Ответить». Для почтового сервера там больше слоёв.

Есть видимый отправитель: например, support@shop.ru. Его видит клиент в почтовом ящике. Есть сервер, который реально отправил письмо. Это может быть ваш почтовый сервис, CRM, платформа поддержки или сторонняя рассылочная система. Есть технический адрес для возвратов, куда приходят ошибки доставки. Есть подпись письма, если она настроена.

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

Например, клиент видит письмо от support@shop.ru, а отправляет его сервер стороннего сервиса. Для человека это нормально: вы же подключили сервис поддержки. Для почтового сервера это вопрос: почему чужой сервер говорит от имени shop.ru и есть ли у него на это разрешение.

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

Тут важно не спорить с клиентом в духе «мы отправляли». Отправить письмо и доставить его во входящие — разные события. В поддержке важно второе.

SPF говорит, какие серверы имеют право отправлять от вашего домена

SPF — это DNS-запись домена. В ней перечисляют серверы и сервисы, которым разрешено отправлять письма от имени домена.

Если ваша поддержка пишет с адреса support@shop.ru, а письма фактически уходят через сервис поддержки, этот сервис должен быть указан в SPF. Иначе получающий сервер видит: домен один, отправляющий сервер другой, разрешения не найдено.

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

У SPF есть неприятная особенность: у домена должна быть одна SPF-запись. Не две записи рядом, не «одна для почты, одна для поддержки», а одна общая. Если разные подрядчики добавляли настройки в разное время, в DNS легко появляются две строки v=spf1.... Для части проверок это уже ошибка.

Цена исправления — нужно собрать все сервисы, которые отправляют письма от домена, и аккуратно объединить их в одну запись. Это не задача на «быстро скопировать строку из инструкции». Если забыть старый сервис рассылок, у него начнутся проблемы. Если оставить лишнее, вы разрешаете отправку там, где она уже не нужна.

Минимальная проверка такая: возьмите реальное письмо, которое попало в спам, откройте служебные заголовки и найдите результат SPF. Обычно он выглядит как spf=pass, spf=fail или spf=softfail. Дальше смотрите не только на слово pass, но и на домен, для которого прошла проверка. Иногда SPF проходит для технического домена сервиса, а не для вашего видимого домена. Для следующего шага это важно.

DKIM показывает, что письмо не переписали по дороге

DKIM — это подпись письма. Отправляющий сервис подписывает письмо приватным ключом, а получающий сервер проверяет подпись по публичному ключу в DNS.

Если упростить, DKIM отвечает на вопрос: «Это письмо действительно подписал тот домен, за который он себя выдаёт, и текст не меняли после отправки».

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

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

Ошибки здесь скучные, но частые:

• запись добавили не в тот домен;
• скопировали ключ с лишним пробелом или переносом;
• включили DKIM в сервисе, но не дождались обновления DNS;
• сервис подписывает письма доменом поставщика, а не вашим доменом;
• поменяли домен отправителя, но DKIM оставили старый.

Проверять DKIM лучше не по панели настроек, где всё может светиться зелёным, а по реальному письму. В заголовках ищите dkim=pass и параметр d=. Этот d= показывает домен подписи. Если клиент видит письмо от shop.ru, а подпись стоит от совсем другого домена, это не всегда авария, но для DMARC может быть проблемой.

И ещё один бытовой момент. Любые системы, которые меняют письмо после подписи, могут её ломать. Например, добавляют длинный дисклеймер, переписывают ссылки, вставляют баннер или меняют вложения. Если после такого DKIM становится fail, надо решать, где именно письмо должно подписываться: до этих изменений или после них.

DMARC связывает проверки и задаёт правила

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

Именно DMARC часто объясняет ситуацию «настройки вроде есть, а письма всё равно недоверенные». SPF может проходить, DKIM может проходить, но не для того домена, который стоит в поле From. Для DMARC важно выравнивание: чтобы домены в проверках были связаны с доменом видимого отправителя.

Пример. Клиент видит письмо от support@shop.ru. SPF проходит для mail.service-example.com. DKIM тоже подписан service-example.com. Формально проверки не пустые, но для домена shop.ru они не подтверждают авторство. DMARC может считать такое письмо не прошедшим проверку.

У DMARC есть политика. Самые частые варианты:

• p=none — только наблюдать и получать отчёты;
• p=quarantine — подозрительные письма можно отправлять в спам;
• p=reject — подозрительные письма можно отклонять.

Начинать обычно безопаснее с p=none. Это не «боевой режим», зато он помогает увидеть, кто отправляет письма от вашего домена и какие потоки не проходят проверки. Если сразу поставить жёсткую политику, можно случайно ударить по своим же письмам: поддержке, счетам, рассылкам, уведомлениям из личного кабинета.

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

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

Обратный адрес часто ломает картину незаметно

Под «обратным адресом» в разговорах обычно смешивают две разные вещи.

Первая — Reply-To: куда попадёт ответ клиента, если он нажмёт «Ответить». Вторая — Return-Path: технический адрес, куда почтовые серверы присылают ошибки доставки. Клиент чаще видит первое, почтовые серверы активно используют второе.

Если Reply-To неправильный, клиент отвечает в пустоту или на адрес, который никто не читает. Например, письмо пришло от поддержки, а ответ уходит на no-reply@.... С точки зрения доставки письмо могло быть нормальным, но диалог всё равно сломан.

Если Return-Path живёт на чужом домене и никак не связан с видимым отправителем, это может мешать проверкам и отчётности. Плюс вы можете не видеть отказы доставки. Оператор уверен, что ответ ушёл, а почтовый сервер получателя вернул ошибку на технический ящик поставщика, до вашей команды она не дошла.

Проверка обратных адресов занимает меньше времени, чем спор о текстах писем. Отправьте тестовый ответ из поддержки на внешний ящик, откройте оригинал письма и сравните четыре вещи: видимый From, Reply-To, Return-Path и домен DKIM-подписи. Если они все разные, это не всегда ошибка, но точно повод разобраться.

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

Не начинайте с текста письма, пока не проверили техническую базу

Да, содержание письма тоже влияет на спам-фильтры. Подозрительные ссылки, тяжёлые вложения, одинаковые шаблоны, резкие формулировки, слишком много картинок — всё это может ухудшать доставку. Но если SPF, DKIM, DMARC и адреса не сходятся, переписывание текста похоже на покраску двери, которая не закрывается.

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

Чтобы не утонуть, разделите проверку на четыре вопроса:

• SPF: разрешён ли отправляющий сервис в DNS домена;
• DKIM: подписываются ли реальные письма и каким доменом;
• DMARC: совпадают ли проверки с видимым отправителем и какая стоит политика;
• обратные адреса: туда ли уходят ответы клиентов и ошибки доставки.

На каждый вопрос нужен не скриншот из настроек, а реальное письмо. Лучше то самое, которое попало в спам. В нём видна правда: какой сервер отправил, что прошло, что не прошло, какой домен подписал письмо и куда ушёл бы ответ.

Завтра можно сделать простую вещь: попросить клиента или коллегу переслать проблемное письмо как оригинал, открыть его заголовки и выписать четыре строки — SPF, DKIM, DMARC, From/Reply-To/Return-Path. Если где-то fail, домен не тот или ответ уходит на нерабочий адрес, у вас появляется не догадка, а конкретная задача для почтового администратора или сервиса поддержки.