Как настроить dkim для exchange

Содержание

Настраиваем SPF, DKIM и DMARC на сервере Exchange
Исходные данные
Необходимые условия
Как настроить SPF
Как настроить DKIM
Настройка политики DMARC
Благодарности
Настройка DKIM в MS Exchange Server 2010/2013/2016
Настройка DKIM в MS Exchange Server 2007/2010/2013
Реализация DKIM для Exchange Server 2013

Настраиваем SPF, DKIM и DMARC на сервере Exchange

Цель данной статьи: настроить бесплатный почтовый сервер так, чтобы письма отправляемые вашим сервером от имени вашего домена не попадали в СПАМ на других серверах, в том числе на MAIL.RU, YANDEX.RU и GMAIL.COM

Исходные данные

Имеется корпоративный домен вида domainname.tld и локальный почтовый серверs. С почтовых адресов домена ведется только деловая переписка, общее количество отправляемых писем не превышает 100 штук в сутки, массовые рассылки отсутствуют как класс.

Необходимые условия

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

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

Напомню, что SPF-запись указывает список серверов, которые имеют право отправлять письма от имени домена.

Чтобы настроить SPF необходимо добавить TXT запись для вашего домена. Для большинства доменов подойдет следующая универсальная запись:

Хост	Тип	Значение
domainname.tld	TXT	v=spf1 +a +mx -all

domainname.tld — имя вашего домена;
v=spf1 — обязательный параметр;
+a — разрешать письма от серверов указанных в A-записи;
+mx — разрешать письма от серверов указанных в MX-записи;
-all — блокировать письма с остальных серверов.

Опубликовав такую запись для своего домена вы даете четкие инструкции всем почтовым серверам в интернете как поступать с письмами с отправителями из вашего домена. Письма отправленные с серверов, IP адреса которых не указаны в записях A и MX, не являются легитимными и могут получателями трактоваться как SPAM письма.

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

Настройка политики DMARC

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

Опубликуйте DMARC-запись с необходимой политикой для домена

Хост	Тип	Значение
_dmarc.domainname.tld	TXT	v=DMARC1;p=reject

domainname.tld — имя вашего домена;
v=DMARC1 — обязательный параметр;
p=reject — политика DMARC.

Благодарности

При написании статьи были использованы следующий источник

Источник

Настройка DKIM в MS Exchange Server 2010/2013/2016

Внимание, для настройки Exchange 2016 CU10 и CU11 требуются некоторые изменения!

В конце статьи дополнение.

Всё началось с того, что мне понадобилось минимизировать количество обычных писем (не рассылок), которые регулярно попадали в папку «Спам» на стороне получателя, где благополучно терялись, оставаясь без ответа. К этому моменту SPF в домене уже был настроен, однако, судя по всему, некоторым почтовым серверам этого было мало. Так появилась вполне конкретная задача: «прикрутить» DKIM к MS Exchange Server 2010.

По умолчанию MS Exchange Server не поддерживает DKIM. В процессе поиска решения был обнаружен бесплатный агент транспорта Exchange DKIM Signer. Ссылка для скачивания последней версии — Здесь

Если у вас установлен .NET Framework 4.5, установку агента можно выполнить в автоматическом режиме. В противном случае придётся установить и настроить Exchange DKIM Signer вручную. Подробная инструкция по установке в ручном режиме есть на сайте агента.

Я решил проверить автоматический режим:

На всякий случай делаем резервную копию сервера Exchange
Скачиваем Configuration.DkimSigner.zip с https://github.com/Pro/dkim-exchange/releases/latest
Распаковываем в произвольную папку и запускаем Configuration.DkimSigner.exe
Нажимаем кнопку Install
В открывшемся окне выбираем, какую версию будем устанавливать
Нажимаем кнопку Install и ждём завершения процесса установки
Закрываем окно

Новый агент транспорта Exchange установлен. Теперь необходимо настроить его параметры. Как и в случае установки, конфигурировать агент можно либо вручную (редактируя файл C:\Program Files\Exchange DkimSigner\settigs.xml), либо через GUI (запустив файл C:\Program Files\Exchange DkimSigner\Configuration.DkimSigner.exe).

Нажимаем кнопку Configure и убеждаемся, что агент Exchange DKIM Signer имеет самый низший приоритет (стоит самым последним в списке). Это нужно для того, чтобы письма подписывались на самом последнем этапе, после всех возможных модификаций, которые сделают остальные агенты транспорта.

На закладке «DKIM Settings» указывается, какие поля будут подписаны. По умолчанию это: From, Subject, To, Date, Message-ID.

Настройка параметров нашего домена выполняется закладке «Domain Settings». Указываем имя домена, селектор (имя DNS записи) и файл с секретным ключом. Ключ можно сгенерировать прямо здесь же.

После того как настройки сделаны, нажимаем кнопку «Save domain». По идее, настройки должны примениться сразу автоматически, но я на всякий случай перезапустил службу «Транспорт Microsoft Exchange».

