V spf1 mx: Несколько MX-записей и немного про SPF — ITsberg.ru

Не попадаем в СПАМ. Часть 1: проверка SPF.

В настоящее время почтовые сервисы всё больше уделяют внимания системам для борьбы со СПАМом. Но всё чаше сообщения которые ждут от нас наши клиенты попадают в СПАМ. В большинстве случаев это происходит потому что почтовый сервер на который мы отправили почту не может распознать действительно ли почту отправили мы а не кто то посторонний.

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

Для этого нам потребуется:

1. Доступ к редактированию наших DNS записей.

2. Знать адрес сервера с которого отправляются сообщения.

Начнём с конца.

Основы SPF

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

1. Версия

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

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

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

Префиксы:

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

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

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

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

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

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

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

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

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

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

Примеры

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 запись.

Что такое 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 отправляет письмо на адрес [email protected]. В 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.

<< HELO mx.example.com

В зависимости от настроек принимающей стороны, после данного представления уже может быть проверка на соответствие представленного имени правилам SPF, но в данном месте это не обязательно

>> 250 example.net Hello mx.example.com., pleased to meet you

<< MAIL From:<[email protected]>

А вот в этом месте, после выдачи отправителем 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:%{ir}.spf.rambler.ru -exists:%{l}.u.spf.rambler.ru ~all»

тут указаны 2 подсети, из которых разрешено принимать почту, и 2 набора источников, почта с которых будет иметь результат проверки Fail.

Проблема пересылки

Представьте себе следующую схему — пользователь отправляет письмо с адреса [email protected] на [email protected], а там стоит автоматический форвардинг на [email protected]. А у домена xyz.com прописано SPF «v=spf1 +mx -all». В итоге, конечный получатель gmail.com сделает проверку, и получит несовпадение адреса фактического отправителя с указанным, и по правилам SPF не примет письмо. Для решения данной проблемы существует SRS: Sender Rewriting Scheme. В двух словах — происходит переписывание форвардером заголовка return-path.
Вообще, я считаю, что данный момент очень спорный. Использование промежуточного ящика для перенаправления трафика на другой ящик весьма напоминает спам-атаку. Вот, например, я регистрирую ящик, свечу его везде, где только можно, подписываюсь на миллион рассылок, и ставлю редирект на некий ящик, который я хочу завалить спамом. В случае наличия у отправителей SPF и отсутствии SRS на пересылающем почтовике — цель отвергнет эти потоки как спам, а вот при работающем SRS он получит вполне «легитимные» потоки почты.

Заключение

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

Как сделать так, чтобы письма не попадали в СПАМ — Маркетинг на vc.ru

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

P.S. будет много технических терминов, но мы их просто объясним.:)

SPF: что? зачем? и как?

SPF (Sender Policy Framework/структура политики отправителя) — это метод борьбы со спамом, который работает по принципу паспорта. Как главный документ удостоверяет нашу личность, так SPF подтверждает, что емейл пришел с проверенного надежного адреса. Но в отличие от объемной книжечки, Sender Policy Framework представляет собой одну строку в TXT-записи домена. Например, такую:

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

где v=spf1 — это используемая версия SPF, а +a +mx -all — механизм и условия защиты домена от мошенников.

Это самый простой пример записи, который говорит о том, что отправлять письма от имени домена 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 ~all»

и означает, что отправлять сообщения от имени домена example.org. могут все сервера, указанные в mx-записях, а также отправленные с IP 195.3.159.250. Кроме того, можно принимать письма с серверов, указанных в SPF-записи домена gmail.com. Письма со всех остальных серверов нужно отправить в спам без проверки: ~all«.

И это далеко не самая сложная SPF-запись. При необходимости, она может вмещать до 10 параметров. Для удобства, мы собрали их все в одном месте:

+ принимать сообщение. Например: +all — принимать все письма;

— отклонить сообщение. Например: -all — отклонять все письма;

~ принять емейл, но пометить как СПАМ. ~all — отправлять все письма в СПАМ;

? нейтральное отношение;

mx все адреса, указанные в MX-записях домена;

ip4 указывает конкретный IP-адрес. Например: ip4:195.3.156.134 — принимать письма с IP 195.3.156.134;

a указывает действие, которое нужно сделать при получении письма от конкретного домена. Например: +a — принять все письма, которые присланы с IP, который совпадает с IP-адресом в записи отправляющего домена;

