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


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 ~all»

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

 

  • «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-запись указаного домена, вместо текущего домена. Пример:

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

В даном примере будет проводится проверка 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.

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

adminunix.ru

Настройка SPF и DKIM

Проверить SPF запись можно при помощи специального сервиса, расположенного по адресу http://mxtoolbox.com/spf.aspx.
Чтобы приступить к проверке в поле «Domain Name» необходимо указать имя своего домена, для которого настраивалася SPF запись. В поле «IP (Optional)» можно ничего не указывать. После заполнения поя необходимо нажать на кнопку «SPF Record Lookup».

Если настройка выполнена неправильно или совсем не заполнена, появится сообщение «Записей не найдено». При корректном заполнении записи, появится две таблицы. В первой таблице будут отображены все настройки, прописанные в SPF-записи, то есть значения таблицы у каждого почтового сервера будут отличаться.

Вторая таблица содержит следующие поля:

  • Record Published;
  • Syntax Check;
  • Multiple Records;
  • Record Deprecated;
  • Included Lookups.

На втором этапе проверки рекомендуется отправить письмо с доверенного севера, то есть с того, для которого осуществлялась настройка, на почтовый ящик, зарегистрированный на google.com. Когда письмо придет на почтовый ящик test@gmail.com (вместо test указать свой ящик), его необходимо открыть. Затем, нажать на стрелку, позволяющую развернуть меню, чтобы выбрать пункт «Показать оригинал». В открывшемся окне следует отыскать запись «Received-SPF». Если у этого атрибута стоит значение «pass», значит, настройка произведена корректно.

Советы по работе с SPF записью

Настроить SPF запись, может даже неопытный пользователь, достаточно всего лишь следовать инструкции. Чтобы не возникло сложностей, необходимо придерживаться следующих советов:

  • Рекомендуется тщательным образом проверить, сервер, предназначенный для отправки писем. Если хотя бы один сервер будет пропущен, может произойти потеря важной корреспонденции;
  • Важно создать SPF-запись домену со вторым уровнем. Это можно сделать как для личного, так и для рабочего домена;

  • Пользователям рекомендуется устанавливать SPF запись как для популярных почтовых серверов, так и для своих собственных;
  • Если будет выбран неверный механизм обработки, переадресация будет выполнена не корректно;
  • При наличии большого числа серверов, делящихся на филиалы и географию, рекомендуется воспользоваться механизмом «include»;
    После настройки SPF-записи, рекомендуется изучить принцип работы DKIM технологии.

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

Благодаря вышеописанным советам, можно снизить вероятность попадания писем в спам. Однажды настроив SPF запись для почтового сервера, можно забыть о проблеме с получением писем. Рекомендуется все делать по инструкции и тогда с настройками справится даже неопытный пользователь.

steptosleep.ru

SPF (Sender Policy Framework) — дает возможность добавить DNS записи типа TXT к доменному имени и указать в них IP адреса серверов, с которых разрешена отправка электронной почты. Это необходимо для защиты репутации домена и снижения вероятности попадания писем в спам. Дело в том, что при отправке письма, можно подставить абсолютно любой адрес отправителя в поле "From:", чем и пользуются злоумышленники при рассылке спама и фишинга от чужого имени. Такие рассылки могут значительно навредить репутации вашего домена, и создать проблемы с доставкой электронной почты с вашего домена. А вот IP адреса почтового сервера, с которого была произведена отправка, подделать нельзя. Соответственно если SPF запись для домена есть, то почтовые службы сначала проверят с того ли IP адреса идет рассылка и если не с того, то будут действовать согласно правилам указанным в SPF.


Как создать SPF запись

Как уже писалось выше, SPF это обычная текстовая запись, но данные указываются с использованием определенного синтаксиса, который мы сейчас и рассмотрим.
Пример SPF записи: "v=spf1 +a +mx -all". Означает эта запись следующее — принимать почту с IP адресов, которые указаны в DNS записях типа A и MX для этого же домена (имеется ввиду домен, для которого это запись указана), со всех остальных почту отклонить. Можно ее немного укоротить и написать так: "v=spf1 a mx -all", результат работы будет тот же. Рассмотрим синтаксис более детально.

  • "v=spf1" — используемая версия SPF. На текущий момент она одна, первая версия.
  • "+" — принимать почту. Этот параметр установлен по умолчанию, его отсутствие означает то же самое, что и его наличие.
  • "-" — отклонять почту.
  • "~" — принимать почту, но помещать ее в спам.

  • "?" — относится нейтрально. То есть, принимать как обычное письмо.
  • "mx" — содержит IP адреса всех серверов, указанных в DNS записях типа MX для домена.
  • "ip4" — позволяет указать конкретные IPv4 адреса.
  • "ip6" — то же, что и "Ip4", только указывается IPv6 адрес.
  • "a" — указывает на IP адреса, которые указаны в DNS записях типа A для домена.
  • "include" — разрешает получение почты, согласно SPF другого домена.
  • "all" — все остальные, не перечисленные в SPF записи.

