Что такое SPF
Думаю, никому не нужно объяснять, какой проблемой является спам в наше время. Борьба с этим злом — дело не простое, и если хочется приблизится к идеалу, требующее сочетания нескольких элементов. Одним из этих элементов является протокол SPF. Будучи опубликованным в апреле 2006 года в RFC 2006 года к настоящему времени протокол имеет статус «экспериментальный», и достаточно неплохую распространенность.
SPF взят на вооружение такими гигантами, как Google, Яндекс, Mail.Ru, Microsoft, Рамблер. Yahoo не поддерживает SPF, а пытается продвигать свою разработку DKIM, к слову, не слишком успешно.
Итак — как же работает SPF?
Общие принципы работы
Основная идея такова — хозяин адреса указывает, с каких адресов следует ожидать его почту, и как интерпретировать ошибку, в случае несоответствия. Важно понимать, что эти данные — всего лишь рекомендация отправителя по проверке. Да-да, конечно же, стандарт описывает, как должна принимающая сторона обрабатывать результат, но по всяким причинам принимающая сторона фактически может с ними делать все, что заблагорассудится — полностью соблюсти, интерпретировать по-своему или же вообще проигнорировать рекомендации.
Технические детали
Для размещения данных используется поле TXT в DNS. Так IANA назначила DNS поле с кодом 99 для SPF. Формат SPF поля идентичен TXT. Вообще, использование поля TXT не является оптимальным, но проблема в том, что не всякий DNS сервер и клиент понимает новый SPF тип записи. Поэтому совместное использование TXT и SPF считается хорошим подходом, обеспечивающим совместимость и будущее развитие.
Стандарт рекомендует доменам, удовлетворяющим требованиям SPF, иметь записи обоих типов. Вместе с тем, как минимум одна запись должна присутствовать обязательно. В случае наличия двух записей они должны быть идентичны. Например:
example.com. IN TXT «v=spf1 +mx a:colo.example.com/28 -all»
example.com. IN SPF «v=spf1 +mx a:colo.example.com/28 -all»
Если установлена запись SPF, то TXT записи должны быть проигнорированы.
Механизм взаимодействия
Почтовый обмен с использованием SPF происходит по следующему алгоритму.
Почтовый сервер mx.example.com отправляет письмо на адрес user@example.net. В DNS записи example.com содержатся такие строки:
mx.example.com. IN A 208.77.188.166
example.com. IN MX 10 mx.example.com.
example.com. IN TXT «v=spf1 +mx -all»
Итак, mx.example.com устанавливает соединение с SMTP example.net и получает от него, нечто вроде
>> 220 example.net ESMTP Service (Mailer v1.0) ready at 30.07.2009 12:28:21 UTC
затем mx.example.com представляется через HELO/EHLO.
В зависимости от настроек принимающей стороны, после данного представления уже может быть проверка на соответствие представленного имени правилам SPF, но в данном месте это не обязательно
>> 250 example.net Hello mx.example.com., pleased to meet you
А вот в этом месте, после выдачи отправителем MAIL FROM должна последовать обязательная проверка, интерпретация результата и реакция на него.
В данный момент модуль, отвечающий за проверку SPF делает следующие вещи. Осуществляется запрос к DNS. Запрашиваются SPF и TXT поля. Если в полученном ответе присутствует правило SPF, то оно разбирается и происходит анализ на соответствие. В нашем примере это правило «v=spf1 +mx -all». Согласно правила проверяются MX записи, и проводится сверка указанных в записях IP-адресов, полученного из представления DNS-имени и IP-адреса подключившегося отправителя. В данном случае все совпадает, управление возвращается почтовику, и он начинает прием сообщения.
Если бы, вдруг, фактический IP подключившегося отправителя был иным, то анализатор сообщил бы почтовику, что входящее сообщение не валидно, и лучше бы его вообще не принимать, ну или на крайний случай отмаркировать отдельно.
Формат записи
Запись SPF выглядит примерно так:
example.com. IN SPF «v=spf1 +mx a:colo.example.com/28 -all»
Эта запись содержит следующую информацию:
версия SPF — 1 (кстати, пока единственная используемая)
письмо может иметь отправителя с IP-адресом, соответствующим записям в MX для домена example.com
письмо может иметь отправителя с IP-адресом, соответствующим одному из адресов в подсети colo.example.com/28
Во всех остальных случаях, когда адрес не соответствует перечисленным условиям, считать отправителя недостоверным.
Вообще, в условии есть 2 части — определитель и механизм.
Определители могут быть: «+» Pass, «-» Fail, «~» SoftFail, «?» Neutral
Механизмы: all, include, A, MX, PTR, IP4, IP6, exists
Результатами проверки условий могут являться следующие определенные результаты:
* None — означает, что либо в домене нет записей, либо вообще не удается проверить домен. В общем никакого внятного ответа не получено.
* Neutral — возникает в ситуации, когда хозяин домена не хочет или не может сообщить разрешен ли IP. Этот результат должен обрабатываться так же, как и None.
* Pass — означает, что все ОК и получатель может принять письмо.
* Fail — явно указывает на то, что письмо принимать не следует. Проверяющая сторона может отмаркировать письмо либо отбросить.
* SoftFail — находится где-то между Fail и Neutral. Принимающая сторона не должна отбрасывать письмо на основании только этого результата.
* TempError — результат, возникающий, если клиент в момент проверки получает временную ошибку. Сообщение можно принять или временно отвергнуть.
* PermError — ошибка, возникающая при невозможности корректной интерпретации DNS записей отправителя.
Возьмем, для примера, какой-нибудь реальный домен. Допустим Google.com. Запрос TXT возвращает
«v=spf1 include:_netblocks.google.com ~all»
тут говорится, что нужно включить правила из записи _netblocks.google.com. Интересно, что у _netblocks.google.com отсутствует A-запись, а есть только TXT-запись. Вот она:
«v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ?all»
Тут перечислены подсети, в которых могут находится почтовые сервера Google. Последний механизм all c определителем Neutral сообщает анализатору о том, что адрес отправителя может быть не из разрешенного диапазона. Письма из чужих адресных пространств рекомендуется проверять дополнительно, а не отвергать безусловно. Для такой масштабной структуры, как Google — это верное решение, ибо в процессе работы адреса могут изменятся, например, при временном отказе и переключении на резерв. И к тому же, адрес может меняться пересылками.
Более хитрая SPF запись у Рамблера:
«v=spf1 ip4:81.19.66.0/23 ip4:81.19.88.0/24 -exists:%.spf.rambler.ru -exists:%.u.spf.rambler.ru ~all»
тут указаны 2 подсети, из которых разрешено принимать почту, и 2 набора источников, почта с которых будет иметь результат проверки Fail.
Проблема пересылки
Представьте себе следующую схему — пользователь отправляет письмо с адреса vasily@xyz.com на pupkin@mylo.ru, а там стоит автоматический форвардинг на pupkin@gmail.com. А у домена xyz.com прописано SPF «v=spf1 +mx -all». В итоге, конечный получатель gmail.com сделает проверку, и получит несовпадение адреса фактического отправителя с указанным, и по правилам SPF не примет письмо. Для решения данной проблемы существует SRS: Sender Rewriting Scheme. В двух словах — происходит переписывание форвардером заголовка return-path.
Вообще, я считаю, что данный момент очень спорный. Использование промежуточного ящика для перенаправления трафика на другой ящик весьма напоминает спам-атаку. Вот, например, я регистрирую ящик, свечу его везде, где только можно, подписываюсь на миллион рассылок, и ставлю редирект на некий ящик, который я хочу завалить спамом. В случае наличия у отправителей SPF и отсутствии SRS на пересылающем почтовике — цель отвергнет эти потоки как спам, а вот при работающем SRS он получит вполне «легитимные» потоки почты.
Заключение
SPF является простым и достаточно эффективным способом оценить легитимность передаваемой почты. Администраторам почтовых серверов стоит минимальных телодвижений добавление SPF записей в DNS. Простота внедрения и поддержка основными популярными MTA делают распространение SPF все шире и шире, что несет всем пользователям электронной почты пользу, почтовым серверам снижение трафика и в целом делает мир лучше 🙂
Spf=softfail как настроить?
Добрый день. Подскажите пожалуйста, есть свой почтовый сервер из коробки. Проблема в том, что при перенаправлении входящего письма с помощью фильтра на почту yandex, письмо падает в спам.
astivv@yandex.ru(начало)-> user@mysrv.ru(перенаправление)-> astivv2@yandex.ru(SPAM)
В свойстве письма есть такая строка:
Authentication-Results: iva3-bf649248480a.qloud-c.yandex.net; spf=softfail (iva3-bf649248480a.qloud-c.yandex.net: transitioning domain of yandex.ru does not designate внешний ip моего сервера as permitted sender, rule=[~all]) smtp.mail=astivv@yandex.ru; dkim=pass header.i=@yandex.ru
Правильно ли я понял, что yandex ругается на sfp запись?
- Вопрос задан более двух лет назад
- 657 просмотров
2 комментария
Средний 2 комментария
SPF-запись
В Unisender есть все для рассылок: можно создавать и отправлять клиентам письма и SMS, настроить чат-бота и делать рассылки в Telegram и даже собрать простой лендинг для пополнения базы контактов.
SPF (Sender Policy Framework) — это список IP-адресов в виде буквенного кода, который прописывается в настройках домена и содержит информацию о серверах, с которых владелец разрешает отправлять письма.
SPF-запись выглядит, например, так:
v=spf1 ip4:176.57.223.0/24 -all
где v — версия SPF, всегда принимает значение v=SPF1;
ip4 — IP-адрес, с которого разрешена отправка писем;
-all — механизм работы с письмами, отправленными с других IP-адресов.
Данная SPF-запись простая и весьма строгая. Она разрешает отправку писем только с указанного IP. Все остальные письма должны быть заблокированы, так как указан механизм «-all».
Как работает SPF-запись
После отправки письма почтовый сервер получателя проверяет, с какого IP-адреса пришло сообщение. Он сверяет его со списком, который прописан в SPF.
Если адрес есть в списке, значит, все в порядке. Письмо попадает во входящие. Если IP-адреса нет в списке, то письмо может быть заблокировано почтовым провайдером .
А вот если SPF не прописан, велика вероятность, что письмо будет доставлено. И тогда мошенники легко могут написать сообщение от вашего имени и украсть личные данные подписчиков.
Для чего нужна SPF-запись
Часто владельцы доменов пренебрегают SPF. А зря. Настройка этой записи займет несколько минут, но убережет от многих проблем.
Иногда SPF и хотелось бы настроить, но нет такой возможности. Довольно часто встречаю хостинги и даже сервисы рассылок, которые ограничиваются только настройкой DKIM и дополнительных механизмов аутентификации отправителя (проверки подлинности) не предусматривают.
email-маркетолог, основатель блога «Практичный email маркетинг» и автор книг по email-маркетингу
Защита домена от спуфинга. Главная причина настроить SPF — это обеспечить безопасность вашего домена.
Иногда мошенники отправляют письма от имени другой компании или человека, маскируются под известный бренд, присылают сообщения «от банка» о переводе средств и просят перейти по ссылке. Они делают это, чтобы украсть данные пользователей, деньги с карты или поселить в компьютер вирусную программу.
Если вам пришло подобное письмо, проверьте, с какого адреса оно отправлено и сверьте его с официальным. А лучше позвоните на горячую линию компании. Банки обычно не пишут такие сообщения
Схема, при которой отправитель письма пытается выдать себя за другого, использует чужой логотип и похожий email-адрес, называется спуфинг-атакой. Чтобы защитить корпоративную почту и домен от блокировки, а ваших подписчиков от мошенников, нужно настроить SPF. Тогда подмена отправителя будет уже менее страшна.
Доставка писем во входящие. Почтовые провайдеры лояльны к отправителям, которые настроили email-аутентификацию, в том числе прописали SPF. Почтовики с большей вероятностью пропускают письма таких компаний во входящие.
Дополнительные возможности. Если вы добавили SPF-запись, то сможете подключить сервисы расширенной статистики по отправленным рассылкам — постамстеры. Правда, для этого еще потребуется настроить DKIM.
Механизмы SPF-записи
Любая SPF-запись начинается с v=spf1, это значение не меняется.
Далее указываются параметры, или механизмы. Чаще всего используют следующие: all, ip4, ip6, a, mx, include, redirect.
Параметры «ip4/ip6» указывают конкретные адреса, с которых можно отправлять письма. Параметр «a» проверяет A-запись домена, «mx» — МХ-запись домена.
А-запись домена отвечает за связь с IP-адресом сервера. Если A-запись не прописана, сайт не будет работать. А вот МХ-запись отвечает за сервер, через который работает почта.
Механизмы include, redirect позволяют применять настройки SPF другого домена. Их используют компании, у которых несколько доменов и почтовых серверов. Тогда можно прописать настройки SPF один раз и тем самым упростить работу.
Параметр «all» задает обработку всех писем с адресов, не указанных в SPF-записи. Как именно почтовик будет поступать с этими письмами, зависит от префикса, прописанного перед параметром.
Префиксы (или определители) диктуют действия, которые следует применить к письмам отправителя:
«+» — pass, принимать почту.
«-» — fail, отклонять почту.
«~» — softFail, принимать почту, но помещать ее в спам.
«?» — обрабатывать как обычное письмо.
Пара примеров для закрепления:
v=spf1 a include:other-domain.com -all
Принимать почту с А-записи текущего домена и серверов, указанных в SPF-записи домена other-domain.com. Остальные письма отклонять.
v=spf1 ip6:2002:db7 ~all
Принимать почту с указанного адреса, остальные письма отправлять в спам.
Как настроить SPF для рассылок
Если вы отправляете письма только через почтовые провайдеры, сделайте SPF-запись в настройках аккаунта. У Яндекс, Google и Mail.ru есть подробные инструкции.
Если вы используете сервис рассылок, то для настройки SPF вам потребуется доступ к хостингу вашего сайта. Мы написали пошаговую инструкцию, как настроить SPF с нуля в Unisender.
На всякий случай уточню такой нюанс: SPF-запись для домена в DNS делается только одна. И в неё уже включаются все IP-адреса, с которых допустима отправка писем.Например, если мы используем для рассылок несколько сервисов: какой-то сервис для массовых рассылок, отдельный сервис для отправки писем с товарными рекомендациями, отдельное решение для отправки транзакционных писем — то везде у них будут разные IP-адреса для отправки. Все их понадобится включить в единую SPF-запись. В этом отличие от DKIM, которых может быть добавлено в DNS несколько (в данном конкретном примере это будет три отдельных DKIM-подписи для трёх разных сервисов отправки писем).
email-маркетолог, основатель блога «Практичный email маркетинг» и автор книг по email-маркетингу
Как проверить SPF
При настройке SPF через сервисы рассылок достаточно проверить статус записи в разделе email-аутентификации. Например, в Unisender корректно настроенная SPF-запись будет отмечена зеленым цветом.
Еще один способ проверить SPF-запись — специальные сервисы, например MailTester.com.
Отправьте ваше письмо на указанный адрес, а сервис проверит, каковы его шансы попасть во входящие.
После отправки сервис покажет общий рейтинг, а также статус настроек email-аутентификации.
Итак, SPF-запись помогает предотвратить спуфинг-атаку на домен, улучшить доставляемость писем и защитить ваших подписчиков от спама.
Из Атланты в Лондон
Я настроил SPF, чтобы лучше доходила почта, отправляемая моим сайтом. Windows-хостинг у ASP Host Central, письма отправляются с помощью обычной функции mail() из PHP. Но почему-то SPF не помогает, всё равно происходит softfail:
Delivered-To: john.smith@gmail.com
Received: by 10.231.35.199 with SMTP id q7cs118060ibd;
Thu, 21 Apr 2011 03:15:33 -0700 (PDT)
Received: by 10.142.200.1 with SMTP id x1mr4731149wff.82.1303380933251;
Thu, 21 Apr 2011 03:15:33 -0700 (PDT)
Return-Path:
Received: from asp157mail.asphostserver.com (174.37.170.227-static.reverse.softlayer.com [174.37.170.227])
by mx.google.com with ESMTP id 9si5563363wfi.117.2011.04.21.03.15.31;
Thu, 21 Apr 2011 03:15:32 -0700 (PDT)
Received-SPF: softfail (google.com: domain of transitioning support@asphostserver.com does not designate 174.37.170.227 as permitted sender) client-ip=174.37.170.227;
Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning support@asphostserver.com does not designate 174.37.170.227 as permitted sender) smtp.mail= support@asphostserver.com
Message-Id:
Received: from asphost157 [127.0.0.1] by asp157mail.asphostserver.com with SMTP;
Thu, 21 Apr 2011 05:14:11 -0500
Date: Thu, 21 Apr 2011 05:14:11 -0500
Subject: Registration on mydomain.com
To: john.smith@gmail.com
From: noreply@mydomain.com
Return-Path: noreply@mydomain.com
Проблема в том, что в SPF я прописал домен mydomain.com, и обратный адрес должен быть noreply@mydomain.com. Но, как видите, письмо почему-то отправляется от имени support@asphostserver.com. Хотя я же вроде указал noreply@mydomain.com в заголовке Return-Path, когда вызывал mail().
Но если присмотреться, то видно, что в емейле на самом деле два Return-Path. И мой, правильный, находится внизу, а сверху всё равно лепится «левый» емейл support@asphostserver.com.
Решение: перед вызовом mail() делаю ini_set(«sendmail_from», ‘noreply@mydomain.ua’) . Это помогает убрать support@asphostserver.com.