Spf запись для почтового сервера

Spf запись для почтового сервера

SPF и DKIM – это механизмы верификации почтового сервера, позволяющие проверить его подлинность. Многие почтовые сервера используют их при получении почты, чтобы быть уверенным в том, что получаемая почта не является спамом. Если вы организуете рассылку со своего почтового сервера, например, периодическую рассылку, либо рассылку писем от вашего интернет-магазина, вам, скорее всего, придется настраивать оба механизма, поскольку это позволит быть уверенным в том, что ваши письма доставляются и автоматически не определяются как спам.

Настройка SPF (Sender Policy Framework).

Настройка SPF является достаточно простой. Для этого достаточно создать записи DNS, определяющие, с каких серверов разрешена отправка почты для данного домена. Использоваться могут два типа записи – TXT и SPF.

В данном примере указывается, что отправка почты данного домена разрешена только с хоста с адресом , для которого есть записи типа A и MX, со всех остальных отправка запрещена.

После добавления записей не забудьте изменить serial для зоны DNS и перезагрузить информацию о доменной зоне. Если вы всё сделали правильно, то при отправке письма на другой домен, например, на gmail.com, в заголовках письма вы увидите следующий заголовок:

SPF-запись — проверка отправителя.

Как всем известно, протокол отправки электронной почты SMTP, подразумевает, что в качестве отправителя можно указать любой почтовый ящик. Таким образом можно послать письмо, подставив в поле «From» вымышленное значение. Процесс такого почтового обмана называется Спуфинг (e-mail spoofing). Чтобы бороться с этим явлением, был разработан и введен в действие стандарт SPF – Sender Policy Framework (структура политики отправителя).

SPF позволяет владельцу домена указать в TXT-записи домена специальным образом сформированную строку, указывающую список серверов, имеющих право отправлять email-сообщения с обратными адресами в этом домене.

Рассмотрим простой пример SPF-записи:

example.org. IN TXT «v=spf1 +a +mx -all»

Теперь более детально о допустимых опциях. Рассмотрим варианты поведения получателя, в зависимости от используемых опций:

  • «v=spf1» — используемая версия SPF.
  • «+» — принимать корреспонденцию (Pass). Этот параметр установлен по умолчанию. Тоесть, если никаких параметров не установлено, то это «Pass»;
  • «-» — Отклонить (Fail);
  • «

