Для того, чтобы прописать необходимые записи, нам нужен доступ к DNS. DNS расшифровывается как Domain Name System. Обычно доступ к DNS в компании имеют системные администраторы или, на крайний случай, программисты. Для них вы должны написать ТЗ, по которому они смогут добавить записи в DNS.
Итак, что же такое DKIM?
DKIM (Domain Keys Identified Mail) — это цифровая подпись, которая подтверждает подлинность отправителя и гарантирует целостность доставленного письма. Подпись добавляется в служебные заголовки письма и незаметна для пользователя. DKIM хранит 2 ключа шифрования — открытый и закрытый. С помощью закрытого ключа формируются заголовки для всей исходящей почты, а открытый ключ как раз добавляется в DNS записи в виде TXT файла.
Проверка DKIM происходит автоматически на стороне получателя. Если домен в письме не авторизован для отправки сообщений, то письмо может быть помечено подозрительным или помещено в спам, в зависимости от политики получателя.
Записей DKIM может быть несколько — например, если вы пользуетесь одновременно сервисом Mandrill и при этом отправляете письма через Gmail, у вас будет 2 записи DKIM с разными селекторами:
| Название записи | Формат | Содержание |
| для Mandrill (селектор — mandrill): mandrill._domainkey.ваш_домен. (в некоторых панелях управления можно указывать без вашего домена, зависит исключительно от вашего хостинга) |
TXT | v=DKIM1; k=rsa; p=(сгенерированный публичный ключ) |
| для Gmail (селектор — google): google._domainkey.ваш_домен. |
TXT | v=DKIM1; k=rsa; p=(сгенерированный публичный ключ) |
Синтаксис DKIM
Обязательные элементы:
«v» — версия DKIM, всегда принимает значение v=DKIM1;
«k» — тип ключа, всегда k=rsa;
«p» — публичный ключ, кодированный в base64.
Необязательные элементы:
«t=y» — режим тестирования. Нужно только для отслеживания результатов;
«t=s» — означает, что запись будет использована только для домена, к которому относится; не рекомендуется, если используются субдомены;
«h» — предпочитаемый hash-алгоритм, может принимать значения «h=sha1» и «h=sha256»;
«s» — тип сервиса, использующего DKIM. Принимает значения «s=email» (электронная почта) и «s=*» (все сервисы). По умолчанию «*»;
«;» — разделитель.
| Название записи | Формат | Содержание |
| _adsp._domainkey.ваш_домен. | TXT | dkim=all |
где «all» — отправка неподписанных сообщений запрещена; «discardable» — все неподписанные сообщения должны быть заблокированы на стороне получателя; «unknown» — отправка неподписанных сообщений разрешена (значение по умолчанию).
UPD: adsp в 2013 году объявлен устаревшим.
Обратите внимание, что некоторые хостинги не поддерживают доменные записи длиннее 255, а то и 200 символов. В таком случае нужно разбить строку переводом. Но у некоторых хостингов и это не работает, обратитесь в поддержку вашего хостинга, чтобы узнать это заранее.
Некоторые хостинги проставляют кавычки для всех записей самостоятельно, об этом тоже можно спросить у поддержки или проставить по аналогии с другими TXT-записями домена, если они присутствуют.
Проверить DKIM можно здесь.
SPF
SPF (Sender Policy Framework) — это подпись, содержащая информацию о серверах, которые могут отправлять почту с вашего домена. Наличие SPF снижает вероятность попадания вашего письма в спам.
Важно помнить, что SPF запись может быть только одна для одного домена. В рамках одной SPF может быть несколько записей (например, если письма отправляются с нескольких ESP — маловероятно, но все же, чуть позже будет пример). Для поддоменов нужны свои записи.
Пример записи SPF:
| Название записи | Формат | Содержание |
| ваш_домен. (у некоторых хостингов вместо этого может подставляться @ или оставаться пустое поле. При написании названия «ваш_домен.» оно заменится автоматически) |
TXT | v=spf1 +a +mx -all |
Синтаксис SPF
«v=spf1» — версия SPF, обязательный параметр, всегда spf1, никакие другие версии не работают;
«+» — принимать письма (по умолчанию);
«-» — отклонить;
«~» — «мягкое» отклонение (письмо будет принято, но будет помечено как спам);
«?» — нейтральное отношение;
«mx» — включает в себя все адреса серверов, указанные в MXзаписях домена;
«ip4» — позволяет указать конкретный IP-адрес или сеть адресов;
«a» — IP-адрес в A-записи;
«include» — включает в себя хосты, разрешенные SPF-записью указанного домена;
«all» — все остальные сервера, не перечисленные в SPF-записи;
«ptr» — проверяет PTR-запись IP-адреса отправителя (разрешено отправлять всем IP-адресам, PTR-запись которых направлена на указанный домен) (не рекомендуется к использованию согласно RFC 7208);
«exists» — выполняется проверка работоспособности доменного имени;
«redirect» — указывает получателю, что нужно проверять SPF запись указанного домена, вместо текущего домена.
Так как запись должна быть всего одна, через include необходимо прописывать все возможные сервера, через которые вы отправляете письма.
Пример записи SPF, если вы пользуетесь одновременно сервисом Mandrill и при этом отправляете письма через Gmail (несколько записей в рамках одной SPF, как я упоминала ранее):
| Название записи | Формат | Содержание |
| ваш_домен. |
TXT | v=spf1 include:_spf.google.com include:spf.mandrillapp.com -all |
Проверить SPF можно здесь.
DMARC
DMARC (Domain-based Message Authentication, Reporting and Conformance) — это подпись, которая позволяет принимающему серверу решить, что делать с письмом. DMARC использует DKIM и SPF. Если отправленное сообщение не прошло проверку DKIM и SPF, то оно не пройдет и DMARC. Если же сообщение успешно прошло хотя бы одну проверку (DKIM или SPF), то и проверку DMARC сообщение пройдет успешно. DMARC добавляется только после того, как настроены записи SPF и DKIM.
Пример записи DMARC (не имеет значения, какими сервисами для рассылки вы пользуетесь):
| Название записи | Формат | Содержание |
| _dmarc.ваш_домен. |
TXT | v=DMARC1; p=reject; sp=reject; ruf=mailto:postmaster@your.tld; fo=1 |
Синтаксис DMARC
«v» — версия, всегда принимает значение «v=DMARC1» (обязательный параметр);
«p» — правило для домена (обязательный параметр). Может принимать значения «none», «quarantine» и «reject», где «p=none» не делает ничего, кроме подготовки отчетов; «p=quarantine» добавляет письмо в спам; «p=reject» отклоняет письмо.
Тег «sp» отвечает за субдомены и может принимать такие же значения, как и «p».
«aspf» и «adkim» позволяют проверять соответствие записям и могут принимать значения «r» и «s», где «r» — «relaxed» (более мягкая проверка), а «s» — «strict» (строгое соответствие).
«pct» отвечает за кол-во писем, подлежащих фильтрации, указывается в процентах, например, «pct=20» будет фильтровать 20% писем.
«rua» — позволяет отправлять ежедневные отчеты на email, пример: «rua=mailto:postmaster@your.tld», также можно указать несколько email через пробел («rua=mailto:postmaster@your.tld mailto:dmarc@your.tld»).
«ruf» — отчеты для писем, не прошедших проверку DMARC.
Тег «fo» служит для генерации отчетов, если один из механизмов сломается. «fo=0» (используется по умолчанию) — присылать отчет, если не пройден ни один этап аутентификации; «fo=1» — присылать отчет, если не пройден хотя бы один этап аутентификации; «fo=d» — присылать отчет, если не пройдена аутентификация DKIM; «fo=s» — присылать отчет, если не пройдена аутентификация SPF.
Запись DMARC может быть одна для домена и поддоменов, т.к. в ней можно явно указать действия для тега «sp». Если вам требуется специфическая запись для поддоменов, можно создать отдельную запись с наименованием «_dmarc.ваш_поддомен.ваш_домен.».
Проверить DMARC можно здесь.
Надеюсь, что эта статья помогла вам разобраться в синтаксисе записей, и теперь вы с легкостью сможете написать ТЗ для системного администратора или программиста на внесение этих записей в DNS.
Использованные материалы и публикации:
«SPF-запись — проверяем валидность отправителя»
DKIM — это просто
DomainKeys Identified Mail
Настройка DKIM/SPF/DMARC записей или защищаемся от спуфинга
DKIM, SPF И PTR: как настроить почту, чтобы не попасть в спам
Настройка SPF, DKIM, DMARC, FBL
Комментарии (17)
kirillaristov
24.11.2017 21:03Всё это ищется без проблем, материалов тонна, например здесь. По dmarc в статье пример неполный, чтобы полностью отбросить неподписанную почту — v=DMARC1; p=reject; sp=reject; aspf=s; adkim=s.
Более юзабельный сервис для проверки dns — mxtoolbox.com, а ссылки на статьи из «Использованные материалы и публикации» вываливаются гуглом по запросу «dmarc» в самом топе.
При этом нет нюансов использования, например, что многие почтовики игнорируют некоторые поля, в частности google игнорирует тег fo для dmarc (раздел руководства из gsuite о dmarc).
mxms
24.11.2017 21:38К сожалению, вы не разобрались в вопросе. Иначе я не могу объяснить присутствие в статье устаревшего ADSP и других более тонких, но важных, ремарок.
dpyatnisa Автор
25.11.2017 15:44Буду рада, если вы поможете мне улучшить этот материал
mxms
25.11.2017 19:17О том, что ADSP устарел, я уже написал. Его роль выполняет DMARC.
Далее же, чтобы не пересказывать вам опубликованную, в том числе, и на Habrahabr информацию, рекомендую поиском пройтись по статьям по ключевым словам SPF, DKIM и DMARC. Все аспекты (ну почти) их использования неплохо описаны в статьях, к примеру, Mail.ru.
Если говорить о тонкостях, то, к примеру, надо быть готовым к тому, что использование запрещающих политик DMARC может негативно сказаться на пересылаемой почте и листах рассылки.
nikitasius
24.11.2017 23:30dmarc вообще по сути не приелся никому. Так как чтобы получить "dmarc passed", то достаточно добавить запись. Отчетами никто по сути и не занимается. Вот если бы почтовик отправлял отсчет, которые надо было отработать в риалтайме, и следом произвести некие действия, то было бы куда интереснее.
SPF — палка о двух концах, которая выдает ваши пулы на блюдечке с каемочкой. Поэтому, если стоит тема с поднятием пула (за десяти айпи или сразу на /24 блоке), то надо очень аккуратно с ним и с объяслением айпи, которые могут слать от домена. Иначе, как писал, раскрывается весь пул, а операторы
бывают капризныежадные.
На счет DKIM: очень хорошая штука, можно проверить, что письмо было отправлено правильным доменом (from). В то же время, есть и второй dkim — когда вторая подпись от того сервера, который отправил письмо. Например
from: support@example.comс сервераmta-1.example-one.com, первым DKIM будет@example.com, а вторым —example-one.com.
upd: отщепятки
maggg
25.11.2017 12:04Ещё как приелся. Если огрубить, то DMARK это политика, а SPF и DKIM — методы аутентификации. То есть, если вы просто прописали SPF и DKIM, но не прописали DMARK, принимающая сторона такая: ну, окей, это письмо прошло проверку DKIM, а это не прошло. Сама решу, что с ними делать. С DMARK вы сами решаете, что нужно делать.
SyavaSyava
25.11.2017 22:18С DMARK вы сами решаете, что нужно делать
Увы, вы ничего не решаете.
Вы можете рекомендовать, просить, предложить и т.п. принимающей стороне сделать то-то и то-то в таких-то и таких-то случаях, но никак не заставить её это сделать.
Принимающий сервер видит (предположим, что он вообще это видит), что отправитель что-то там просил сделать с почтой в политиках DMARK — но большинству пофиг, ибо для получателя почты от DMARK никакого профита нет, в отличии от например SPF. Спам-то уже прилетел, и отфильтрован — чё ещё нужно?
По этому никто и не заморачивается с отправкой этих всяких отчётов и прочего. Ну разве что кроме крупных контор типа маил.ру, да и тем это нужно, что бы «как у гугля было».maggg
26.11.2017 09:56Это рекомендации, которым будут следовать большинство крупных игроков. Допустим, если я директор атомной станции, то я хочу, чтобы письмо, якобы отправленное с моего адреса, но не прошедшее проверку подлинности, не отфильтровывалось в спам, где его всё равно найдёт наивный журналист, а не принималось получателем совсем. С DMARK я могу это сделать (окей, я могу рекомендовать это сделать).
SyavaSyava
26.11.2017 11:08Это рекомендации, которым будут следовать большинство крупных игроков
Но даже среди крупных — следуют далеко не все. Да, гуголь, как выдумщик всего этого — поддерживает. Но насколько я знаю — из (условно) наших мэйлруша например внедрил поддержку DMARK, а я тот же яндекс — нет.
Допустим, если я директор атомной станции
Согласитесь, что большинство — всё же НЕ директора атомных станций. И вести себя как директор атомной станции в повседневной жизни будет странно, минимум — нерационально.
Что бы уже до конца пояснить мою позицию. Я не считаю DMARK плохой или не нужной технологией. Но она слишком сложная и запутанная для понимания и реализации, плюс не несёт большинству владельцев почты какой-то практической пользы — и результат закономерный. Никто не хочет заморачиваться с ней, потому что это нафиг не нужно.
Сразу касательно следующего комментария, где упоминались сервера, не обращающие внимания на SPF. Это из той же оперы: только принимающий сервер может решить, на что обращать внимание, а на что — нет. Заставить его мы не можем.
Но если в случае с SPF и DKIM для принимающего сервера есть непосредственная польза — можно сразу отбросить весь заведомый мусор (сделает сервер это или нет — его личное дело), то в случае с DMARK — это только лишняя нагрузка на него: считать политики отправителя, что-то куда-то оправлять… Зачем ему это делать?maggg
26.11.2017 14:06Мой пойнт в том, что уменьшение вероятности подделки писем всем полезно, а добавить запись типа такой ничего не стоит:
_dmarc.domain.com TXT "v=DMARC1; p=reject"SyavaSyava
26.11.2017 16:20Ещё раз.
DMARK никак не снижает ни вероятность подделки писем, ни количество спама – вообще никак не влияет на процесс получения писем. Никак. Совсем.
Именно по этому она и бесполезна для большинства почтовиков.
В вашем примере выше вы просите условно говоря отбросить письма, которые принимающий сервер уже определил, как поддельные. Без всякой помощи DMARK в этом, замечу.
Спасибо, кэп – а мы-то и не знали, что делать с такими письмами без этого самого DMARK-а, ночей не спали )))
А вот и SPF, и DKIM – напротив, помогают принимающему серверу отделить полезные письма от мусорных. И они как раз активно внедряются.maggg
26.11.2017 18:16Именно так. Не знали, что делать. Без DMARK сервер может положить письма, проверка SPF и DKIM которых зафейлилась, во входящие, в спам, или может отказаться принимать совсем. Непредсказуемо. С DMARK вы имеете возможность рекомендовать серверу, как поступить, и большaя часть сервисов вас послушает. Отказываться от этой возможности глупо.
maggg
26.11.2017 18:24Просто попробуйте провести массовую рассылку писем, не проходящих аутентификацию SPF и DKIM, с разной политикой DMARC, и вы поймёте, о чём речь.
maggg
26.11.2017 10:07И больше того. Для одного из моих доменов были корректно настроены SPF и DKIM для случая отправки писем почтовым сервером. А ещё мы делали рассылку на несколько тысяч получателей с другого сервера, который не был упомянут в SPF и не подписывал письма по DKIM. Эти письма не отфильтровывались в спам и в половине случаев. То есть любой мог отправить письмо от нашего имени, а принимающая сторона с большой вероятностью сказала бы: «Ой, письмо чё-то не прошло проверки SPF и DKIM, хотя они настроены для домена, ну и ладно».
maggg
25.11.2017 12:07Смешанные чувства. Сам как раз прошёл по всем граблям, написал такую же статью, но не успел опубликовать. Необходимость в систематизирующем материале вооот такая вот была.
erley
Чудесно! Кратко и по делу, спасибо за проделанную работу!
dpyatnisa Автор
Спасибо! :)