include разрешает принимать письма с серверов, разрешенных SPF-записями домена. Например: include:gmail.com — принимать письма с айпишников, которые указаны в SPF домена gmail.com;

all все остальные IP, которые не указаны в SPF-записи;

exists проверяет работоспособность доменного имени;

redirect указывает, что нужно проверять SPF указанного домена, вместо текущего; задает сообщение об ошибке, которое передается отправителю. Например:
exp example.org. IN TXT «v=spf1 +a +mx -all exp=spf.example.org»

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

Главная функция SPF — предотвратить попытки спуфинга и других атак на репутацию отправителя. Ее длина и сложность зависит от нужного уровня защиты и навыков специалиста. Зачастую ее можно прописать самостоятельно, и мы расскажем как — чуть дальше:)

Как SPF защищает домен от спуфинга?

Как известно, основной метод спуфинга — это подмена адреса в поле “FROM”. SPF-запись, как противоядие, направлено именно на это поле, поскольку оно с

SPF записи тонкости при изменение MX записей / likes / блог студии Клондайк!

Тонкости правильной настройки SPF записей на собственном сервере при делегировании 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 у яндекса естественно нет!

Как мы видим из рисунка, отправив почту с яндекса, все действительно работает, почта, приходя к клиенту, отдает 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 на всякий случай.

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

всё, что нужно знать о SPF — Блог EMAILMATRIX

Это первая статья цикла о том, как доставить письма в Inbox. В нём рассказываем о технических тонкостях доставляемости емейл‑рассылок: что и как нужно настраивать, чего бояться и избегать, как вернуть своё честное имя и повысить показатели рассылок.

Первая статья цикла посвящена SPF-записи: что это такое, зачем она нужна и как её настроить.

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

Что такое SPF-запись

Это специальная DNS-запись. Она содержит список IP-адресов, с которых разрешается отправлять емейл‑сообщения от имени отправляющего домена.

Зачем нужна SPF-запись

Настроив SPF-запись и указав в ней все ваши IP‑адреса, почтовые провайдеры (Mail.ru/Yandex/Gmail) понимают, что пришедшее письмо действительно отправлено от имени домена вашей компании.

При этом спамер не сможет использовать ваш домен для фишинга. Ему придётся искать другие варианты.

О синтаксисе

SPF-запись имеет формат TXT. Пример настроенной SPF-записи для домена example.com. В нём указаны IP‑адреса, с которых можно отправлять емейлы от имени домена example.com. Другие IP‑адреса проверку SPF не пройдут.

	v=spf1 ip4:46.243.168.39 ip4:217.66.145.1 ip4:217.66.145.2 ip4:213.87.72.33 ip4:213.87.75.66 ip4:212.248.112.197 ip4:81.176.66.43 ip4:217.74.241.47 ip4:213.87.44.5 ip4:213.87.44.6 ip4:213.87.71.65 mx -all

Также SPF-запись одного домена может включать ссылку на запись другого домена. Для этого в тело записи добавляют модификатор include:. При прочтении SPF-записи отправляющего домена происходит запрос к записи домена, указанного в модификаторе include. IP-адреса этой записи будут учтены при проверке.

Пример SPF-записи домена example.com с модификатором include:

	v=spf1 ip4:176.9.155.239 ip4:192.95.30.151 ip4:94.231.116.76 ip4:94.231.116.77 ip4:94.231.116.78 ip4:94.231.116.69 ip4:78.47.65.243 include:spf-es-ru.com +mx ~all"

C такой записью отправка писем от имени домена example.com разрешена с IP-адресов, описанных выше, плюс IP-адресов, указанных в SPF-записи домена spf-es-ru.com.

Подробнее о синтаксисе SPF читайте в отдельной статье.

Как настроить

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

Далее сформируйте SPF-запись согласно синтаксису протокола.

SPF-запись сформирована. Её необходимо прописать в TXT-записи домена. Фактически вам необходимо добавить новую DNS-запись типа TXT.

Через 6–12 часов значение SPF-записи обновится и станет доступно всем DNS-серверам.

Как проверить настройку

Проверьте правильность настройки с помощью специализированных сервисов для проверки SPF или любого из сервисов для просмотра DNS-записей, например www.dnswatch.info.

Для этого после перехода на сайт введите проверяемый домен и выберите тип записи TXT:

Нажмите на кнопку Resolve — вы увидите список всех TXT-записей. SPF-запись начинается с “v=spf1” и должна содержать все необходимые ip-адреса:

Другие сервисы для проверки:

Как проверить настройку

Наличие SPF-записи является обязательным требованием большинства почтовых провайдеров.

Если запись не будет найдена, то с большой вероятностью рассылка попадёт в папку «Спам». То же самое произойдёт, если SPF-запись существует, но IP-адрес, с которого рассылается письмо, не присутствует в разрешённом списке.

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

О DKIM-записи также есть исчерпывающий материал. В нём написано, что это, для чего она нужна и как её настраивать.

Почта для сайта — что такое MX, SPF, DKIM, DMARC

Что такое MX запись

MX запись (mail exchange) — тип DNS-записи. Она указывает на почтовый сервер, который принимает электронную почту на вашем домене. Без этой DNS записи невозможно работа почты, т.к. почтовый сервер отправителя просто не будет знать на какой сервер ему отправлять письма. Поэтому у каждого хостинга и почтового сервиса будут свои MX записи.

Если вы используете почту для домена на сторонних почтовых сервисах (Яндекс, Гугл или Майл.ру), то для настройки MX-записей воспользуйтесь этой инструкцией.

Что такое SPF запись

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

Что такое DKIM запись

DKIM (DomainKeys Identified Mail) — добавляет специальную цифровую подпись, которая проверяется открытым ключом шифрования, записанном в TXT записи домена. С помощью DKIM-подписи получатель письма может удостовериться в том, что оно действительно пришло от предполагаемого отправителя.

Для работы с DKIM необходимо создать два ключа: приватный и публичный.

• Приватный ключ — ваш личный уникальный ключ, который шифрует скрытую подпись в заголовках каждого вашего письма. Эта подпись не видна получателям писем.
• Публичный ключ — добавляется в DNS-записи домена в формате TXT.

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

Таким образом, если DKIM не настроен, то большинство почтовых серверов будут отклонять такие письма или помечать их как подозрительные и отправлять в спам.

Пример TXT записи публичного ключа:

v=DKIM1; s=email; k=rsa; =MIGIb3DQEfAA4GNADCBiQKBgQDl3JMA0GCSqG…

где v – версия протокола (всегда DKIM1), k – тип ключа (всегда rsa), p – открытый ключ.

Если вы используете почту на хостинге Джихост, то DKIM запись можно включить в Панели управления:

Почта – Почтовые домены – выбрать почтовый домен – Изменить – Включить DKIM для домена.

Что такое DMARC запись

DMARC (Domain-based Message Authentication, Reporting and Conformance) — один из механизмов защиты от фишинга с использованием известного домена в почтовом адресе. Запись устанавливает правила проверки входящей почты. Например, письма будут считаться поддельными, если они не прошли проверку SPF и DKIM. Данный параметр также рекомендуется использовать всегда.

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

Например, помечать письма как спам и отправлять их в карантин или отклонять сообщение без доставки адресату.

Выглядеть DMARC запись может так:

dmarc.ваш_домен.ru. – 3600 – TXT (текстовая запись) – v=DMARC1; p=none; aspf=r; sp=none

Если вы используете наш хостинг, то DMARC запись можно включить в Панели управления:

Почта – Почтовые домены – выбрать почтовый домен – Изменить – Включить DMARC для домена.

Таким образом, правильная настройка MX, SPF, DKIM, DMARC записей является гарантией того, что ваши письма дойдут до получателей и не попадут в спам.

Как настроить SPF, DKIM и DMARC

Введение

Английская версия статьи

SPF и DKIM в целом похожие технологии, и выполняют схожую задачу — подтверждают валидность сервера отправителя. Работают они через записи на DNS сервера. Принцип работы очень простой:

1. Сервер получателя получает письмо с адреса [email protected] , с сервера mta.mindbox.ru

2. Сервер получателя делает запрос к DNS для домена company.com и ищет записи SPF и DKIM

3. В случае если записей нет, письму проставляется статус neutral (конкретно по этим проверкам) и письмо проверяется дополнительными фильтрами.

4. В случае если записи обнаружены, проверяется, разрешено ли серверу mta.mindbox.ru отправлять почту домена company.com

5. Если mta.mindbox.ru не найден в списке разрешенных, то письмо или отбрасывается, или проставляется статус neutral

6. Если mta.mindbox.ru найден в списке разрешенных, письму проставляется статус pass и повышается рейтинг письма при прохождении других фильтров.

Выглядят записи в DNS вот так:

Важно! Домен второго уровня для DKIM проставляется автоматически!

Например, если ключ добавляется для домена company.com , то запись должна быть вида mindbox._domainkey , а если для домена mail.company.com , то запись должна быть mindbox._domainkey.mail

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

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

Эти записи говорят о том, что почту с этого домена могут отправлять основные сервера домена (a mx ptr ) а также все серверы из SPF записи домена mindbox.ru (include:spf.mindbox.ru ) — мы поддерживаем список наших серверов актуальным, и Вам нет необходимости в последствии изменять эти записи. ?all говорит о том, что с других серверов тоже можно отправлять почту с этого домена (просто она получит статус neutral, а не pass).
Если записи у Вас уже есть, нужно просто добавить туда include:spf.mindbox.ru

Если используется Sender ID, в него также нужно добавить include:spf.mindbox.ru

Проверка SPF записей

Обновление днс записей обычно занимает от 30 минут до 4 часов — стоит подождать некоторое время, чтобы записи успели обновиться.
Затем идем сюда и вбиваем доменное имя, для которого Вы прописали записи. Жмем SPF Record Lookup.

Если все правильно, Вы увидите что-то похожее на эту картинку

Если Вы видите пустое окно — значит либо Вы что-то неправильно прописали, либо днс записи еще не обновились.

Вторым шагом проверки является отправка письма с доверенного сервера (который вы внесли в SPF, например, с нашего) на ящик на Gmail. Нужно открыть полученное письмо, в меню выбрать «Показать оригинал»

Там нужно найти строчку Received-SPF: pass — значит все правильно.
Если стоит failed или neutral — значит что-то прописано неправильно, и гугл не доверяет серверу, с которого было отправлено письмо.
Учтите, что mxtoolbox игнорирует наличие переносов в записи.

Для дополнительной проверки используйте сервисы https://2ip.ru/dig/ (выбираем тип TXT) или http://www.mail-tester.com/spf-dkim-check

Настройка DKIM

Настройка DKIM немного сложнее, так как предварительно нужно сгенерировать ключи для подписи сообщений. Для Вас это сделает ваш менеджер.

1. Ваш менеджер отправляет соответствующие записи для добавления в DNS.

2. Полученные записи нужно внести на днс-сервере (аналогично SPF записям).Первая запись говорит о том, что не вся почта домена подписывается. t=y; — указывать не надо, это для тестового режима. Вторая запись содержит публичный ключ.

ВАЖНО: ключ должен быть одной строкой — если есть переносы строк, ключ нужно скопировать в блокнот и убрать их, чтобы получилась одна длинная строка — именно ее нужно вносить в днс.

Проверка DKIM

1. Идем по ссылке http://www.mail-tester.com/spf-dkim-check

2. Вводим доменное имя в соответствующее поле и mindbox в после «Выбор DKIM» (оно же Selector), жмем «Проверить SPF и DKIM записи»

Если все настройки правильные, то мы увидим их на странице:

Также для проверки DKIM можно отправить письмо на Gmail, открыть оригинал

И найти dkim=pass — это значит что все настроено правильно. Если нет, проверьте что есть запись DKIM-Signature: v=1; … — если есть, значит неправильная подпись. Если нет — значит сообщения вообще не подписываются.

Если при попытке отправить письмо на mail.ru получаете ошибку вида dkim=invalid reason=pubkey_syntax, проверьте опубликованную запись DKIM на наличие пробелов.

Настройка DMARC

Настраивать запись DMARC можно только после того, как у вас уже есть корректно настроенные записи SPF и DKIM, так как технология DMARC использует для проверки одну (любую) из описанных выше.

Аналогично предыдущим, запись DMARC – это запись типа TXT. Чтобы создать её, нужно добавить в ДНС:

Имя записи: _dmarc .company.com

Значение (TXT): v=DMARC1; p=none

Проверка DMARC

Для проверки нужно пройти по ссылке https://mxtoolbox.com/dmarc.aspx и ввести в поле поиска почтовый домен клиента.
Если запись настроена, детали должны отобразиться на странице в развёрнутом виде:

Отправив письмо на адрес Gmail, открыть оригинал

И найти в заголовках проверку DMARC:

Was This Article Helpful?

Yes
No

SPF, пожалуйста, объясните мне, что это означает: v = spf1 a mx ~ all

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

6. О компании

.Электронная почта

— Как создать запись SPF для нескольких IP-адресов?

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

6. О компании

Загрузка…

2. Авторизоваться
   зарегистрироваться

3. текущее сообщество
   

.