Рассмотрим сложный пример SPF записи

"v=spf1 mx a ip4:154.56.125.94 a:some-domain.com mx:some-domain.com include:some-domain.com ~all"
mx — принимать почту со своих почтовых серверов.
a — принимать почту с серверов, которые указаны в записях типа A для своего домена.
ip4:154.56.125.94 — принимать почту отправленную с IP 154.56.125.94. Также можно указывать подсети в формате 154.56.125.0/24.
a:some-domain.com — принимать почту с серверов, которые указаны в записях типа A для домена some-domain.com.


есь также есть возможность указать подсеть в формате some-domain.com/24.
mx:some-domain.com — принимать почту с почтовых серверов, указанных в записях типа MX для домена some-domain.com. Возможно указание подсети аналогично с a:some-domain.com.
include:some-domain.com — разрешает получать почту согласно правилам, указанным в SPF для домена some-domain.com.
~all — помещать в спам все письма, отправленные с адресов, не указанных в SPF. Если указать -all, почта будет отклонятся.
Это наиболее часто используемые конструкции для создания SPF, но есть и другие, редко используемые, но о которых стоит знать.​

  • "ptr" — проверяется PTR запись IP адреса отправителя на совпадение с указанным доменом.
    "v=spf1 ptr:your-domain.com -all"
  • "exists" — проверяется резолвится ли домен по какому либо IP адресу, причем IP адрес может быть абсолютно любой.
    "v=spf1 exists:your-domain.com -all"
  • "redirect" — говорит о том, что правила в SPF записи необходимо проверять на другом домене, а не на текущем.
    "v=spf1 redirect:some-domain.com -all"
  • "exp" — позволяет указать текст, который будет отправляеться отправителю письма в случае не соответствия правил, указанных в SPF. Указывается самым последним.
    "v=spf1 a mx -all exp=spferror.your-domain.com"
    Небольшое пояснение, для того, что бы отдавался текст ошибки, необходимо создать домен spferror.your-domain.com и добавить для него TXT запись с желаемым текстом.

hostgid.net

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

Если у вас есть сомнения в корректности и достоверности какой-либо информации, никогда не будет лишним обратиться к первоисточнику. Точно также и с SPF — в интернете очень много любительских статей о лучших практиках создания и использования SPF, но лично меня все эти советы лишь ввели в заблуждение. Именно поэтому открываем RFC 7208 и начинаем разрушать мифы.

Рекомендую к прочтению перечень статей ниже:

  • Базовые DNS-записи для почтового сервера
  • Технология DKIM для почтового сервера

Итак, переходим к SPF.

Назначение

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

Even more precisely, SPFv1 allows the owner of a domain to specify their mail sending policy, e.g. which mail servers they use to send mail from their domain.

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

Основы протокола

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

Задача SPF — проверить содержится ли адрес отправляющего сервера в записи SPF домена. Если адрес содержится, значит spf=pass, в противном случае spf=fail.

При этом SPF не должен однозначно отвечать на вопрос «Блокировать принимаемое сообщение или нет?». Это должен делать ваш антиспам сервис на основе различных оценок и критериев, среди которых результат проверки SPF является лишь одним из многих. Это подтверждается и заключениями в RFC:

SPF «fail» results can alternately be used as one input into a larger set of evaluations that might, based on a combination of SPF «fail» results with other evaluation techniques, result in the email being marked negatively in some way (this might be via delivery to a special spam folder, modifying subject lines, or other locally determined means).

Поэтому рекомендуемым вариантом является использование политики softfail (директива ~all один раз в записи и только в самом конце) во всех возможных случаях, чтобы исключить отклонение валидных писем, не прошедших проверку SPF (а такое бывает). Использовать -all целесообразно для доменов, с которых почта не отправляется.

HELO/EHLO и MAIL FROM

Проверяемый домен извлекается из конвертного заголовка MAIL FROM (другие названия — Return-Path, Bounce address, Envelope from) 2. Однако в некоторых случаях необходимо оставлять заголовок MAIL FROM пустым. Например это используется при отправке NDR, DSN 3:

Whenever an SMTP transaction is used to send a DSN, the MAIL FROM command MUST use a NULL return address, i.e. «MAIL FROM:<>».

Если же MAIL FROM пустой, нужный домен будет извлекаться из ответа HELO/EHLO отправляющего сервера.

Более того, RFC рекомендует сначала выполнять проверку HELO/EHLO как наименее ресурсоемкую по сравнению с MAIL FROM. Именно поэтому одной из рекомендаций RFC является также создание SPF-записи для DNS-имени, которое сервер отправляет в приветствии HELO/EHLO.

Принцип работы SPF подсказывает ещё одну особенность этого протокола — результаты его работы абсолютно незаметны для конечного пользователя. Действительно, MAIL FROM является конвертным заголовком и юзеру не виден, при этом заголовок From самого сообщения может содержать вообще другой адрес (от подмены этого заголовка защищает совсем другой протокол — DKIM, о котором читайте в статье Технология DKIM для почтового сервера). HELO/EHLO не видны пользователю тем более, при том они ещё и маскируется в конвертных заголовках Received 4. А другие данные SPF не анализирует.

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

Если бегло пробежаться по RFC 7208, натыкаешься на очень любопытные ограничения, которые можно запросто упустить из виду, например:

  • Допускается использование только записей TXT. Любые другие типы (например SPF) как минимум считаются экспериментальными, а как максимум не поддерживаются вовсе;
  • Для каждого имени должна существовать лишь одна единственная запись SPF, множественные записи не поддерживаются. При этом допускается разделение одной записи на несколько частей, если суммарное количество символов превышает 255. Все же желательно, чтобы запись была как можно короче;
  • Не используйте записи PTR внутри SPF, стандарт это запрещает в явном виде:

5.5. «ptr» (do not use)

This mechanism SHOULD NOT be published.

Note: This mechanism is slow, it is not as reliable as other mechanisms in cases of DNS errors, and it places a large burden on the .arpa name servers. If used, proper PTR records have to be in place for the domain’s hosts and the «ptr» mechanism SHOULD be one of the last mechanisms checked. After many years of SPF deployment experience, it has been concluded that it is unnecessary and more reliable alternatives should be used instead.

  • Запись должна содержать как можно меньше вложений вида a, mx, include (и ptr конечно), поскольку они требуют выполнения DNS-запросов для получения ip-адреса, а реализация SPF запрещает выполнение более 10 запросов. Почитать подробнее об этом ограничении вы можете в статье 10 DNS-запросов для одной SPF-записи;
  • Расположите DNS-зависимые директивы в конце записи, а ip4/ip6 — в начале;
  • Помните, что SPF-запись вы внедряете для получателей ваших писем, чтобы им было проще идентифицировать вас как надежных отправителей вашего домена. Эта запись никак не влияет на объем спама, который приходит на ваш домен от сторонних отправителей.

Для получения более подробной информации обращайтесь к первоисточнику. Если совсем лень читать на английском, то могу порекомендовать замечательную статью от Mail.ru — Загадки и мифы SPF. А я перехожу к долгожданным примерам.

blog.bissquit.com

ptr-spf-antispam-000.jpg

В наших прошлых материалах мы уже рассматривали настройку 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-сессии), даже если он расположен в другом домене.

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

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

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

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

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

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

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

example.com. IN TXT "v=spf1 +a +mx -all"

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

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

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

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

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

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

example.org. IN TXT "v=spf1 +a +mx ~all"

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

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

example.org. IN TXT "v=spf1 +a +mx ?all"

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

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

example.org. IN TXT "v=spf1 +a +mx +mx:web-service.com -all"

или

example.org. IN TXT "v=spf1 +a +mx +a:mail.web-service.com -all"

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

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

example.org. IN TXT "v=spf1 redirect=example.com"

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

interface31.ru

Тонкости правильной настройки SPF записей на собственном сервере при делегировании MX записей на сторонний сервер.

Изменение MX записей

SPF Запись в DNS владельца домена тип TXT.

Данная запись позволяет не попасть вашему письму в спам или отклониться сервером получателя письма (при условии поддержки технологии SPF сервером получателя).

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

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

Отправив почту с почтового клиента, вы получите свое письмо обратно.

Если же она отправлялась функцией sendmail mailutils msmtp, то оно честно вернется к серверу и удачно там умрет.

Пример SPF-данных в TXT-записи DNS:

v=spf1 ip4:188.138.84.111 ip4:188.138.85.107 a mx ~all
v=spf1 ip4:111.111.111.111 ip4:222.222.222.222 a mx ~all

А вот так рекомендует поступить яндекс, в случае если ваша почта делегирована на яндекс.

v=spf1 redirect=_spf.yandex.ru

При создании веб сервера в последнюю очередь думаешь о TXT записях в доменном имени сервера и самих доменов на вашем сервере, а зря. Уделить им особое внимание требуется.

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

Даже делегировав почту на яндекс, у вас будут проблемы с ней.

Все дело в тонкости, которую яндекс не описывает в своих мануалах.

Дело в том, что отправленные письма вашим сервером теперь знают только об IP адресах серверов яндекс, но забывает про свои IP и все работает хорошо до момента, когда ваш сервер отправляет почту, используя PHP который отправляет почту локально, а данного айпи в записях SPF у яндекса естественно нет!

Изменение MX записей

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

А вот ваш сервер отправляющий почту от вашего имени, как правило, это формы обратной связи и т. д. Так же честно отправляет почту, клиент, получив ее, запрашивает SPF и, вуаля, попадает опять на яндекс. Логично было бы указать в таком случае все ваши айпи в SPF и яндекса в придачу, но сколько у него их? Следовательно, нужно сделать нечто среднее. Указать все местные айпи, и добавить все те айпи, которые есть у spf.yandex.ru. В таком случае почта будет уходить как и от яндекс, и их айпи убавлять и добавлять будут они сами, так и наши айпи попадут в зону доверия.

Вот ответ яндекса на мой вопрос о возможности наличия вышеуказанной коллизии.

Здравствуйте, Виктор

Если Вы хотите отправлять письма не только с серверов Яндекса, Вам необходимо изменить значение SPF-записи. Вместо «v=spf1 redirect=_spf.yandex.ru» необходимо указать следующее значение: «v=spf1 ip4:IP-1 ip4:IP-2 ip4:IP-3 include: _spf.yandex.ru ~all», где IP-1, IP-2, IP-3 — адреса тех серверов, с которых дополнительно отправляются письма. В ином случае (если не указать таким образом серверы), доставка письма будет успешной только в том случае, если сервер получателя не проверяет SPF-запись.

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

От себя добавлю только дополнительно +mx на всякий случай.

Получилось так:

Изменение MX записей

klondike-studio.ru

Недавно мы настраивали SMTP-сервер для нашего проекта. Вопрос стоял так: что нужно сделать, чтобы письма, отправленные нашим пользователям, не попадали в папку со спамом или попадали туда как можно реже?

Было найдено несколько интересных и полезных статей на эту тему (ссылки в конце статьи), на основе которых и было всё сделано в итоге. Но получив сегодня утром очередную порцию рассылки от достаточно известных русскоязычных ресурсов и увидев, что они пренебрегают описанными правилами, я решил кратко и в одном месте собрать все действия, которых достаточно для решения проблемы. Надеюсь, что после этого количество сайтов, отправляющих почту как надо, возрастет.

Приведенные советы актуальны только если вы используете свой собственный SMTP-сервер. При использовании, например, SMTP сервера Google всё уже сделано за нас. Как правило. В любом случае рекомендую проверить (см. подразделы Как проверить?).

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

Пропишите Reverse DNS

Название говорит само за себя. Reverse DNS lookup — процедура обратная DNS lookup. По IP адресу мы, а точнее почтовый сервер пользователя, получаем доменное имя. Если он совпадает с доменным именем в поле From, отправляемого письма, то всё в порядке.

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

Как проверить?
Используйте любой из online-сервисов Reverse DNS lookup. Например, этот. Достаточно ввести IP-адрес сервера, с которого производится отправка почты. Если в результате отображается ваш домен, то всё в порядке.

Настройте DomainKeys

DomainKeys Identified Mail (DKIM) — метод, позволяющий убедиться, что почта отправлена тем, кто имеет на это право. По сути это протокол цифровой подписи письма.

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

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

openssl genrsa -out private.pem 1024 openssl rsa -pubout -in private.pem -out public.pem 

В любом случае дальнейшие шаги следующие:

  1. Настроить ваш SMTP-сервер.
  2. Прописать две записи в DNS.

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

В DNS своего домена теперь надо прописать две TXT-записи:
_domainkey.example.com. TXT "t=s; o=~;"
mail._domainkey.example.com. TXT "k=rsa; t=s; p={REPLACE_WITH_PUBLIC_KEY_CONTENT}"

mail — это селектор DomainKeys. По факту может быть любым идентификатором, но должен совпадать с тем, что указан в настройках DKIM SMTP-сервера.

Как проверить?
Отправьте почту через ваш сервис на любой GMail-аккаунт. Откройте полученное письмо и выберите в меню действий пункт Show Original.

Если вы найдете следующую строчку, то всё в порядке:
Authentication-Results: ... dkim=pass

Настройте DNS записи SPF

Sender Policy Framework — система, позволяющая указывать IP-адреса, с которых разрешена отправка в DNS-записях домена.

Как сделать?
Подробное описание синтаксиса доступно здесь.

В большинстве случаев достаточно следующей записи:
example.com. TXT v=spf1 a mx ~all

Эта запись говорит о том, что почту можно отправлять с любого IP, указанного в записях A (AAAA) и MX данного домена и только с них.

Как проверить?
Отправьте почту через ваш сервис на любой GMail-аккаунт. Откройте полученное письмо и выберите в меню действий пункт Show Original.

Если вы найдете следующие строчки, то всё в порядке:
Received-SPF: pass
Authentication-Results: ... spf=pass

Итого

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

habr.com

Основы SPF

В SPF используется 3 блока:

  1. Версия

  2. Префикс-механизм

  3. Модификатор

Версия на данный момент только одна — “v=spf1”.

Префиксы:

  • "+" Pass — принимать сообщения. Параметр по умолчанию

  • "-" Fail — не принимать сообщения

  • "~" SoftFail — отправлять в СПАМ

  • "?" Neutral — нейтральное отношение, требуется дополнительная проверка.

Основные механизмы:

  • all — любой сервер

  • ip4, ip6 — адрес сервера,

  • a, mx — сервер из DNS записи A или MX соответственно

  • include — взять данные с другого адреса

Модификаторы:

  • redirect — использовать данные другого адреса

  • exp — ссылка на сообщение при отказе принятия сообщения

Примеры

v=spf1 -all

Игнорировать всю почту с домена.

 

v=spf1 +a +mx -all

Принимать сообщения с серверов указанных в A и MX записях, сообщения с остальных серверов должны быть отклонены.

 

v=spf1 +mx ~all

Принимать сообщения с серверов указанных MX записях, сообщения с остальных серверов будут приняты, но отправлены в СПАМ.

 

v=spf1 redirect:example.com

Забрать все правила с домена example.com.

 

v=spf1 ip4:example.com/24 -all

Доверять всей почте из адресного пространства example.com класса C (например, есле example.com имеет ip адрес 10.123.41.12, то доверие будет всем 10.123.41.[0-255]). Остальная почта будет проигнорирована.

Какие могут быть серверы отправки почты?

Условно серверы отправки почты можно разделить на 3 группы:

  1. Популярные почтовые сервисы, к которым вы привязали свой домен. Например: Google App, Yandex PDD, Mail.ru для бизнеса.

  2. Хостинг

  3. Собственный почтовый сервер

SPF для популярных сервисов.

На момент написания статьи они выглядят следующим образом.

Google App:

“v=spf1 include:_spf.google.com ~all”

Yandex PDD:

“v=spf1 redirect=_spf.yandex.ru”

Mail.ru:

“v=spf1 redirect=_spf.mail.ru”

Как подобрать SPF для собственного почтового сервера или хостинга.

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

Самый верный вариант, это просмотреть исходное сообщение полученного письма и найти там информацию о сервере отправителя.

Например:

Received: from gateway08.websitewelcome.com (gateway08.websitewelcome.com. [67.18.36.18])

Из этого сообщения мы можем понять имя сервера “gateway08.websitewelcome.com” и ip адрес 67.18.36.18. IP адрес лучше не использовать, т.к. он может изменяться очень часто. Домен 3-го уровня в этом случае то же лучше не использовать, т.к. из его названия понятно что он не один, и следующее письмо может быть отправлено уже с другого домена. Лучше просто взять “websitewelcome.com”.

Далее проверяем, есть ли у websitewelcome.com SPF запись. В этом нам может помочь утилита dig.

$ dig TXT websitewelcome.com

В ответе найдём:

websitewelcome.com. 19117 IN TXT "v=spf1 a mx ip4:64.5.0.0/16 ip4:67.18.0.0/16 ip4:69.41.0.0/16 ip4:69.56.0.0/16 ip4:69.93.0.0/16 ip4:70.85.0.0/16 ip4:74.52.0.0/16 ip4:174.132.0.0/16 ip4:174.120.0.0/16 ip4:173.192.100.229 ip4:173.192.111.0/24 include:spf.websitewelcome.com"

Данная запись выглядит вполне жизнеспособной, можем просто забрать её:

“v=spf1 redirect=websitewelcome.com”

Заключение

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

www.freedev.world


You May Also Like

About the Author: admind

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.