Defaults.Exposed › Исправления › SPF (Sender Policy Framework — список разрешённых отправителей)

Как исправить SPF (Sender Policy Framework — список разрешённых отправителей)

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

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

Во что это может вам обойтись

Мошенник присылает вашему клиенту счёт «от вас» со своими банковскими реквизитами и получает оплату. Вы узнаёте об этом спустя недели, когда клиент спрашивает, где его товар, — и теперь под ударом ваша репутация, а возможно, и ваша ответственность.
Ваши предложения, счета и ответы тихо оседают в папке спам у клиентов, потому что крупные почтовые сервисы не могут подтвердить, что письма действительно от вас. Сделки остывают, а вы так и не понимаете почему.
Мошенник выдаёт себя за владельца или финансиста и пишет сотрудникам с просьбой срочно оплатить счёт или купить подарочные карты — письмо действительно выглядит так, будто пришло с вашего домена, поэтому кто-то платит.
Служба ИТ или безопасности крупного потенциального клиента проверяет ваш домен, не видит защиты отправителя и либо отказывается от вас, либо требует всё исправить до подписания, — что стоит вам сделки или недель задержки.
Вы думаете, что защищены, раз запись SPF существует, — но она настроена в режиме «мягкого отказа» без какого-либо принуждения, либо тихо сломана, поэтому поддельные письма всё равно проходят.

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

Коротко

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

SPF (Sender Policy Framework) — это решение. Это одна текстовая строка в настройках вашего домена, перечисляющая, каким почтовым сервисам действительно разрешено отправлять письма от вашего имени. Принимающие почтовые сервисы — Gmail, Outlook, все — сверяются с этим списком, прежде чем решить, настоящее ли письмо. Нет списка или он слабый — им не на что опереться.

Эта страница охватывает две вещи, которые обе должны быть верны: существует ли запись SPF вообще и настроена ли она достаточно строго, чтобы реально выполнять свою задачу.

Чем это может вам обойтись

Вот повседневные, реальные способы, которыми отсутствующая или слабая запись SPF превращается в утекающие деньги и доверие. Мы никогда не называем настоящий бизнес — это закономерности, которые мы видим по всем данным.

Подмена счёта. Преступник присылает одному из ваших клиентов письмо, которое выглядит ровно как от вас, с правдоподобным счётом и своим банковским счётом. Ваш клиент его оплачивает. Первое, что вы слышите, — напоминание с вопросом, где заказ. И вот у вас разъярённый клиент, ушедшие к преступнику деньги и тяжёлый разговор о том, кто несёт убыток.
Афера «от лица директора/финансиста». Кто-то пишет вашему бухгалтеру «от» владельца: «Небольшая просьба — можешь провести этот платёж до конца дня?» Поскольку письмо действительно выглядит пришедшим с вашего домена, оно ни у кого не вызывает подозрений. Деньги уходят из компании.
Невидимый налог на доставляемость. Ваши предложения и счета начинают оседать в спаме у клиентов, потому что Gmail и Yahoo не могут подтвердить, что они правда от вас. Вы не получаете ни отскока, ни ошибки — сделки просто затихают. Вы теряете бизнес и даже не видите, как это происходит.
Потерянный контракт. Отдел закупок или безопасности более крупного клиента в рамках подключения проводит базовую проверку вашего домена. Они не видят аутентификации отправителя и помечают вас как риск. В лучшем случае вы судорожно всё чините под давлением сроков; в худшем — они выбирают конкурента, который проверку прошёл.
Волна отравления бренда. Ваш домен используют в фишинговой кампании против широкой публики. Люди, которые обожглись, теперь не доверяют ни одному письму с вашим именем — поэтому даже ваши настоящие предложения и продления игнорируют или жалуются на них.

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

Что это на самом деле

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

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

v=spf1 include:_spf.google.com include:sendgrid.net -all

Простыми словами это читается так: «Настоящая почта от нас идёт с серверов Google и SendGrid — отклоняйте всё остальное, что выдаёт себя за нас».