Осталось настроить две записи в DNS:
_domainkey. . TXT «t=s; o=

;»
mail._domainkey. . TXT «v=DKIM1; k=rsa; t=s; p= »

Параметр o= может принимать значение:

» — некоторые письма из этого домена подписаны

«-» — все письма из этого домена подписаны.

«mail» перед «._domainkey» — это и есть имя селектора.

Так же рекомендуется прописать в DNS запись ADSP:
_adsp._domainkey. . TXT «dkim=all»

Параметр dkim может принимать значение:

«unknown» — аналогично отсутствию записи
«all» — все письма должны быть подписаны
«discardable» — неподписанные письма не должны приниматься.

Отправляем тестовое письмо, например, на gmail и ищем в заголовках dkim=pass:

Строчки есть, всё работает.

Для настройки Exchange 2016 CU10 и CU11 требуются некоторые изменения

Вот что пишет один из авторов форка:

You can test my fork for Ex 2016 CU11 support. Its working on my machine.

You‘ll need to manually add the files for CU11 to your setup of DKIM-Signer, uninstall the old transport-agent and install the new one (using uninstall.ps1 and install.ps1).

See folder «Src/Exchange.DkimSigner/bin/Exchange 2016 CU11» and «Src/Configuration.DkimSigner/bin/Release»

Скачиваем его дистрибутив и следуем инструкции.

Источник

Настройка DKIM в MS Exchange Server 2007/2010/2013

По умолчанию MS Exchange Server не поддерживает DKIM. В процессе поиска решения был обнаружен бесплатный агент транспорта Exchange DKIM Signer.

Я решил проверить автоматический режим:

На всякий случай делаем резервную копию сервера Exchange
Скачиваем Configuration.DkimSigner.zip с https://github.com/Pro/dkim-exchange/releases/latest
Распаковываем в произвольную папку и запускаем Configuration.DkimSigner.exe
Нажимаем кнопку Install
В открывшемся окне выбираем, какую версию будем устанавливать
Нажимаем кнопку Install и ждём завершения процесса установки
Закрываем окно

На закладке «DKIM Settings» указывается, какие поля будут подписаны. По умолчанию это: From, Subject, To, Date, Message-ID.

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

Осталось настроить две записи в DNS:
_domainkey. . TXT «t=s; o=

;»
mail._domainkey. . TXT «v=DKIM1; k=rsa; t=s; p= »

Параметр o= может принимать значение:

» — некоторые письма из этого домена подписаны

«-» — все письма из этого домена подписаны.

«mail» перед «._domainkey» — это и есть имя селектора.

Так же рекомендуется прописать в DNS запись ADSP:
_adsp._domainkey. . TXT «dkim=all»

Параметр dkim может принимать значение:

«unknown» — аналогично отсутствию записи
«all» — все письма должны быть подписаны
«discardable» — неподписанные письма не должны приниматься.

Отправляем тестовое письмо, например, на gmail и ищем в заголовках dkim=pass:

Источник

Реализация DKIM для Exchange Server 2013

При построении современной почтовой системы нужно учитывать множество факторов, чтобы защитить получателей/отправителей почтовой системы от спамовых и фишинговых почтовых сообщений. Все мы хорошо знаем о Sender Policy Framework (SPF), который позволяет проверить не подделан ли домен отправителя почтового сообщения, но изощренность злоумышленников ставит перед нами новые задачи которые можно, а главное нужно решать с помощью стандартов DomainKeys Identified Mail (DKIM) и Domain-based Message Authentication, Reporting and Conformance (DMARC).

Для более глубокого понимая технологий советую просмотреть видео Дмитрия Разборнова DMARC, DKIM .

В этой же заметке мы подробно рассмотрим внедрение в реально работающую почтовую систему технологий DKIM и DMARC на базе почтовой системы Exchange Server 2013.

До недавнего времени в нашей компании использовалась схема исходящей почтовой корреспонденции Exchange Server 2013 –-> почтовый релей Exim 4.x (Linux Debian 7.x x64) –> интернет. На почтовом релее был реализован агент DKIM, который успешно подписывал всю исходящую почту. К сожалению Exchange 2013 не имеет своего встроенного механизма, который может реализовывать подобное.

В свою очередь я пристально слежу за развитием проекта dkim-exchange , который очень бодро развивается и реализует поддержку DKIM в самых последних версиях Exchange.

При установке Exchange DKIM Signer на Exchange сервер устанавливается транспортный агент:

Единственной задачей этого агента является создание электронной цифровой подписи для письма, которое отправлено внешним получателям.

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

Установка агента Exchange DKIM Signer

1) Идем по ссылке и скачиваем файл Source Code (zip)

2) Распаковываем ZIP архив.

3) Открываем от имени администратора Exchange Management Shell и переходим в распакованную папку.

4) Перед тем, как запустить PowerShell скрипт .\install.ps1, зададим политику выполнения PowerShell скриптов:

