сделать главной
добавить в закладки
Почему письма попадают в спам: SPF, DKIM и DMARC простыми словами
Коротко. Почему письма попадают в спам? Почтовый сервис может не подтвердить отправителя, не доверять репутации домена или сервера либо считать сообщения нежелательными для адресата. SPF, DKIM и DMARC помогают проверить право отправки от имени домена, но не гарантируют попадания во «Входящие». Начать стоит с конкретного недошедшего письма и системы, которая его отправила.
Как сервис решает, что перед ним спам
У фильтра несколько задач: распознать подделку отправителя, оценить источник и содержание сообщения, учесть жалобы получателей. Правильная подпись не означает, что адресат подписывался на рекламу. Проверьте, чтобы тема не вводила в заблуждение, а ссылки были заметны и понятны: это требования Gmail. Точная формула классификации не раскрывается, поэтому универсального набора слов, который обеспечит доставку, нет.
Сначала выясните, что произошло. Если сервер отказал в приёме, нужен отчёт о недоставке и ответ сервера. Если сообщение есть в «Спаме», изучают его служебные заголовки и репутацию отправителя. Когда письма нет нигде и отчёта тоже нет, администратор должен проследить отправку по журналу системы: отсутствие во входящих ещё не доказывает срабатывание спам-фильтра.
Почему счета и массовые рассылки разделяют
Счёт по конкретной сделке, уведомление о статусе заказа и рекламная подборка решают разные задачи. Для служебного сообщения важно, чтобы адресат вовремя получил нужный документ; для рекламы — чтобы он хотел получать именно такую рассылку и мог от неё отказаться. При общей отправке разбирать жалобы, отказы и нагрузку приходится вперемешку.
В требованиях к честным рассылкам Яндекс рекомендует отделять отправляющий хост от обычной корреспонденции, а если это невозможно — использовать другое доменное имя, в том числе поддомен. На практике деловую переписку можно оставить на корпоративной почте, уведомления выделить в отдельный поток, рекламу отправлять через предназначенный для неё сервис. У каждого источника надо проверить аутентификацию и обработку ошибок.
Массовой бывает и отправка документов из учётной программы. Пример того, как в 1С:УХ отделили подготовку таких писем от отправки через очередь и фоновое задание, описан в материале https://dp-consulting.ru/articles/ot-pryamoy-otpravki-k-nezavisimoy-sisteme-pochtovoy-rassylki-na-baze-1s-uh/. Такая организация позволяет управлять отправкой, но настройки домена и проверку доставки всё равно нужно выполнять отдельно.
SPF, DKIM и DMARC: что настраивают и что проверяют
DNS — система записей, через которую публикуют сведения о домене. Для почтовой аутентификации в ней размещают правила и открытые ключи. Но одной публикации мало: отправляющая программа должна пользоваться подходящим сервером и подписывать сообщения.
SPF: разрешён ли сервер отправки
SPF позволяет указать, какие серверы вправе отправлять почту с техническим обратным адресом в данном домене. Этот адрес используется при передаче письма и может отличаться от видимого поля «От кого». Поэтому успешная проверка SPF сама по себе ещё не подтверждает домен, который видит получатель.
Типичная ошибка — учесть корпоративную почту, но забыть сайт, CRM или бухгалтерскую программу. Другой промах — добавить для нового сервиса вторую отдельную SPF-запись на том же имени домена. Разрешённых отправителей объединяют в одну политику; параметры берут из документации реально используемых платформ, а не из случайного примера.
DKIM: верна ли подпись
DKIM добавляет к сообщению криптографическую подпись. Отправляющая система использует закрытый ключ, а принимающая получает открытый ключ из DNS и проверяет подписанные части письма. DKIM не шифрует текст и не подтверждает, что содержание безопасно.
Для каждого отправляющего сервиса проверяют его собственную настройку DKIM. Опубликованный ключ бесполезен, если программа вообще не подписывает письма или пользуется другим ключом. Проверять нужно сообщение, прошедшее реальный путь отправки.
DMARC: связан ли результат с полем «От кого»
DMARC сопоставляет домен в видимом адресе отправителя с доменом успешной проверки SPF или DKIM. Достаточно одного из этих механизмов с нужным соответствием доменов. При мягком режиме соответствия допустим общий организационный домен, при строгом требуется точное совпадение. Просто увидеть слово pass рядом с чужой подписью недостаточно.
Политика p=none не просит применять ограничительные меры DMARC; p=quarantine просит считать не прошедшие DMARC письма подозрительными, p=reject — отклонять их. Итоговое решение остаётся за принимающей стороной. Для начала разумен режим наблюдения с получением агрегированных отчётов: адрес их приёма задают параметром rua.
Перед ужесточением политики найдите все законные источники и устраните ошибки. Иначе под ограничение могут попасть ваши же счета из редко запускаемой программы. Отчёты помогают увидеть отправляющие серверы и результаты проверок, но не показывают, в какую папку попало каждое письмо.
Репутация почтового домена и IP
Домен — имя, с которым связана почта компании, а IP — адрес сервера отправки. Репутацию проверяют по обоим направлениям. На общем IP поведение других отправителей может влиять на доставку ваших писем; сервис рассылок не отменяет этой зависимости. До подключения стоит выяснить, как он контролирует общий пул и показывает отказы.
Отдельный домен или поддомен помогает организовать разные потоки, но считать его гарантией защиты основной переписки нельзя. Новому отправителю тоже нужны корректные настройки и ожидающие писем адресаты. Объём увеличивают постепенно, наблюдая за ответами серверов и жалобами; универсального срока восстановления репутации нет.
Согласие получателя: что важно для рекламы
Техническая настройка не заменяет разрешения на рекламу. Для рекламной рассылки по электронной почте нужно заранее получить согласие адресата, иметь возможность его доказать и сразу прекратить отправку по требованию получателя (часть 1 статьи 18 закона № 38-ФЗ «О рекламе»). Открытый адрес на сайте компании сам по себе такого согласия не подтверждает.
Практически полезно сохранять, когда, каким способом и на какую рассылку подписался человек. В каждом рекламном письме нужен понятный работающий способ отказа: это также требование почтовых сервисов. Не добавляйте получателя счёта в рекламную базу автоматически и не превращайте служебное уведомление в рекламную подборку под прежним названием.
Как проверить настройки: чек-лист для компании
Попросите администратора или подрядчика проверить не только домен, но и каждую систему отправки. Результат удобнее принять в виде перечня источников с тестовыми письмами и объяснением обнаруженных ошибок.
- Собрать отправителей. Корпоративная почта, сайт, CRM, учётная программа, сервис рекламы. Для каждого записать назначение писем, сервер отправки, ответственного и домен в поле «От кого».
- Отправить реальные тесты. Сформировать письмо в каждой системе и проверить его на ящиках разных провайдеров. Тест из почтовой программы сотрудника не проверяет отправку из бухгалтерской базы.
- Посмотреть результаты аутентификации. В Gmail на компьютере открыть письмо и выбрать «Показать оригинал» в меню рядом с кнопкой ответа. Проверить SPF, DKIM и DMARC; администратору — заголовок Authentication-Results, добавленный принимающим сервером, и соответствие доменов.
- Сверить DNS с работающими системами. Убедиться, что SPF учитывает нужные серверы без второй отдельной политики, а DKIM-подписи проверяются. При собственной почтовой инфраструктуре проверить также обратную запись PTR, прямую DNS-запись и защищённую передачу TLS.
- Разобрать отказы и подписку. Сохранить ответ сервера при недоставке. При подтверждённом отсутствии адреса прекратить отправку на него; отдельно проверить согласия, работающую отписку и исключение отказавшихся из рекламной базы.
- Проверить отчёты после исправлений. Повторить тесты из тех же систем, изучить DMARC-отчёты и доступную статистику провайдера. В Google Postmaster Tools видны репутация и жалобы по письмам на личные адреса Gmail, но при небольшом объёме данных может не быть. Пустая панель не означает, что всё исправно.
Проверку стоит повторять после подключения нового сервиса или смены сервера. Задача закрыта, когда понятны результаты по каждому источнику и есть наблюдение за ошибками.
Вопросы и ответы
Почему письма компании уходят в спам после настройки всех записей?
Аутентификация подтверждает использование домена, но фильтры учитывают и другие сигналы. Проверьте жалобы, состав базы, репутацию домена и IP, содержание письма. Убедитесь также, что записи использует именно проблемная система отправки.
Можно сразу включить p=reject?
Без проверки всех отправителей это рискованно: законные сообщения с ошибками DMARC могут отклоняться. Начните с наблюдения и исправления источников, затем переходите к ограничительной политике.
Переход на сервис рассылок решит проблему?
Он может упростить отправку и сбор статистики. При этом домен нужно настроить, согласия — проверить, а отказы — обрабатывать. Передавать эти задачи сервису стоит с понятными критериями проверки результата.
Для руководителя полезный итог проверки — понятная карта отправителей и подтверждённая работа каждого из них. Если счета, уведомления и реклама проверяются отдельно, легче найти причину сбоя и оценить результат исправления.
Источники
- Google, «Руководство для отправителей писем».
- IETF, RFC 7208: протокол SPF.
- IETF, RFC 6376: подписи DKIM.
- IETF, RFC 9989 и RFC 9990: DMARC и агрегированные отчёты.
- Google Workspace, «Рекомендуемый порядок внедрения DMARC».
- Google, «Как получить подробные сведения о письме из заголовка» и «Какие панели доступны в Postmaster Tools».
- Яндекс Почта, «Отправить много писем», раздел «Требования Яндекса к честным рассылкам».
- Федеральный закон № 38-ФЗ «О рекламе», часть 1 статьи 18; текст в системе КонсультантПлюс.