Spf почта что это
SPF-запись
SPF-запись помогает снизить риск того, что письмо, отправленное с адреса на вашем домене, попадет в спам у адресата. Чтобы настроить SPF-запись, нужно создать TXT-запись со списком серверов, которые отвечают за отправку почты с вашего домена.
Если вы делегировали домен на серверы Яндекса, SPF-запись будет настроена автоматически.
Общая инструкция по настройке SPF-записи
Войдите в панель управления на сайте компании, которая предоставляет вам DNS-хостинг.
Если вы делегировали домен на серверы Яндекса, перейдите в DNS-редактор Коннекта.
Создайте TXT-запись со следующими значениями полей (в разных панелях управления названия полей могут различаться):
Имя поддомена (или Хост ) — @
Если это поле отсутствует в панели управления, можно его не указывать.
Подождите, пока изменения в DNS вступят в силу. Может потребоваться до 72 часов, чтобы DNS-серверы в интернете обменялись данными о новых DNS-записях.
Инструкции по настройке SPF-записи у некоторых хостинг-провайдеров
Откройте страницу https://reg.ru и войдите в ваш аккаунт.
Text — v=spf1 redirect=_spf.yandex.net
Подождите, пока изменения в DNS вступят в силу. Может потребоваться до 72 часов, чтобы DNS-серверы в интернете обменялись данными о новых DNS-записях.
Откройте страницу https://cp.masterhost.ru и войдите в ваш аккаунт.
значение (IP/host.) — v=spf1 redirect=_spf.yandex.net
Поле MX preference оставьте пустым.
Подождите, пока изменения в DNS вступят в силу. Может потребоваться до 72 часов, чтобы DNS-серверы в интернете обменялись данными о новых DNS-записях.
Откройте страницу https://mcp.sweb.ru и войдите в ваш аккаунт.
В выпадающем списке выберите нужный домен.
Подождите, пока изменения в DNS вступят в силу. Может потребоваться до 72 часов, чтобы DNS-серверы в интернете обменялись данными о новых DNS-записях.
Создать SPF: Как сделать так, чтобы письма не попадали в СПАМ
P.S. будет много технических терминов, но мы их просто объясним.:)
SPF (Sender Policy Framework/структура политики отправителя) — это метод борьбы со спамом, который работает по принципу паспорта. Как главный документ удостоверяет нашу личность, так SPF подтверждает, что емейл пришел с проверенного надежного адреса. Но в отличие от объемной книжечки, Sender Policy Framework представляет собой одну строку в TXT-записи домена. Например, такую:
Это самый простой пример записи, который говорит о том, что отправлять письма от имени домена example.org могут все все сервера, указанные в записях a и mx. Другие же адреса должны быть удалены: -all.
Более сложный уровень SPF-защиты для того же домена может выглядеть так:
example.org. IN TXT «v=spf1 mx ip4:195.3.159.250 +a:smtp.mail.ru include:gmail.com
и означает, что отправлять сообщения от имени домена example.org. могут все сервера, указанные в mx-записях, а также отправленные с IP 195.3.159.250. Кроме того, можно принимать письма с серверов, указанных в SPF-записи домена gmail.com. Письма со всех остальных серверов нужно отправить в спам без проверки:
И это далеко не самая сложная SPF-запись. При необходимости, она может вмещать до 10 параметров. Для удобства, мы собрали их все в одном месте:
принять емейл, но пометить как СПАМ.
mx все адреса, указанные в MX-записях домена;
all все остальные IP, которые не указаны в SPF-записи;
exists проверяет работоспособность доменного имени;
spf.example.org. IN TXT «You host not allowed e-mail to me from this domain!»
Как известно, основной метод спуфинга — это подмена адреса в поле “FROM”. SPF-запись, как противоядие, направлено именно на это поле, поскольку оно содержит главный критерий для проверки: домен отправителя и его IP адрес. Сопоставляя его с теми айпишниками, которые прописаны в SPF-записи как разрешенные, сервер-получатель принимает решение о безопасности сообщения.
Коротко, алгоритм работы SPF проходит четыре этапа. Для примера, возьмем отправку сообщения с адреса info@example.com на адрес example@beispiel.com через почтовый сервис Estismail:
И такие этапы проходит каждое письмо. Графически, преодоление SPF-фильтра выглядит следующим образом:
Базовую роль в проверке домена играет список IP адресов, указанных в SPF-записи. Именно он подтверждает честные намерения отправителя. Поэтому постарайтесь вписать в этот список все возможные IP, которым вы разрешаете отправку: все корпоративные адреса, а также не забудьте о сервисах почтовых рассылок.
Создание SPF — простая операция. В большинстве случаев для установки базовой защиты достаточно прописать одну строку в TXT-записи домена. Но и здесь есть много подводных камней:
Процесс настройки SPF-записи проходит на сайте провайдера и состоит из 5 этапов. Последний из них — проверка работоспособности и правильности SPF. Ее можно провести на одном из специальных сервисах:
Настройка DKIM/SPF/DMARC записей или защищаемся от спуфинга
1. DKIM
DKIM (DomainKeys Identified Mail) — это метод e-mail аутентификации, основанный на проверке подлинности цифровой подписи. Публичный ключ хранится TXT записи домена.
Зачем же он нужен?
DKIM необходим для того, чтобы почтовые сервисы могли проверять, является ли отправитель достоверным или нет. Т.е. защищает получателя письма от различных мошеннических писем (которые отправлены с подменой адреса отправителя).
Настройка DKIM подписи и DNS записей
Для это нам необходимо создать пару ключей:
Или можно воспользоваться онлайн-сервисом, чего я крайне не советую.
Далее необходимо указать путь с секретному ключу в файле конфигурации (для этого лучше почитать документацию) почтового сервера и публичный ключ в DNS.
Так же стоит прописать ADSP запись, которая позволяет понять, обязательно должно быть письмо подписано или нет.
_adsp._domainkey.example.com. TXT «dkim=all»
Значений может быть три:
all — Все письма должны быть подписаны
discardable — Не принимать письма без подписи
unknown — Неизвестно (что, по сути, аналогично отсутствию записи)
2. SPF
SPF (Sender Policy Framework) — расширение для протокола отправки электронной почты через SMTP. SPF определен в RFC 7208 (Wiki). Если простым языком, то SPF — механизм для проверки подлинности сообщением, путем проверки сервера отправителя. Как по мне, данная технология полезна в связке в другими (DKIM и DMARC)
Настройка SPF записей
» — дополнительные проверки, «?» — нейтрально.
3.DMARC
Domain-based Message Authentication, Reporting and Conformance (идентификация сообщений, создание отчётов и определение соответствия по доменному имени) или DMARC — это техническая спецификация, созданная группой организаций, предназначенная для снижения количества спамовых и фишинговых электронных писем, основанная на идентификации почтовых доменов отправителя на основании правил и признаков, заданных на почтовом сервере получателя (Wiki). То есть почтовый сервер сам решает, хорошее сообщение или плохое (допустим, исходя из политик выше) и действует согласно DMARC записи.
Настройка DMARC записей
Типичная запись выглядит так: _dmarc.your.tld TXT «v=DMARC1; p=none; rua=mailto:postmaster@your.tld»
В ней не предпринимаются никакие действия, кроме подготовки и отправки отчета.
ruf — отчеты писем, не прошедшие проверку DMARC. В остальном все так же, как и выше.
Эпилог
Мы научились настраивать DKIM/SPF/DMARC и противостоять спуфингу. К сожалению, это не гарантирует безопасность в случае взлома сервера или же отправки писем на серверы, не поддерживающие данные технологии. Благо, что популярные сервисы все же их поддерживают (а некоторые и являются инициаторами данных политик).
Эта статья — лишь инструкция по самостоятельной настройке записей, своего рода документация. Готовых примеров нет намеренно, ведь каждый сервер уникален и требует своей собственной конфигурации.
Что такое SPF
Думаю, никому не нужно объяснять, какой проблемой является спам в наше время. Борьба с этим злом — дело не простое, и если хочется приблизится к идеалу, требующее сочетания нескольких элементов. Одним из этих элементов является протокол SPF. Будучи опубликованным в апреле 2006 года в RFC 2006 года к настоящему времени протокол имеет статус «экспериментальный», и достаточно неплохую распространенность.
SPF взят на вооружение такими гигантами, как Google, Яндекс, Mail.Ru, Microsoft, Рамблер. Yahoo не поддерживает SPF, а пытается продвигать свою разработку DKIM, к слову, не слишком успешно.
Итак — как же работает SPF?
Общие принципы работы
Основная идея такова — хозяин адреса указывает, с каких адресов следует ожидать его почту, и как интерпретировать ошибку, в случае несоответствия. Важно понимать, что эти данные — всего лишь рекомендация отправителя по проверке. Да-да, конечно же, стандарт описывает, как должна принимающая сторона обрабатывать результат, но по всяким причинам принимающая сторона фактически может с ними делать все, что заблагорассудится — полностью соблюсти, интерпретировать по-своему или же вообще проигнорировать рекомендации.
Технические детали
Если установлена запись SPF, то TXT записи должны быть проигнорированы.
Механизм взаимодействия
>> 220 example.net ESMTP Service (Mailer v1.0) ready at 30.07.2009 12:28:21 UTC
> 250 example.net Hello mx.example.com., pleased to meet you
Если бы, вдруг, фактический IP подключившегося отправителя был иным, то анализатор сообщил бы почтовику, что входящее сообщение не валидно, и лучше бы его вообще не принимать, ну или на крайний случай отмаркировать отдельно.
Формат записи
» SoftFail, «?» Neutral
Механизмы: all, include, A, MX, PTR, IP4, IP6, exists
Результатами проверки условий могут являться следующие определенные результаты:
* None — означает, что либо в домене нет записей, либо вообще не удается проверить домен. В общем никакого внятного ответа не получено.
* Neutral — возникает в ситуации, когда хозяин домена не хочет или не может сообщить разрешен ли IP. Этот результат должен обрабатываться так же, как и None.
* Pass — означает, что все ОК и получатель может принять письмо.
* Fail — явно указывает на то, что письмо принимать не следует. Проверяющая сторона может отмаркировать письмо либо отбросить.
* SoftFail — находится где-то между Fail и Neutral. Принимающая сторона не должна отбрасывать письмо на основании только этого результата.
* TempError — результат, возникающий, если клиент в момент проверки получает временную ошибку. Сообщение можно принять или временно отвергнуть.
* PermError — ошибка, возникающая при невозможности корректной интерпретации DNS записей отправителя.
тут указаны 2 подсети, из которых разрешено принимать почту, и 2 набора источников, почта с которых будет иметь результат проверки Fail.
Проблема пересылки
Заключение
SPF является простым и достаточно эффективным способом оценить легитимность передаваемой почты. Администраторам почтовых серверов стоит минимальных телодвижений добавление SPF записей в DNS. Простота внедрения и поддержка основными популярными MTA делают распространение SPF все шире и шире, что несет всем пользователям электронной почты пользу, почтовым серверам снижение трафика и в целом делает мир лучше 🙂
Загадки и мифы SPF
SPF (Sender Policy Framework), полное название можно перевести как «Основы политики отправителя для авторизации использования домена в Email» — протокол, посредством которого домен электронной почты может указать, какие хосты Интернет авторизованы использовать этот домен в командах SMTP HELO и MAIL FROM. Публикация политики SPF не требует никакого дополнительного софта и поэтому чрезвычайно проста: достаточно добавить в зону DNS запись типа TXT, содержащую политику, пример записи есть в конце статьи. Для работы с SPF есть многочисленные мануалы и даже онлайн-конструкторы.
Первая версия стандарта SPF принята более 10 лет назад. За это время были созданы многочисленные реализации, выработаны практики применения и появилась свежая версия стандарта. Но самое удивительное, что почему-то именно SPF, более чем любой другой стандарт, оброс за 10 лет невероятным количеством мифов и заблуждений, которые кочуют из статьи в статью и с завидной регулярностью выскакивают в обсуждениях и ответах на вопросы на форумах. А протокол, казалось бы, такой простой: внедрение занимает всего пару минут. Давайте попробуем вспомнить и разобрать наиболее частые заблуждения.
TL;DR — рекомендации в конце.
1. Заблуждение: SPF защищает мой домен от подделок
На самом деле: SPF никак не защищает видимый пользователю адрес отправителя.
Объяснение: SPF вообще не работает с содержимым письма, которое видит пользователь, в частности с адресом отправителя. SPF авторизует и проверяет адреса на уровне почтового транспорта (SMTP) между двумя MTA (envelope-from, RFC5321.MailFrom aka Return-Path). Эти адреса не видны пользователю и могут отличаться от видимых пользователю адресов из заголовка From письма (RFC5322.From). Таким образом, письмо с поддельным отправителем во From запросто может пройти SPF-авторизацию.
2. Заблуждение: Я внедрю SPF и станет безопасней и меньше спама
На самом деле: скорей всего, изменений в плане безопасности и спама вы не заметите.
Объяснение: SPF изначально альтруистический протокол и сам по себе не дает преимуществ тому, кто публикует SPF-политику. Теоретически, внедрение вами SPF могло бы защитить кого-то другого от поддельных писем с вашего домена. Но на практике даже это не так, потому что результаты SPF редко используются напрямую (об этом ниже). Боле того, даже если бы все домены публиковали SPF, а все получатели запрещали получение писем без SPF-авторизации, это вряд ли привело бы к снижению уровня спама.
SPF не защищает от подделки отправителя или спама напрямую, тем не менее, он активно используется и весьма полезен и в системах спам-фильтрации и для защиты от поддельных писем, т.к. позволяет привязать письмо к определенному домену и его репутации.
3. Заблуждение: SPF отрицательно (положительно) влияет на доставляемость писем
На самом деле: Всё зависит от типа письма и пути, по которому оно доставляется.
Объяснение: SPF сам по себе не влияет на доставляемость писем обычным потоком, и отрицательно влияет при неправильном внедрении или на непрямых потоках писем (indirect flow), когда пользователь получает письма не от того сервера, с которого письмо было отправлено, например на перенаправленные письма. Но системы спам-фильтрации и репутационные классификаторы учитывают наличие SPF, что в целом, на основном потоке писем, дает положительный результат. Если, конечно, вы не рассылаете спам.
4. Заблуждение: SPF авторизует отправителя письма
На самом деле: SPF авторизует почтовый сервер, отправляющий письмо от имени домена.
Объяснение: Во-первых, SPF работает только на уровне доменов, а не для отдельных адресов электронной почты. Во-вторых, даже если вы являетесь легальным пользователем почты определенного домена, SPF не позволяет вам отправить письмо из любого места. Чтобы письмо прошло SPF-валидацию, вы должны отправлять только через авторизованный сервер. В-третьих, если вы авторизовали сервер по SPF (например, разрешили отправку писем от вашего домена через какого-либо ESP или хостинг-провайдера) и он не реализует дополнительных ограничений, то все пользователи данного сервера могут рассылать письма от имени вашего домена. Всё это следует учитывать при внедрении SPF и аутентификации писем в целом.
5. Заблуждение: письма, не прошедшие авторизацию SPF, отсеиваются
На самом деле: SPF-авторизация или ее отсутствие в общем случае не влияет кардинально на доставку писем.
Факт наличия SPF-авторизации важен не столько для доставки письма и принятия решения о том, является ли оно спамом, сколько для подтверждения адреса отправителя и связи с доменом, что позволяет для письма использовать не репутацию IP, а репутацию домена.
На принятие решения о действии над письмом, не прошедшим авторизацию, гораздо больше влияет политика DMARC. Политика DMARC позволяет отбросить (или поместить в карантин) все письма, не прошедшие авторизацию или их процент.
7. Заблуждение: достаточно прописать SPF только для доменов, с которых отправляется почта
На самом деле: необходимо также прописать SPF для доменов, используемых в HELO почтовых серверов, и желательно прописать блокирующую политику для неиспользуемых для отправки почты A-записей и вайлдкарда.
Объяснение: в некоторых случаях, в частности, при доставке NDR (сообщение о невозможности доставки), DSN (сообщение подтверждения доставки) и некоторых автоответах, адрес отправителя в SMTP-конверте (envelope-from) является пустым. В таком случае SPF проверяет имя хоста из команды HELO/EHLO. Необходимо проверить, какое имя используется в данной команде (например, заглянув в конфигурацию сервера или отправив письмо на публичный сервер и посмотрев заголовки) и прописать для него SPF.
Спамерам совершенно не обязательно слать спам с тех же доменов, с которых вы отправляете письма, они могут отправлять от имени любого хоста, имеющего A- или MX-запись. Поэтому, если вы публикуете SPF из альтруистических соображений, то надо добавлять SPF для всех таких записей, и желательно еще wildcard (*) для несуществующих записей.
8. Заблуждение: лучше добавлять в DNS запись специального типа SPF, а не TXT
На самом деле: надо добавлять запись типа TXT.
Объяснение: в текущей версии стандарта SPF (RFC 7208) записи типа SPF являются deprecated и не должны больше использоваться.
9. Заблуждение: чем больше всего (a, mx, ptr, include) я включу в SPF-запись, тем лучше, потому что меньше вероятность ошибиться
10. Заблуждение: TTL для SPF-записи следует сделать поменьше (побольше)
На самом деле: как и для большинства DNS-записей, лучше иметь TTL в диапазоне от 1 часа до 1 суток, заблаговременно снижая его при внедрении или планируемых изменениях и повышая при стабильно работающей политике.
Объяснение: более высокий TTL снижает вероятность ошибок DNS и, как следствие, temperror SPF, но повышает время реакции при необходимости внесения изменений в SPF-запись.
11. Заблуждение: если я не знаю, с каких IP могут уходить мои письма, то лучше опубликовать политику с +all
На самом деле: политика с явным +all или неявным правилом, разрешающим рассылку от имени домена с любых IP-адресов, негативно скажется на доставке почты.
Объяснение: такая политика не несет смысловой нагрузки и часто используется спамерами, чтобы обеспечить SPF-аутентификацию на спам-письмах, рассылаемых через ботнеты. Поэтому домен, публикующий подобную политику, имеет очень большие шансы попасть под блокировку.
12. Заблуждение: SPF бесполезен
На самом деле: SPF необходим.
Объяснение: SPF — это один из механизмов авторизации отправителя в электронной почте и способ идентификации домена в репутационных системах. В настоящее время крупные провайдеры почтовых сервисов постепенно начинают требовать наличие авторизации писем, и на письма, не имеющие авторизации, могут накладываться «штрафные санкции» по их доставке или отображению пользователю. Кроме того, на письма, не прошедшие SPF-авторизации, могут не возвращаться автоответы и отчеты о доставке или невозможности доставки. Причина в том, что эти категории ответов, как правило, идут именно на адрес SMTP-конверта и требуют, чтобы он был авторизован. Поэтому SPF необходим даже в том случае, если все письма авторизованы DKIM. Также SPF совершенно необходим в IPv6-сетях и облачных сервисах: в таких сетях практически невозможно использовать репутацию IP-адреса и письма с адресов, не авторизованных SPF, как правило, не принимаются. Одна из основных задач SPF, определенная в стандарте — как раз использование репутации доменного имени вместо репутации IP.
13. Заблуждение: SPF самодостаточен
На самом деле: необходимы также DKIM и DMARC.
Объяснение: DKIM необходим для прохождения писем через различные пересылки. DMARC необходим для защиты адреса отправителя от подделок. Кроме того, DMARC позволяет получать отчеты о нарушениях политики SPF.
14. Заблуждение: если сервер пересылает письма, необходимо использовать SRS (Sender Rewriting Schema) для сохранения SPF-авторизации.
На самом деле: SRS следует использовать только в том случае, если вы хотите дать перенаправляемым письмам авторизацию (и, как следствие, репутацию) своего домена.
Объяснение: SRS перезаписывает адрес конверта отправителя на адрес из домена перенаправляющего сервера, таким образом, для письма проходит SPF-авторизация с доменом осуществляющим перенаправление. Однако, домен отправителя RFC5322.From у такого письма не будет совпадать с доменом конверта, для которого проходит SPF-авторизация. С точки зрения DMARC такая авторизация не рассматривается как валидная. Кроме того, перенаправляемое письмо получает авторизацию домена, если бывают ситуации в которых перенаправляются спам-письма (например, переправляется общий поток писем в котором даже при наличии хорошей спам-фильтрации присутствует некоторая доля спама) — это негативно затрагивает репутацию перенаправляющего домена и наоборот, распространяет репутацию домена на спам-письма. SRS имеет смысл использовать там, где входящие письма проходят дополнительную авторзацию и спам-фильтрацию, например в списках рассылки с ограничением по отправителям, возможно в сочетании с опцией From rewrite для сохранения DMARC-аутентификации. Во всех остальных случаях, лучше уделить внимание тому, чтобы пересылки сохраняли целостность DKIM-сигнатуры.
15. Заблуждение: spf1 хорошо, spf2.0 — лучше
Объяснение: spf2.0 не существует. Публикация записи spf2.0 может приводить к непредсказуемым результатам. spf2.0 никогда не существовал и не был стандартом, но отсылка на него есть в серии экспериментальных стандартов, самым известным из которых является RFC 4406 (Sender ID). Эта серия стандартов разрабатывалась независимой рабочей группой, параллельно с принятием стандарта spf, что и внесло путаницу. Sender ID, который должен был решить проблему подмены адресов, не стал общепринятым стандартом и от него следует отказаться в пользу DMARC. Даже в том случае, если вы решаете использовать Sender ID и опубликовать spf2.0 запись, она не заменит записи spf1.
Я практически закончил писать эту статью, когда меня перехватила служба поддержки пользователей и настоятельно (с угрозой применения грубой силы) рекомендовала напомнить о следующих нюансах SPF, с которыми им чаще всего приходится сталкиваться при разрешении проблем: