Как сделать запись dmarc

Как попасть в Inbox: всё о DMARC

Рассказываем о протоколе DMARC (Domain-based Message Authentication Reporting and Conformance) — зачем он нужен, как настраивать, какие есть особенности в использовании и как читать отчёты. Это третья статья цикла о доставляемости, и в ней мы используем понятия предыдущих публикаций, поэтому перед чтением рекомендуем вспомнить про SPF и DKIM.

Что такое DMARC и зачем он нужен?

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

На примере ниже — скриншот фишингового письма, маскирующегося под рассылку от Сбербанка. Оно оформлено полностью корректно и использует почту отправителя fomin.s@sberbank.ru — что похоже на реальный корпоративный адрес сотрудника Сбербанка. В действительности при клике по ссылке юзера уводит на сайт, где скачивается zip-архив с вирусом.

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

Уберечься от такой рассылки Сбербанк мог, настроив политику reject для DMARC, — тогда почтовый провайдер отклонит фишинговое письмо ещё на этапе анализа на спам и письмо просто не попадёт в ящики пользователей.

Как это работает?

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

По результатам проверки обновляется информация в отчётах:

DMARC позволяет отправителю указать, как поступать с письмом по результатам проверки. Это делается через указание политики DMARC, которая бывает трёх видов:

Если совсем кратко — то при использовании DMARC получатель может быть уверен, что письмо действительно отправлено именно с того емейла, который указан в поле From-email.

Синтаксис записи

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

На основе этих параметров мы получаем минимально рабочую запись:

Следующий блок параметров имеет значения по умолчанию, которые используются, если параметр явно не указан в записи DMARC:

Как итог, у вас может получиться следующая запись, если использовать все доступные параметры:

Как читать агрегированные отчёты?

Агрегированные отчёты дают информацию о том, какие емейлы прошли проверки по SPF, DKIM и DMARC, а какие нет. В этих отчётах нет информации о каждом конкретном письме, но есть возможность оценить весь поток писем, идущий от имени вашего домена. Каждый почтовый провайдер, который поддерживает DMARC, генерирует и отправляет свой собственный отчёт.

Отчёты отправляются на емейл, указанный вами в параметре rua=mailto:email@domain.com.

Сам отчёт состоит из нескольких стандартных блоков.

Источник

Полный синтаксис DKIM, DMARC и SPF

Не так давно прописывала записи DKIM, DMARC и SPF для своего домена. Это оказалось сложнее, чем я думала, потому что мне не удалось нигде найти полный синтаксис всех этих записей. Тогда вместе с Яной Лыновой мы собрали материал. Фактически, эта статья дополняет несколько статей с Хабра (внизу вы найдете ссылки).

Для того, чтобы прописать необходимые записи, нам нужен доступ к DNS. DNS расшифровывается как Domain Name System. Обычно доступ к DNS в компании имеют системные администраторы или, на крайний случай, программисты. Для них вы должны написать ТЗ, по которому они смогут добавить записи в DNS.

Итак, что же такое DKIM?

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

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

Записей DKIM может быть несколько — например, если вы пользуетесь одновременно сервисом Mandrill и при этом отправляете письма через Gmail, у вас будет 2 записи DKIM с разными селекторами:

Синтаксис 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=*» (все сервисы). По умолчанию «*»;
«;» — разделитель.

Помимо этого можно создать необязательную запись, которая подскажет, что делать с неподписанными письмами:

где «all» — отправка неподписанных сообщений запрещена; «discardable» — все неподписанные сообщения должны быть заблокированы на стороне получателя; «unknown» — отправка неподписанных сообщений разрешена (значение по умолчанию).

Обратите внимание, что некоторые хостинги не поддерживают доменные записи длиннее 255, а то и 200 символов. В таком случае нужно разбить строку переводом. Но у некоторых хостингов и это не работает, обратитесь в поддержку вашего хостинга, чтобы узнать это заранее.

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

Проверить DKIM можно здесь.

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

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

Синтаксис SPF

» — «мягкое» отклонение (письмо будет принято, но будет помечено как спам);
«?» — нейтральное отношение;
«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, как я упоминала ранее):

Проверить SPF можно здесь.

DMARC

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

Пример записи DMARC (не имеет значения, какими сервисами для рассылки вы пользуетесь):

Синтаксис 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 через запятую без пробелов.
«ruf» — отчеты для писем, не прошедших проверку DMARC.
Тег «fo» служит для генерации отчетов, если один из механизмов сломается. «fo=0» (используется по умолчанию) — присылать отчет, если не пройден ни один этап аутентификации; «fo=1» — присылать отчет, если не пройден хотя бы один этап аутентификации; «fo=d» — присылать отчет, если не пройдена аутентификация DKIM; «fo=s» — присылать отчет, если не пройдена аутентификация SPF.