Две части, важные для вашей оценки:

Существует ли запись? Это главное (этот критерий весит больше любой другой отдельной проверки почты). Нет записи — значит, получателям не с чем сверяться, и подделка открыта настежь. Здесь есть и тонкий режим отказа: если у вашего домена две или более записей SPF, по правилам все они недействительны — то есть SPF у вас фактически нет, хотя выглядит, что есть.
Достаточно ли строга политика? Запись может существовать, но всё равно быть беззубой. Окончание — механизм «all» — это инструкция получателям:
- -all (жёсткий отказ) — отклонять всё, чего нет в списке. Самое строгое. Полный балл.
- ~all (мягкий отказ) + DMARC в режиме reject — современная рекомендуемая настройка. Защита эквивалентна жёсткому отказу, без риска отскоков легитимной пересланной почты. Полный балл.
- ~all + DMARC в режиме quarantine — приемлемо, чуть слабее; переведите DMARC в reject для полной защиты.
- ~all сам по себе (без принуждения DMARC) — слабо. Это говорит «вероятно подделка, всё равно доставьте». Поддельная почта всё равно проходит. Это ловушка, в которую попадают многие, считая себя защищёнными.
- ?all (нейтрально) — не даёт никакой защиты.
- +all — прямо опасно: говорит всему миру, что кто угодно может отправлять от вашего имени. Никогда так не делайте.

Есть ещё один невидимый сбой: при вычислении SPF разрешено не более 10 обращений к DNS. Накопите слишком много записей include: — и запись превысит лимит, после чего получатели сочтут её целиком сломанной, и вы снова без защиты. Это распространённая тихая проблема у бизнесов, использующих много маркетинговых и SaaS-инструментов.

Как выглядит «хорошо»: ровно одна запись SPF, перечисляющая каждый сервис, легитимно отправляющий почту от вас, заканчивающаяся на -all (или ~all в паре с DMARC p=reject) и с уверенным запасом по лимиту в 10 обращений.

Как это исправить (бесплатно, ~10 минут)

Передайте этот раздел тому, кто ведёт ваш домен или сайт, — и учтите, что исправление бесплатно. Это изменение DNS-настройки, а не продукт, который покупают. Мы берём плату только за мониторинг того, что настройка остаётся корректной со временем, а не за само изменение.

Шаг 1 — Перечислите каждый сервис, отправляющий почту от вашего имени. Именно здесь ошибаются. Выпишите их все: вашего почтового провайдера (Google Workspace, Microsoft 365 и т. п.), а также любой инструмент рассылок, CRM, службу поддержки, платформу интернет-магазина, приложение для счетов/бухгалтерии и систему бронирования. Если сервис шлёт почту с вашим именем, а вы его забудете, ваш SPF заблокирует его письма, когда вы ужесточите политику.

Шаг 2 — Опубликуйте одну TXT-запись на корневом домене. Объедините строки «include» для всех ваших отправителей в одну запись. По типичным платформам:

Google Workspace: include:_spf.google.com
Microsoft 365: include:spf.protection.outlook.com
SendGrid: include:sendgrid.net
Mailchimp: include:servers.mcsv.net
Zoho: include:zoho.eu (или домен, соответствующий вашему региону)

Объединённая запись выглядит так:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net -all

Где её добавить, по провайдерам:

Cloudflare: DNS → Records → Add record → тип TXT, Name @, Content = значение выше.
Админка Microsoft 365 / Google: они выдают точную строку include в своём мастере настройки; скопируйте её в TXT-запись у вашего DNS-хоста.
GoDaddy / большинство хостингов: управление DNS → Add → TXT, Host/Name @, Value = запись.

Шаг 3 — Начните безопасно, затем включите принуждение. Пока вы убеждаетесь, что список отправителей полон, опубликуйте с ~all (мягкий отказ), чтобы ничто легитимное не заблокировалось по случайности. Убедившись, что вся настоящая почта по-прежнему ходит, ужесточите до -all (жёсткий отказ) — или, что лучше, оставьте ~all и добавьте политику DMARC p=reject, это и есть рекомендуемая современная пара.

