SPF — протокол подтверждения почты¶

SPF (Sender Policy Framework, «инфраструктура политики отправителя») — стандарт электронной почты, определяющий, какие серверы уполномочены отправлять письма от имени конкретного домена. Термин SPF также расшифровывается как Sender Policy Framework, что переводится на русский как «фреймворк политики отправителя» или «инфраструктура политики отправителя». В контексте информационной безопасности аббревиатура SPF может означать и другие понятия — например, Secure Perimeter Framework или Simple Power Flow в энергетике, — однако наиболее распространённое значение относится к электронной почте.

¶История

Работа над SPF началась в 2003 году. Автором первой версии протокола стал Монис Мансур (Monis Mansour), а публикация проекта состоялась в 2004 году. Идея заключалась в простом механизме: владелец домена публикует в DNS-записи список серверов, которым разрешено отправлять почту от его имени, а принимающий сервер сверяет IP-адрес отправителя с этим списком.

В 2006 году протокол был формализован в виде RFC 4408. В 2014 году вышла обновлённая версия — RFC 7208, которая действует и по сей день и заменила собой ранние спецификации. SPF стал одним из первых стандартов, направленных на борьбу с подделкой адреса отправителя (spoofing), — практикой, при которой злоумышленник отправляет письмо, подставляя чужой адрес в поле From.

¶Принцип работы

Механизм SPF построен на трёх элементах:

1. Запись SPF в DNS домена. Владелец домена добавляет в TXT-запись (ранее — в отдельный тип записи SPF) перечень IP-адресов или подсетей, авторизованных для отправки почты. Пример записи: v=spf1 ip4:192.0.2.0/24 include:_spf.google.com -all.

1. Проверка на принимающем сервере. При получении письма почтовый сервер извлекает домен из адреса отправителя (envelope sender), запрашивает его TXT-запись и сравнивает IP-адрес подключившегося сервера с опубликованным списком.

1. Код результата. Проверка возвращает одно из значений: pass (отправитель авторизован), fail, softfail, neutral, none (записи SPF нет), temperror или permerror. На основе этого результата принимающий сервер принимает решение о доставке письма, пометке его как спама или отклонении.

¶Механизмы и синтаксис

Запись SPF начинается с метки версии v=spf1. Далее перечисляются механизмы:

• ip4: и ip6: — конкретные IP-адреса или подсети;
• a и mx — разрешение доменных A- и MX-записей;
• include: — ссылка на запись SPF другого домена (часто используется для почтовых сервисов);
• all — обозначение конца списка, с квалификаторами: -all (жёсткий отказ), ~all (мягкий отказ), ?all (нейтрально) и +all (разрешить всем, что считается ошибкой конфигурации).

Ограничение протокола — не более 10 DNS-запросов на одну проверку, что накладывает ограничения на глубину вложенности include:.

¶Ограничения

SPF проверяет адрес отправляющего сервера (envelope sender), но не отображаемое имя пользователя в поле From, которое видит получатель. Письмо может пройти проверку SPF, но отображать поддельный адрес в интерфейсе почтового клиента. Для закрытия этого пробела разработаны дополнительные протоколы — DKIM (DomainKeys Identified Mail) и DMARC (Domain-based Message Authentication, Reporting and Conformance), которые используют SPF как один из компонентов проверки.

К другим ограничениям относятся сложность настройки при переадресации почты (mail forwarding), поскольку промежуточный сервер меняет IP-адрес отправителя, и необходимость поддержания актуального списка авторизованных серверов.

¶SPF в России

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

¶Связанные стандарты

Вместе эти три протокола формируют основу современной аутентификации электронной почты.

¶Источники

• RFC 7208 — Sender Policy Framework (SPF) for Authorizing Use of Domains in Email
• RFC 4408 — Sender Policy Framework (SPF) for Authorizing Use of Domains in Email
• RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures
• RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC)