С февраля 2024 года Gmail и Yahoo начали требовать корректную настройку SPF, DKIM и DMARC для массовых отправителей, а в мае 2025-го аналогичные правила ввела Microsoft для Outlook.com, Hotmail и Live.com. Для компаний это уже не тонкая настройка почты, а базовая гигиена: без нее письма уходят в спам, а домен становится удобной мишенью для подделки.
Об этом пишет ZDNet, разбирая три DNS-механизма, которые отвечают и за доставляемость, и за защиту от спуфинга. Смысл простой: если почтовый сервер получателя не видит, что письмо действительно отправлено с разрешенного сервера, не было изменено по дороге и подпадает под понятную политику домена, шансы попасть во входящие резко падают.
Проблема знакома многим командам: письма уходят, а в ответ тишина. Часто дело не в копирайтинге, не в теме письма и не в очередном «слишком продажном» CTA, а в том, что домен не аутентифицирован. Для принимающей стороны это выглядит подозрительно: сервер видит письмо якобы от корпоративного адреса, но не получает доказательств, что отправитель действительно имеет право использовать этот домен. В такой ситуации письмо проще и безопаснее спрятать в папку со спамом, чем рисковать фишингом.
Каждый из трех механизмов закрывает отдельную дыру. SPF определяет, какие серверы вообще могут отправлять письма от имени домена. DKIM добавляет криптографическую подпись и позволяет проверить, что содержимое письма не меняли в пути. DMARC связывает эти проверки в единую политику: он объясняет получателю, что делать, если проверка не пройдена, и одновременно отправляет владельцу домена отчеты о том, кто и как рассылает почту от его имени. Ключевой момент здесь в том, что по отдельности эти инструменты полезны, но неполны. SPF не мешает злоумышленнику подделать отображаемый адрес отправителя, DKIM сам по себе не останавливает отправку с неавторизованного сервера, а без DMARC все это остается набором сигналов без понятного сценария реакции.
SPF, по сути, работает как белый список отправителей на уровне DNS TXT-записи. Владелец домена публикует запись с перечнем разрешенных платформ и серверов, а принимающая сторона сверяет с ней IP-адрес, с которого пришло письмо. Если компания отправляет почту только через Google Workspace, запись будет одной; если одновременно использует, например, Google Workspace и Microsoft 365, разрешенные сервисы нужно собрать в один SPF. И здесь у администраторов есть типичная ловушка: у домена должна быть только одна SPF TXT-запись. Вторая запись не усиливает защиту, а ломает проверку. Есть и техническое ограничение: SPF допускает не более 10 DNS lookup’ов, так что бесконтрольно раздувать список отправителей нельзя. Для стартапов и небольших компаний это обычно означает одно практичное правило: вести учет всех сервисов, которые шлют письма от имени домена, от корпоративной почты до CRM, рассылок и тикет-систем.
DKIM решает другую задачу. Почтовый сервис генерирует пару ключей: приватный хранится у отправителя, публичный публикуется в DNS. Исходящее письмо подписывается приватным ключом, а сервер получателя сверяет подпись с публичным. Если письмо по дороге изменили, проверка провалится. Для бизнеса это важно не только из-за безопасности, но и из-за нормальной доставки в реальных сценариях. Например, пересылка писем нередко ломает SPF, потому что письмо фактически приходит уже не с исходного сервера. DKIM в таких случаях обычно переживает форвардинг лучше, и письмо сохраняет шанс пройти проверку. Настройка здесь зависит от провайдера: где-то публикуется TXT-запись, где-то CNAME, а после добавления записи нужно отдельно включить подпись в панели администратора. ZDNet напоминает о банальной, но дорогой по последствиям детали: одна ошибка в имени хоста или значении записи превращает всю схему в фикцию. И да, DNS не обновляется мгновенно, так что на распространение изменений обычно закладывают 24-48 часов.
Самый недооцененный слой в этой тройке — DMARC. Именно он делает SPF и DKIM управляемыми. Базовая запись выглядит предельно скромно: версия протокола, политика и адрес, на который будут уходить агрегированные отчеты. На первом этапе обычно ставят политику p=none: она не просит принимающий сервер блокировать письма, зато показывает владельцу домена, что вообще происходит. Это полезно почти всегда, потому что в инфраструктуре компании нередко внезапно обнаруживаются старые маркетинговые платформы, forgotten SaaS-сервисы или подрядчики, которые все еще отправляют письма от имени домена и при этом не проходят аутентификацию. По сути, DMARC сначала работает как аудит, а уже потом как дубинка. После нескольких недель наблюдения политику можно ужесточать, переходя к quarantine или reject. Без этого шага домен остается уязвимым для имитации: злоумышленник может рассылать письма якобы от имени компании, а получатели будут видеть знакомый адрес в поле From.
Для русскоязычной IT-аудитории здесь важен не сам факт существования SPF, DKIM и DMARC — о них все слышали, — а то, что почтовые провайдеры окончательно перевели эту тему из разряда «когда-нибудь наведем порядок» в категорию обязательных требований. Это касается не только больших e-commerce-команд с миллионами писем, но и SaaS-компаний, агентств, HR-команд, продуктовых стартапов и B2B-продаж. Любой поток писем с собственного домена — от cold outreach и офферов кандидатам до чеков, алертов и onboarding-писем — завязан на то, доверяют ли домену почтовые системы. Если доверия нет, страдает уже не только open rate, а бизнес-процессы целиком: клиент не получает инвайт, кандидат не видит оффер, пользователь не дожидается письма для входа или подтверждения.
Отдельно показательно, что речь идет не о покупке нового продукта и не о внедрении «почтовой платформы следующего поколения», а о нескольких DNS-записях, которые многие компании откладывали годами. Именно поэтому тема так неприятно бьет по организациям: исправление обычно несложное, но вспоминают о нем после того, как продажи жалуются на молчание лидов, поддержка — на недоставленные уведомления, а безопасность — на риск поддельных писем от имени бренда. В 2026 году вопрос уже звучит не как «нужно ли нам настраивать SPF, DKIM и DMARC», а как «почему мы до сих пор не знаем, какие сервисы отправляют почту от нашего домена и проходят ли они проверку».
Порог входа в эту тему остается низким, а цена бездействия растет. По мере того как крупные почтовые платформы ужесточают требования, корпоративная почта все меньше прощает хаос в DNS и все хуже переносит инфраструктуру, собранную по принципу «работало же как-то раньше».
The post Почему письма компании уходят в спам и как это чинят SPF, DKIM и DMARC appeared first on iTech News.