Запись DMARC может быть одна для домена и поддоменов, т.к. в ней можно явно указать действия для тега «sp». Если вам требуется специфическая запись для поддоменов, можно создать отдельную запись с наименованием «_dmarc.ваш_поддомен.ваш_домен.».

Проверить DMARC можно здесь.

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

Источник

Внедрение DMARC для защиты корпоративного домена от спуфинга

A Thief on the Run by Manweri

Привет, Хабр! В этом посте мы снова поговорим о проблеме подделки отправителя (или так называемом спуфинге). В последнее время такие случаи очень участились: подделывается все: письма со счетами за ЖКХ, из налоговой инспекции, банков и так далее. Решить эту проблему помогает настройка строгой DMARC-политики. Мы как почтовая служба проверяем все приходящие к нам письма на DMARC начиная с февраля 2013 года. Мы были первым в рунете почтовым сервисом, поддержавшим стандарты DMARC. Однако чтобы минимизировать число поддельных писем, этого, к сожалению, недостаточно. Главное, чтобы строгий DMARC был поддержан на стороне отправителя. Вот почему мы не устаем качать эту тему, ведем активную разъяснительную работу и всячески призываем всех включать у себя строгий DMARC.

Позитивные сдвиги уже есть: с каждым месяцем мы видим прирост числа корпоративных отправителей, прописавших DMARC, на десятки процентов. Однако безусловно, еще есть над чем работать. Практика показывает, что IT-культура находится на очень разном уровне. Кто-то слышал краем уха про DMARC, но пока не собирается его внедрять. Есть и такие, для кого факт, что в транспортных протоколах электронной почты отсутствует какая-либо проверка и защита адреса отправителя, до сих пор является настоящим откровением. Кроме того, поддержка DMARC — задача непростая. Только на первый взгляд кажется, что достаточно опубликовать запись в DNS, и не требуется никакого дополнительного софта или технических средств (подробнее в нашей статье DMARC: защитите вашу рассылку от подделок). На практике в крупной компании с многочисленными потоками электронной почты и развесистой структурой почтовых доменов все гораздо сложнее. И есть моменты, которые следует предусмотреть и продумать заранее. Именно для таких сложных случаев мы написали эту статью, постаравшись собрать в ней все нюансы.

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

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

Основной проблемой является то, что DMARC требует авторизации всех легитимных писем. А для этого необходимо не просто внедрить методы авторизации (в качестве базовых протоколов используются SPF и DKIM), но и добиться того, чтобы для всех без исключения легитимных писем с обратными адресами домена проходила авторизация. Поэтому внедрение DMARC стоит начинать с нижеследующего пункта.

1. Проведите ревизию легитимных писем от вашего домена и его поддоменов

Типичные упущения в этом процессе:

2. Внедрите SPF для основного домена и его поддоменов

Можно дать следующие рекомендации по внедрению SPF:

3. Опубликуйте DMARC-запись с политикой none для основного домена и поддоменов

Пример такой записи:

Типичные проблемы и рекомендации:

4. Внедрите DKIM

5. Начните переключение на строгую политику

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

Можно начать с включения политики reject на 10% ( p=reject; pct=10 ), чтобы отследить потенциальные проблемы по ошибкам доставки. Но долго держать такую политику не рекомендуется: на оставшиеся 90 % срабатываний будет применяться политика quarantine, и можно пропустить единичные проблемы.

Обязательно следите за журналами сервера и отчетами о невозможности доставки писем на предмет ошибок, связанных с DMARC. Стандарт рекомендует получателям, внедряющим серверную часть DMARC, обязательно указывать его как причину в сообщении об ошибке, поэтому для идентификации проблемы можно использовать «DMARC» как ключевое слово в сообщении об ошибке. По журналам сервера вы увидите проблему гораздо раньше, чем по отчетам и будете точно знать на какие адреса какие письма не были доставлены.

Можно внедрять политику, отличную от политики основного домена, на отдельные поддомены, публикуя для них отдельные политики или указав в политике основного домена ( p=none; sp=reject ): политика sp будет действовать на поддомены, которые не публикуют собственную политику.

Когда все поддомены будут переведены на строгую политику, можно убрать политики поддоменов — или же оставить, на ваше усмотрение. Влияет это только на генерацию репортов в соответствии со сложившейся практикой (в стандарте данный момент не обговорен). Если поддомен публикует свою политику, на нее станут приходить отдельные репорты; если отдельной политики нет, то отчеты по поддомену будут включаться в отчет родительского домена.

6. Тюнинг политики DMARC