5) Запускаем скрипт установки .\install.ps1

Setup нам предлагает запустить Configuration.DkimSigner.exe, чтобы сконфигурировать агента, но мы не будем этого делать сейчас, нажимаем Enter.

6) Теперь можно убедиться в том, что агент удачно установился в системе:

Конфигурирование агента Exchange DKIM Signer

1) Идем в папку “C:\Program Files\Exchange DkimSigner\” и запускаем Configuration.DkimSigner.exe и видим:

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

2) Нажимаем кнопку Configure:

Выбираем Exchange DkimSigner и понижаем приоритет до самого низкого. Это значит, что почтовое сообщение будет обрабатываться в последнюю очередь этим агентом, когда у письма будут окончательно сформированы все заголовки почтового сообщения, из документации:

3) Переходим на вкладку DKIM Settings и переключаем алгоритм хеширования на RsaSha256, Body Canonicalization, Header Canonicalization выставляем в Simple, из документации:

Более подробно про параметры Body Canonicalization, Header Canonicalization можно прочитать в спецификации DKIM

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

Не забываем нажать кнопку Save configuration.

4) Переходим на вкладку Domain Settings и удаляем домены по умолчанию example.com и example.org. Следующим шагом добавляем наш почтовый домен кнопкой Add и заполняем основные поля. Поле Domain Name — это имя вашего почтового домена, например для адресов типа UserName@company.com это поле примет значение company.com

Поле Selector – это произвольная строка которая добавляется к имени домена. С помощью поля Selector правильно идентифицируется public key в TXT записи на DNS сервере:

Читайте также: Микроволновка самсунг не работает табло

Если взять наше значение из поля Selector и посмотреть на Email Headers, то мы увидим тег s= который имеет значение из поля Selector, тег d= имеет значение указывающие на наш почтовый домен. Таким образом сервер получатель понимает какой именно public key на нашем DNS сервере нужно проверять.

Следующим шагом генерируем ключевую пару (public key и private key). Private key будет храниться строго на сервере, и с его помощью будет подписываться вся исходящая почта. Нажимаем кнопку Generate Key и Exchange DKIM Signer предлагает нам сохранить *.xml файл в папку keys, что мы и делаем:

В итоге должно получиться три файла в папке keys для нашего почтового домена:

MailDomain.ru.xml

MailDomain.ru.xml.pub – файл содержит public key, в будущем мы разместим его в TXT-записи на нашем внешнем DNS сервере.

MailDomain.ru.xml.pem — файл содержит private key.

После сохранения *.xml файла не забываем нажать на кнопку Save Domain.

Далее Exchange Dkim Signer предлагает нам создать TXT-запись на внешнем DNS сервере который обслуживает наш почтовый домен:

В панели хостинг провайдера вашего DNS сервера создаем TXT запись:

Обратите внимание на то, что запись публичного ключа разделена кавычками (стрелочка под номером два). Когда я впервые настраивал TXT запись на DNS сервере, то столкнулся с проблемой, что электронно-цифровая подпись письма не проходила проверку на принимающем почтовом сервере.

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

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

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

После создания TXT-записи в DNS желательно подождать 5-8 минут и уже потом проверять работоспособность.

Проверка агента Exchange DKIM Signer

Отправим тестовые письма на известные почтовые домены gmail.com и yandex.com:

На скриншоте выше видно, что отработала только SPF запись.

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

Получающий сервер, в данном случае gmail.com, определил, что почтовое сообщение было отправлено через действительный почтовый домен (SPF) и им же подписано (DKIM).

Посмотрим, как yandex.ru определяет, что сообщение имеет достоверную цифровую подпись:

Посмотрим на Email Headers на сервере получения gmail.com:

Посмотрим в логи агента на сервере Exchange:

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

Кстати, более детальную информации по вашему почтовому домену и задействованных на нем технологиях можно получить отправив письмо на адрес mailtest@unlocktheinbox.com

Обновление агента Exchange DKIM Signer

Обновление реализуется очень легко. На скриншоте ниже видно, что я использую не последнюю версию агента. Чтобы это исправить, нужно просто нажать на кнопку Upgrade:

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

Сколько я не тестировал обновление программы, оно завершалось удачей в 100% случаев:

Удаление агента Exchange DKIM Signer

Удаление возможно через PowerShell скрипт .\Uninstall.ps1 который находится там же, где и .\Install.ps1, но в документации написано, что это нерекомендуемый способ удаления.

Простой и рекомендуемый способ удалить агента – это запустить Configuration.DkimSigner.exe из папки «C:\Program Files\Exchange DkimSigner», нажать на кнопку Configure, выбрать агента DkimExchange Signer и нажать кнопку Uninstall:

При успешном удалении вы увидите сообщение:

Итак, на практическом примере мы установили, сконфигурировали, проверили работу, обновили, удалили DKIM Signing Agent for Microsoft Exchange Server.

В одной из следующих заметок постараюсь рассказать о настройке политики DMARC.

Источник