SPF-запись: как защитить почту домена от подделки и спама

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

Что такое SPF-запись

SPF расшифровывается как Sender Policy Framework — «система политики отправителя». Это правило, которое владелец домена публикует в DNS: «письма от example.ru отправляют только вот эти серверы». Справка Яндекс 360 описывает настройку так: нужно создать TXT-запись со списком серверов, которые отвечают за отправку почты с вашего домена.

Технически это обычная текстовая запись типа TXT. Стандарт RFC 7208 прямо требует публиковать SPF только как DNS-запись типа TXT: отдельный тип записи SPF когда-то существовал, но от него отказались. В панели регистратора или хостинга вы добавляете TXT-запись для домена, и в её значении пишете правило, которое начинается с v=spf1.

Когда ваше письмо приходит, например, на Яндекс Почту или Gmail, принимающий сервер смотрит, с какого IP-адреса оно пришло, запрашивает SPF-запись домена отправителя и проверяет, есть ли этот адрес в списке. Результат проверки — одно из нескольких значений: pass, fail, softfail, neutral или ошибка. Дальше сервер учитывает его, решая, куда положить письмо.

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

От чего защищает SPF, а от чего нет

Главная польза SPF — доставляемость. По справке Яндекс 360, SPF-запись помогает снизить риск того, что письмо, отправленное с адреса на вашем домене, попадёт в спам у адресата. Крупные почтовые сервисы смотрят на неё в первую очередь.

Google сформулировал требования жёстче: все, кто отправляет письма на личные аккаунты Gmail, должны настроить SPF или DKIM. А отправители массовых рассылок — более 5000 сообщений в день — должны настроить все три механизма: SPF, DKIM и DMARC.

Вторая польза — защита от подделки. Мошенник, который рассылает письма «от вашей компании» со своего сервера, не попадёт в ваш список, и проверка SPF у получателя не пройдёт.

Но у SPF есть важная граница. Стандарт проверяет домен из служебных полей HELO или MAIL FROM, которые сервер передаёт во время доставки, а не адрес в поле «От кого», который видит человек. Злоумышленник может указать в служебном поле свой домен с корректным SPF, а в видимом — ваш. Закрывает эту дыру DMARC, о нём — в разделе про связку SPF, DKIM и DMARC.

Из чего состоит SPF-запись

Запись — это строка из версии и набора правил, которые проверяются слева направо. Первое совпавшее правило определяет результат, а правила после all, по RFC 7208, не проверяются вовсе.

Перед каждым механизмом может стоять квалификатор, который задаёт результат при совпадении. По RFC 7208 их четыре: «+» даёт pass, «-» даёт fail, «~» даёт softfail, «?» даёт neutral. Если квалификатор не указан, действует плюс, поэтому ip4:203.0.113.10 и +ip4:203.0.113.10 означают одно и то же.

На практике квалификатор пишут только перед all: ~all или -all. Это правило для всех серверов, которые не попали в список выше. Адрес 203.0.113.10 в примерах — документационный, подставьте свой.

Примеры SPF-записей для Яндекса, Google и сайта

Готовую запись обычно даёт почтовый сервис. Вот типовые варианты:

Вариант с redirect подходит, только если всю почту отправляет один сервис: redirect передаёт проверку целиком его записи. Как только появляется второй отправитель — рассыльщик, CRM, формы сайта, — переходите на include. Справка Яндекс 360 даёт для этого случая формат v=spf1 ip4:IP-1 ip4:IP-2 ip4:IP-3 include:_spf.yandex.net ~all, где IP-1, IP-2 и IP-3 — адреса дополнительных серверов.

Частый случай на корпоративных сайтах — письма с форм заявок. Их отправляет сервер хостинга, и если его нет в SPF, уведомления о заявках уходят в спам у самой компании. Узнайте IP-адрес почтового сервера у хостера и добавьте его через ip4 или через include, если хостер публикует свою SPF-запись. При переезде сайта адрес сервера меняется, поэтому SPF входит в чек-лист из статьи как перенести сайт на другой хостинг.

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

Мнение. Если у компании больше одного отправителя почты, не используйте redirect: перечислите всех через include и ip4 и закончите запись ~all. Это проще поддерживать, когда добавится новый сервис.

Что выбрать: ~all или -all?

Разница — в том, насколько уверенно вы говорите получателю «остальным не верить». По RFC 7208 результат fail — явное заявление, что сервер не уполномочен отправлять почту домена. Softfail — слабое заявление, что сервер, вероятно, не уполномочен. Решение, что делать с письмом, в обоих случаях принимает получатель.