Шаг 4 — Убедитесь, что запись РОВНО одна. Если старая запись SPF уже есть, редактируйте именно её, а не добавляйте вторую. Две записи v=spf1 взаимно аннулируются и оставляют вас без защиты.

Шаг 5 — Следите за числом обращений. Если отправителей много, можно превысить лимит в 10 обращений. Если так случилось — консолидируйте: некоторые провайдеры предлагают «SPF flattening», либо уберите отправителей, которыми вы больше не пользуетесь.

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

Частые ошибки

Две записи SPF. Самый частый тихий сбой. Добавление новой записи вместо правки существующей аннулирует обе. Должна быть ровно одна.
Остановка на ~all в уверенности, что готово. Мягкий отказ без DMARC за ним — это слабая золотая середина: выглядит настроенным, а защищает едва-едва. Либо переходите на -all, либо соедините ~all с DMARC p=reject.
Забытый отправитель. Ужесточение до -all до того, как вы перечислили сервис счетов, CRM или рассылок, начнёт блокировать вашу же легитимную почту. Сначала перечислите всё.
Превышение лимита в 10 обращений. Каждый include: может цеплять новые обращения. Слишком много — и запись считается сломанной. Держите её компактной.
Использование +all. Это прямо разрешает всему интернету отправлять от вашего имени. Это хуже, чем не иметь записи вовсе. Никогда так не публикуйте.

Как это вписывается

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

Настройте это у своего хостинг-провайдера

Пошагово для популярных провайдеров:

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

Я не технический специалист — смогу ли я разобраться с этим сам?

Вам не нужно разбираться в деталях. Изменение — это одна-две строки, добавленные в настройки вашего домена тем, кто ведёт ваш сайт, или вашим ИТ-подрядчиком. Передайте им раздел «Как это исправить» ниже — обычно это занимает несколько минут и бесплатно. Мы берём плату только за то, чтобы со временем следить, что настройка остаётся корректной.

У нас уже есть запись SPF — значит, мы защищены?

Не обязательно. Наличие записи — это первая половина дела; вторая — чтобы она была настроена строго. Запись, заканчивающаяся на «~all» (мягкий отказ) без DMARC за ней, говорит принимающим серверам «возможно, это подделка, но всё равно доставьте» — а это даёт минимальную защиту. Две записи SPF или одна, делающая слишком много обращений, считаются сломанными и не дают вообще никакой защиты, хотя и выглядят рабочими. Обе половины должны быть верными.

Не сломает ли исправление мою собственную почту?

Может, если запись пропустит легитимного отправителя — например, ваш сервис выставления счетов или рассылок, который шлёт письма от вашего имени. Именно поэтому безопасный подход — сначала перечислить все сервисы, отправляющие почту от вас, опубликовать с мягким «~all», пока вы убеждаетесь, что никого не забыли, а затем ужесточить до жёсткого отказа. В таком порядке ничего не сломается.

В чём разница между «~all» и «-all» и что нам использовать?

«-all» (жёсткий отказ) велит получателям отклонять всё, чего нет в вашем списке, — самая строгая настройка. «~all» (мягкий отказ) говорит «вероятно, нелегитимно, но всё равно примите». Современная рекомендация — «~all» в паре с политикой DMARC «reject»: эта пара даёт ту же защиту, что и «-all», без риска отскоков пересланных писем. Сам по себе «~all» без принуждающего DMARC — это та слабая конфигурация, которой надо избегать.

Остановит ли SPF всю подделку почты в одиночку?

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

Как скоро это заработает и может ли это что-то стоить?

Изменения DNS обычно вступают в силу за время от нескольких минут до пары часов. Само исправление всегда бесплатно — это просто правка настройки у вашего DNS-провайдера. Любой, кто говорит, что для добавления записи SPF нужен платный продукт, ошибается.