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

Если письма стартапа попадают в спам, проверьте не только наличие записи SPF, но и все каналы отправки. Составьте список почтового сервиса, системы продаж, рассылок и уведомлений; настройте для них разрешение на отправку и подпись DKIM, затем опубликуйте DMARC в режиме наблюдения. По рекомендациям Google для отправителей, письма от сторонних сервисов, не учтённых в разрешающей записи, чаще попадают в спам, а для прохождения общей проверки домен успешной аутентификации должен соответствовать домену видимого адреса.

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

Составьте карту законных отправителей

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

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

Обновите одну запись SPF

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

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

Включите подпись DKIM у каждого сервиса

Создайте ключ в настройках почтового сервиса или платформы рассылок и разместите выданную запись под указанным именем. Метка ключа называется селектором: у разных сервисов могут быть разные селекторы и отдельные записи, объединять ключи в одну строку не требуется. После обновления зоны убедитесь, что сервис начал подписывать именно исходящие письма; наличие записи с открытым ключом ещё не говорит о том, что подпись добавлена к сообщению.

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

Включите наблюдение DMARC

После настройки отправителей создайте текстовую запись по имени _dmarc вашего домена. Для условного домена example.com действующая спецификация протокола приводит наблюдающую запись вида v=DMARC1; p=none; rua=mailto:[email protected]. Замените адрес отчётов своим рабочим ящиком или адресом сервиса обработки отчётов. Значение p=none не просит получателя менять доставку из-за результата этой проверки; остальные его фильтры при этом продолжают работать.

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

Сверьте заголовки и отчёты перед ужесточением

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

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

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

Читайте также:

• Facebook помнит прошлую аудиторию: одной настройки приватности недостаточно
• WHOIS уже недостаточно: как проверить домен перед покупкой семью способами
• Курсы первой помощи: для работы одной онлайн-теории недостаточно