» — «мягкое» отклонение (SoftFail). Письмо будет принято, но будет помечено как СПАМ;

  • «?» — нейтральное отношение;
  • «mx» — включает в себя все адреса серверов, указанные в MX-записях домена;
  • «ip4» — опция позволяет указать конкретный IP-адрес или сеть адресов;
  • «a» — указываем поведение в случае получения письма от конкретного домена;
  • «include» — включает в себя хосты, разрешенные SPF-записью указанного домена;
  • «all» — все остальные сервера, не перечисленные в SPF-записи.
  • Итак, попробуем разобраться, что же значит SPF-запись, указанная выше.

    • «+a» — разрешает прием писем от узла, IP-адрес которого совпадает с IP-адресом в A-записи для example.org;
    • «+mx» — разрешает прием писем, если отправляющий хост указан в одной из MX-записей для example.org;
    • «-all» — все сообщения, не прошедшие верификацию с использованием перечисленных механизмов, следует отвергать.

    Для лучшего понимания того, как работает SPF, рассмотрим еще один, более сложный пример:

    example.org. IN TXT «v=spf1 mx ip4:78.110.50.123 +a:mail.ht-systems.ru include:gmail.com

    Теперь более подробно о используемых опциях.

    • «mx» — принимать письма от серверов, указанных в MX-записях;
    • «ip4:78.110.50.123» — принимать письма, отправленные с IP-адреса 78.110.50.123;
    • «+a:mail.ht-systems.ru» — то же, что и a:mail.ht-systems.ru. Принимать от mail.ht-systems.ru;
    • «include:gmail.com» — принимать письма с серверов, разрешенных SPF-записями gmail.com;
    • «

    all» — принимать письма со всех остальных серверов, но помечать их как СПАМ

    А теперь рассмотрим еще более «экзотичный» пример. В описании возможных опций указывалось, что возможно указание сетей ip-адресов. Стоит отметить, что это применимо и к записям «a» и «mx». Рассмотрим следующий пример:

    example.org. IN TXT «v=spf1 mx/24 a:hts.ru/24 -all»

    «mx/24» — в список разрешенных отправителей входят все IP-адреса, находящихся в тех же сетях класса С, что и MX-ы домена;
    «a:hts.ru/24» — в список разрешенных отправителей входят все IP-адреса, находящихся в тех же сетях класса С, что и А-записи домена hts.ru;
    «-all» — всех остальных отправителей — блокируем.

    Иногда можно встретить следующие записи (очень редко):

    «ptr» — проверяет PTR-запись IP-адреса отправителя. Если она сходится с указаным доменом, то механизм проверки выдает положительный результат. Тоесть, разрешено отправлять всем IP-адресам, PTR-запись которых направлены на указанный домен. Серьезным недостатком даного метода есть то, что генерируется очень большое количество DNS-запросов;
    «exists» — выполняется проверка, резолвится ли домен на какой-либо IP-адрес. Тоесть, по существу, выполняется проверка работоспособности доменного имени. Кстати, не имеет значения, на какой IP-адрес резолвится домен, даже если это «серые» сети (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) или loopback (127.0.0.1).

    example.org. IN TXT «v=spf1 ptr:example.org exist:example.org -all»

    Также не будет излишним ознакомиться со следующими опциями: redirect и exp.

    «redirect» — указывает получателю, что нужно проверять SPF-запись указаного домена, вместо текущего домена. Пример:

    Читайте также:  Drivedroid как установить windows

    example.org. IN TXT «v=spf1 redirect:example.com

    В даном примере будет проводится проверка SPF-записи домена example.com, а не example.org.

    «exp» — использование даной опции позволяет задать сообщение о ошибке, которое будет передано отправителю при возникновении таковой. Размещается в конце SPF-записи, даже после опции all. Рассмотрим более детально механизм работы опции exp.

    Допустим, что у домена example.org следущая SPF-запись:

    example.org. IN TXT «v=spf1 +a +mx -all exp=spf.example.org»

    Теперь содаем TXT-запись для домена spf.example.org:

    spf.example.org. IN TXT «You host not allowed e-mail to me»

    В результате этих шаманских действий SPF-запись будет контролировать, чтобы почта доставлялась только от валидных хостов, а всем остальным будет отправляться сообщение о ошибке, прописанное в TXT-записи домена spf.example.org.

    Так же стоит обратить внимание, что любое решение о блокировке или маркировке письма как спам, решает программа которая обрабатывает получение почты на сервере, иногда даже почтовые программы это тоже делают.

    Технический блог специалистов ООО"Интерфейс"

    • Главная
    • Почтовый сервер для начинающих. PTR и SPF записи как средство борьбы со спамом

    Почтовый сервер для начинающих. PTR и SPF записи как средство борьбы со спамом

    • Автор: Уваров А.С.
    • 09.10.2013

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

    Основная проблема современных почтовых систем — спам. Существует много разных методик борьбы с ним, но основная — анализ отправителя, учитывая что вся необходимая информация в письме имеется.

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

    Допустим вы получили на почте крайне подозрительного вида посылку, якобы от любимого дедушки Константина Макаровича, но почему то штемпель отправителя указывает не на почтовое отделение села Макаровки, а на хутор Гадюкино совсем в другом конце страны. Будете вы открывать такую посылку, рискуя обнаружить вместо банки варенья из райских яблочек споры сибирской язвы, или отправите ее назад, от греха подальше?

    Точно также и в системах электронной почты. Если вам пришло письмо от дедушки konstantin-makarovich@example.com, но сервер отправитель почему-то mail.spam.com, то это повод не принимать такое письмо, так как оно с большой долей вероятности является спамом.

    Каким образом мы осуществили данную проверку? Очень просто, посмотрели на штемпель почтового отделения отправителя и сравнили его с обратным адресом. Например на конверте написано, что отправитель находится в городе Москва, однако на штемпеле отделения-отправителя стоит индекс 683000, который указывает на Петропавловск-Камчатский. Следовательно такое письмо мы принимать не будем, так как оно не прошло проверку отправителя.

    Аналогично обстоит дело и с электронным письмом, только вместо индекса отделения-отправителя используется PTR-запись. Так получив письмо от дедушки, мы сделаем PTR-запрос и выясним, что сервер отправитель у нас mail.spam.com, в то время как согласно переданной при соединении информации должен быть mail.example.com. Все понятно, письмо падает в спам.

    Однако если в заголовке будет указано, что сервер отправитель у нас mail.spam.com, то такое письмо успешно пройдет проверку по PTR-записи, не смотря на то, что домен сервера отправителя не совпадает с почтовым доменом письма.

    Почему так происходит? Потому что проверка по PTR-записи позволяет определить лишь то, что сервер-отправитель действительно тот, за кого себя выдает. Но никоим образом не определяет подлинность самого отправителя. Т.е. обращаясь к примеру обычной почты мы проверяем лишь то, что обратный адрес и индекс отделения отправителя совпадают, если место отправления Москва, а индекс указывает на Петропавловк-Камчатский, то проверку по PTR такое письмо не прошло, а если место отправления и индекс совпадают, то все нормально и теперь уже ваша задача думать, что делает ваш любимый дедушка в Петропавловске-Камчатском.

    Непонимание этого момента приводит к тому, что PTR-запись оказывается настроена неправильно и, как результат, большая часть отправляемой почты не доходит до адресата. Особенно важно это понимать при настройке серверов обслуживающих несколько доменов. В этом случае PTR-запись должна указывать на имя почтового хоста (которое он передает в рамках SMTP-сессии), даже если он расположен в другом домене.

    Разберем простой пример.

    Сервер mail.example.com отправляет письмо для обслуживаемого им домена eхample.org. Сервер-получатель делает запрос PTR-записи и убеждается, что по адресу 123.123.123.123 действительно находится mail.example.com, следовательно такое письмо будет принято, хотя домен отправителя письма и домен сервера-отправителя не совпадают.

    Читайте также:  Ipad safari не удается открыть страницу

    А теперь иная ситуация.

    Администратор неправильно настроил DNS-зону, указав неправильный хост в PTR-записи. Cервер-получатель, проверив PTR-запись отклонит наше письмо, так как сервер отправитель не совпадает с результатом обратного DNS-запроса.

    Отсутствие PTR-записи практически всегда ведет к отклонению письма, потому как существует негласное соглашение о том, что добросовестный отправитель имеет правильно настроенную обратную зону.

    Вернемся к нашему дедушке. Допустим он сообщил вам, что летом собирается выезжать из села Макаровки в соседнее село Ивановка, к некой Марфе Васильевне и намерен оттуда посылать вам корреспонденцию. В таком случае вы без опаски будете принимать письма от дедушки как из Макаровки, так и из Ивановки, но откажетесь от якобы дедушкина письма из Петропавловска-Камчатского.

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

    Что она означает? То, что для домена example.сom почту могут отправлять узлы указанные в А-записи (+а) и MX-записях (+mx), всю остальную почту следует отклонять (-all).

    Однако не все так радужно. Во первых, поддержка SPF все еще не является стандартом де-факто и отсутвие SPF-записи у домена отправителя не повод отклонять письмо. Вторая проблема — сервера пересылки или случаи когда почту отправляют сервера не указанные в А или MX записях, а то и вообще находящиеся в других доменах. Это может быть обусловлено как архитектурой IT-системы предприятия, так и использованием для отправки чужих серверов, когда вы привязываете свой домен к провайдерскому или публичному сервису. В последнем случае нужно быть особо осторожным и крайне желательно проконсультироваться с поддержкой сервиса.

    Рассмотрим еще одну ситуацию.

    Ваша компания, кроме своего основного почтового сервера mail.example.com, использует услуги сторонних сервисов, которые могут отправлять почту клиентам компании от ее имени. Это может быть сервис экспресс-почты, который от вашего имени будет уведомлять клиентов о статусе доставки и т.п.

    В нашем примере такая почта будет отправляться от имени zakaz@example.com с сервера mail.web-service.com, так как данный сервер не указан в MX-записях домена example.com, то, согласно указанному нами в SPF-записи правилу, такое письмо будет получателем отклонено.

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

    В отличие от -all (fail),

    all (soft fail) обозначает, что отправители, кроме указанных явно, не имеют права отправлять почту, но не содержит требования отклонять такие письма. Чаще всего такая почта принимается, помечаясь как нежелательная.

    Можно также использовать нейтральный префикс:

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

    Как быть в нашем случае? Самым правильным решением будет добавить в SPF-запись еще одно правило:

    в первом случае мы разрешим прием почты также от всех серверов, перечисленных в MX-записях домена web-service.com, во втором случае только для сервера mail.web-service.com.

    В завершение рассмотрим случай, когда почта для вашего домена обслуживается сервером находящимся в другом домене. Например mail.example.com отправляет также почту для домена example.org. В этой ситуации будет правильно использовать для домена example.org те же самые правила, что и для example.com. Для этого используйте специальный вид записи:

    Это позволит при необходимости изменять записи только один раз, для основного домена и избавляет администраторов иных обслуживаемых доменов от необходимости отслеживать и вносить изменения в DNS-записи.

    SPF (Sender Policy Framework) — это DNS-запись, содержащая список доверенных серверов, с которых может отправляться почта данного домена, и сведения о механизме обработки писем, отправленных с других серверов. Корректная настройка SPF позволит снизить вероятность рассылки спама злоумышленниками от вашего имени.

    В панели Timeweb SPF настраивается в разделе "Домены и поддомены" — "Настройки DNS" — "Добавить DNS запись" — "TXT". Если TXT-запись с параметрами SPF уже создана, необходимо ее отредактировать. Не рекомендуется создавать несколько SPF-записей для домена, так как это может вызывать проблемы с доставкой почты.

    Для доменов, делегированных на наши NS-серверы, SPF-запись указывается автоматически и выглядит примерно следующим образом:

    Такая запись означает, что письма с данного домена могут отправляться из подсетей 176.57.223.0/24 и 92.53.116.0/22, а письма, пришедшие с других серверов (all), должны проходить дополнительную проверку (

    Читайте также:  Le37a557 samsung мутное изображение

    Основной синтаксис

    Любая SPF-запись начинается с v=spf1, этот параметр не изменяется. Он указывает на версию записи, и в настоящее время поддерживается только spf1.

    Далее указываются параметры (механизмы). Чаще всего используются следующие: all, ip4, ip6, a, mx, include, redirect. Также существуют, но используются значительно реже: ptr, exists, exp. Они все будут рассмотрены ниже.

    Помимо механизмов используются префиксы (определители):

    • "+" — Pass, принимать почту. Прописывать этот параметр необязательно, он установлен по умолчанию (т.е. значения "+a +mx" и "a mx" — идентичны).
    • "" — Fail, отклонять почту.
    • "

    " — SoftFail, "мягко" отклонять (принимать почту, но помещать ее в "Спам").

  • "?" — нейтрально (обрабатывать как обычное письмо).
  • Параметр "all" подразумевает все серверы, не упомянутые отдельно в SPF-записи. "All" задает обработку полученных с них писем и указывается в конце записи.

    — принимать почту только из подсети 176.57.223.0/24; письма с других адресов должны быть помечены как спам.

    — принимать почту только с A-записи домена; письма с других адресов должны отвергаться.

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

    В последующих примерах мы не будем дополнительно комментировать значения параметров

    all и -all в SPF-записях.

    ip4 / ip6

    Используется для указания конкретных адресов и подсетей, из которых могут отправляться письма. Синтаксис для IPv4 и IPv6 идентичен.

    — принимать почту из подсети 176.57.223.0/24.

    — принимать почту с IPv6-адреса 2001:db8::10.

    IP отправителя проверяется на соответствие A-записи домена.

    — принимать почту с A-записи текущего домена.

    — принимать почту с A-записи домена sub.domain.com.

    IP отправителя проверяется на соответствие IP-адресам серверов, указанных в MX-записях домена. На текущий день для многих современных сервисов эта директива уже не так важна, так как серверы входящей и исходящей почты зачастую имеют разные IP.

    — принимать почту с MX-серверов текущего домена и домена sub.domain.com.

    — принимать почту из подсети, в которую входят MX-серверы текущего домена.

    include

    Позволяет учитывать в SPF-записи настройки SPF другого домена.

    — принимать почту с A-записи текущего домена и серверов, указанных в SPF-записи домена other-domain.com.

    При такой настройке проверяется SPF домена other-domain.com; если это, допустим, "v=spf1 a -all", то далее IP отправителя проверяется на соответствие A-записи домена other-domain.com.

    redirect

    Технически, redirect является модификатором, а не механизмом. Он выполняет одну основную функцию: сообщает, что необходимо применять настройки SPF другого домена.

    — почта должна приниматься или отклоняться согласно настройкам домена other-domain.com.

    Прочие механизмы

    Здесь мы рассмотрим оставшиеся механизмы, которые используются в настройках значительно реже.

    PTR-запись IP-адреса отправителя проверяется на соответствие указанному домену. Данный механизм требует большого количества DNS-запросов при проверке, поэтому без острой необходимости использовать его в SPF не рекомендуется.

    — принимать почту со всех адресов, PTR-запись которых направлена на домен other-domain.com

    exists

    Запрашивается А-запись указанного домена; если она существует, проверка считается пройденной. Другими словами, проверяется, резолвится ли домен на какой-либо (любой) IP-адрес.

    — принимать почту, если существует A-запись домена mydomain.com.

    Параметр "exp" применяется для отправки сообщения об ошибке отправителю письма. С помощью "exp" в SPF прописывается определенный поддомен, в TXT-записи которого указан текст сообщения об ошибке. Имя поддомена и текст ошибки может быть любым.

    Параметр "exp" всегда указывается в конце записи (после all).

    При этом TXT-запись домена error-spf.mydomain.com содержит: "Not authorized to send mail for this domain".

    Примеры настроек

    Настройка SPF для "Почты для доменов" от Mail.Ru

    (подробнее о настройке DNS для Mail.ru см. здесь)

    Если вы отправляете почту только с серверов Mail.Ru:

    Если вы отправляете почту так же и с других серверов (укажите IP-адреса или подсети вместо IP1, IP2 и т.д.):

    Настройка SPF для Яндекс.Почты

    (подробнее о настройке DNS для Яндекса см. здесь)

    При использовании только серверов Яндекса:

    При использовании также и других серверов (укажите IP-адреса или подсети вместо IP1, IP2 и т.д.):

    Настройка SPF для Google

    (подробнее о настройке DNS для Google см. здесь)

    При использовании только серверов Google:

    При использовании также и других серверов (укажите IP-адреса или подсети вместо IP1, IP2 и т.д.):

    Другие примеры

    — принимать почту с IP-адресов, соответствующих A-записям текущего домена, с IP-адреса 176.57.223.12 и серверов, указанных в SPF-записи domain2.com; прочие письма отклонять.

    — принимать почту из подсети, в которую входят MX-серверы текущего домена, и из подсети, в которую входят A-записи домена domain2.com; прочие письма отклонять.

    — принимать почту с A-записи текущего домена, IP-адреса 176.57.223.12, а также с серверов, указанных в SPF домена domain2.com.

    Ссылка на основную публикацию
    Adblock detector