Ниже приведен разбор некоторых необязательных полей DMARC-записи, примеры и рекомендации по их использованию.

p ( p=reject ) — политика DMARC. Указывает получателю, как поступать с письмами, не проходящими аутентификацию. Может принимать значения none (доставлять письма получателю), quarantine (доставлять письма в папку «Спам») и reject (не принимать письма).

rua ( rua=mailto:ruamailbox@example.com ) — адрес, на который получатели будут отправлять аггрегированный (статистический) отчет. Адрес должен принадлежать тому же организационному домену. Мы рекомендуем обязательно публиковать адрес для аггрегированных отчетов и следить за ними как минимум на этапе внедрения политики DMARC.

ruf ( ruf=mailto:rufmailbox@example.com ) — адрес, на который будут отправляться forensic-отчеты (т. е. исследовательские) по отдельным письмам. По умолчанию forensic-репорты отправляются только по нарушениям DMARC. Можно использовать опцию fo для регулирования поведения. В настоящее время относительно небольшое количество получателей отправляет forensic-отчеты.

fo ( fo=1 ) — по каким нарушениям отправлять уведомления. fo=0 (поведение по умолчанию) отправляет отчеты, только когда не прошли обе аутентификации: SPF и DKIM. fo=1 — когда не проходит любая из аутентификация, даже если проходит альтернативный метод. fo=s шлет forensic-репорты на проблемы с SPF-аутентификаций. fo=d — на проблемы DKIM.

adkim ( adkim=r ) — режим проверки соответствия DKIM-домена. По умолчанию используется режим r (relaxed) и должен совпадать только организационный домен. В строгом ( s ) режиме требуется полное совпадение домена из адреса отправителя с доменом из DKIM-сигнатуры. Имеет смысл использовать строгое соответствие домена, если часть ваших поддоменов делегирована недоверенным сторонам.

aspf ( aspf=r ) — аналогично для домена из envelope-from, для которого проверяется SPF и From. При aspf=s эти домены должны полностью совпадать для прохождения аутентификации SPF.

Источник

SPF, DKIM, DMARC: что всё это значит для email-рассылки, как настроить и проверить работу

SPF, DKIM и DMARC — это базовые настройки, которые обязательно нужно сделать перед запуском email-маркетинга, вне зависимости от того, какой сервис рассылок вы выбрали. Без них письмо не будет доставлено до почтового ящика клиента или попадёт в папку «Спам».

Записи SPF и DKIM это предотвращают. Они не дают мошенникам рассылать вредоносные письма от вашего имени, и говорят почтовым провайдерам, таким как Mail.ru, что рассылки приходят именно от вас. DMARC — это дополнительная броня к защите.

Что всё это значит

SPF и DKIM — это DNS-записи, без которых письмо, скорее всего, не будет доставлено или попадёт в папку «Спам». Domain Name System (DNS) — это «телефонный справочник» интернета, где номер телефона — это IP-адрес, а имя контакта — домен. Эта информация хранится на DNS-серверах. Чтобы добавить её в систему, нужно настроить SPF и DKIM — без этого работа почты на домене невозможна.

DMARC — это алгоритм действий с вашими рассылками, если письма признаны подозрительными. Все эти элементы защиты создаются как TXT — тип записи DNS, который позволяет связать текстовую информацию с доменом.

SPF подтверждает, что домен не подделка

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

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

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

1. Определите, с каких серверов вы будете рассылать письма.

2. Зайдите в панель управления вашего DNS-хостинга.

3. Создайте TXT-запись, заполнив поля (в разных панелях их названия могут различаться). Покажем на примере записи для рассылок через retailCRM.

Некоторые панели управления вместо символа @ требуют указать ваш домен (например, retailcrm.ru). Если не получается указать ни то, ни другое, оставьте эту строку пустой. Иногда этого поля может не быть совсем, значит, что ничего указывать не требуется.

4. Подождите, пока изменения вступят в силу. DNS-серверам необходимо время, чтобы обменяться сведениями о новых DNS-записях. На это может уйти до 72 часов.

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

Чтобы убедиться, правильно ли вы всё настроили, воспользуйтесь сервисами для проверки SPF или просмотра DNS-записей:

DKIM улучшает репутацию отправителя

DKIM (DomainKeys Identified Mail) — цифровая подпись ваших писем. Настроенная DKIM-подпись повышает уровень доверия к отправителю со стороны провайдера.

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

Публичный ключ размещается в DNS‑записи в TXT-поле. С его помощью получающий сервер расшифровывает подпись и проверяет, что спрятанная в ней информация соответствует содержимому письма. Если есть какие-то нестыковки, то письмо попадает в папку «Спам».

Источник