Google в справке рекомендует использовать ~all. Логика простая: если вы забыли включить в запись какой-то сервис, письма от него пометят как подозрительные, но не отклонят. С -all такие письма могут просто не дойти, и вы узнаете об этом от клиентов.

Когда -all уместен:

• Домен не отправляет почту — запись v=spf1 -all без механизмов.
• Полный контроль над отправителями — вы точно знаете все сервисы и сверили их с отчётами DMARC.
• Домен часто подделывают — и вы готовы к тому, что ошибка в записи отрежет часть легитимной почты.

Знак «?all» почти бесполезен: он означает «ничего не утверждаю» и не защищает от подделки. А «+all» — опасная ошибка: он разрешает отправлять от вашего имени кому угодно.

Как добавить SPF-запись в DNS домена?

SPF настраивают там, где управляют DNS-зоной домена: у регистратора, хостера или в кабинете почтового сервиса, если домен делегирован ему. По справке Яндекс 360, при делегировании домена на серверы Яндекса SPF-запись будет настроена автоматически.

Порядок для ручной настройки:

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

Лимит в 10 запросов и другие ограничения

У SPF есть жёсткие технические ограничения, и именно они ломают записи у растущих компаний. Главное — лимит DNS-запросов. По RFC 7208 запросы порождают механизмы include, a, mx, ptr, exists и модификатор redirect, а проверяющий сервер обязан ограничить число таких запросов десятью. Если лимит превышен, проверка возвращает permerror — ошибку, при которой запись считается неработающей.

Подвох в том, что include считается вместе с вложенными. Запись почтового сервиса сама может содержать несколько include, и три-четыре сервиса легко дают больше десяти запросов. Механизмы ip4, ip6 и all запросов не порождают, поэтому постоянные адреса выгоднее писать через ip4.

Второе ограничение — одна запись на домен. RFC 7208 запрещает домену иметь несколько записей, из которых проверка выбрала бы больше одной. Две TXT-записи с v=spf1 — частая ошибка после смены почты: старую забыли удалить, новую добавили рядом. Результат — та же ошибка permerror.

Третье — порядок. Всё, что стоит после all, игнорируется, поэтому all всегда пишут последним.

Факт. По RFC 7208 при проверке SPF допускается не больше 10 DNS-запросов от include, a, mx, ptr, exists и redirect вместе, иначе запись считается ошибочной.

Как проверить SPF-запись?

Проверка нужна дважды: сразу после настройки и после каждого нового сервиса-отправителя.

Сначала убедитесь, что запись опубликована. Подойдёт любой онлайн-сервис проверки DNS или команда nslookup -type=txt example.ru в терминале. В ответе должна быть ровно одна строка, начинающаяся с v=spf1.

Затем проверьте, как запись работает на реальном письме. Отправьте письмо с корпоративного адреса на личный ящик в Gmail или Яндекс Почте и откройте его служебные заголовки — в Gmail это пункт «Показать оригинал». Ищите строку Authentication-Results с результатом spf=pass. Если там softfail или fail, сервер, который отправил письмо, не попал в запись.

Повторите тест для каждого отправителя: письма с формы сайта, уведомления из CRM, тестовая рассылка. Именно они чаще всего оказываются вне SPF, потому что их настраивали разные люди в разное время.

SPF, DKIM и DMARC: зачем нужны все три

SPF — только первая из трёх проверок, и по отдельности он закрывает не всё. Почтовые сервисы смотрят на связку.

• SPF — проверяет, что письмо пришло с разрешённого сервера.
• DKIM — цифровая подпись письма. Сервер отправителя подписывает письмо закрытым ключом, а открытый ключ лежит в DNS; в Яндекс 360 это TXT-запись mail._domainkey.
• DMARC — политика домена: что делать с письмом, если проверки не прошли, и куда присылать отчёты. Она сверяет видимый адрес отправителя с доменом, прошедшим SPF или DKIM, и закрывает подделку поля «От кого».

У DMARC три режима. По RFC 7489 политика none ничего не требует от получателя, quarantine просит считать не прошедшие проверку письма подозрительными, reject — отклонять их. Начинают обычно с none и отчётов: они покажут, кто ещё отправляет почту от вашего имени, а уже потом политику ужесточают.

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

Источники

• SPF-запись — Яндекс 360 для бизнеса
• RFC 7208. Sender Policy Framework (SPF) — IETF
• Настройте SPF — Справка Google Workspace
• RFC 7489. Domain-based Message Authentication, Reporting, and Conformance (DMARC) — IETF