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

Записи SPF помогают предотвратить спуфинг – рассылку спамерами нежелательных писем из вашего домена. Для этого используется технология Sender Policy Framework (SPF).

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

Использование SPF с DKIM и DMARC

Помимо SPF, рекомендуем использовать проверки DomainKeys Identified Mail (DKIM) и Domain-based Message Authentication, Reporting & Conformance (DMARC). SPF определяет круг доменов, из которых вам могут поступать письма. DKIM позволяет удостовериться, что контент сообщения не менялся после отправки. А DMARC указывает, что делать с подозрительными сообщениями, поступившими в ваш домен.

Как создать запись SPF для домена

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

Чтобы настроить записи SPF в Gmail, добавьте запись TXT в систему своего регистратора. Это не отразится на работе электронной почты.

Если вам требуется помощь, обратитесь к своему регистратору.

1. Войдите в аккаунт своего домена на сайте регистратора (не в консоли администратора Google).

   Подробнее о том, как определить регистратора домена…

2. Откройте страницу, где можно обновить записи DNS. Эта страница может называться DNS management (Управление DNS), Name server management (Управление серверами доменных имен) или Advanced settings (Расширенные настройки).
3. Найдите записи TXT и проверьте, нет ли среди них записи SPF, начинающейся с v=spf1.

   Если вы нашли запись SPF, переходите к шагу 4, а если нет – к шагу 5.

4. Удалите запись SPF.

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

5. Создайте запись TXT с указанными ниже значениями.
   • В поле Name/Host/Alias (Имя/хост/псевдоним) введите @ или оставьте его пустым (правильный вариант может быть указан в других записях DNS).
   • В поле Time to Live (TTL) (Время жизни) введите 3600 или оставьте значение по умолчанию.
   • В поле Value/Answer/Destination (Значение/ответ/назначение) введите v=spf1 include:_spf.google.com ~all
6. Сохраните изменения.

Новая запись SPF начнет действовать в течение 48 часов.

Как проверить запись SPF

Запись SPF можно проверить с помощью Набора инструментов G Suite.

1. Перейдите по адресу https://toolbox.googleapps.com/apps/checkmx/.
2. Введите доменное имя.
3. Нажмите Начать проверку.
4. После ее окончания нажмите Диапазоны действующих адресов SPF.
5. Проверьте результаты. Они должны содержать следующие строки:
   • _spf.google.com
   • _netblocks.google.com и несколько IP-адресов
   • _netblocks2.google.com и несколько IP-адресов
   • _netblocks3.google.com и несколько IP-адресов

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

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

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

Чтобы добавить почтовый сервер в существующую запись SPF, введите перед аргументом ~all IP-адрес этого сервера в формате ip4:адрес или ip6:адрес, как показано в примере ниже.

v=spf1 ip4:172.16.254.1 include:_spf.google.com ~all

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

v=spf1 include:serverdomain.com include:_spf.google.com ~all

Статьи по теме

Дополнительная информация о создании записей SPF приведена в справочных статьях:

• Диапазоны IP-адресов Google для исходящих SMTP-сообщений
• Формат записей SPF на сайте Sender Policy Framework

support.google.com

SPF (Sender Policy Framework) — расширение для протокола отправки электронной почты через SMTP. Содержит список адресов серверов, через которые вы отправляете рассылки с ящиков на вашем домене.

Простыми словами, SPF-запись защищает от подделки письма, отправленные от имени вашего домена и позволяет предотвратить попадание писем, отправленных с ваших адресов, в спам.

SPF запись содержит перечень IP адресов, с которых вы производите свои рассылки. Если вы делаете их на сервисе рассылок, к примеру Estismail.com, вам необходимо указать IP адреса серверов данного сервиса.

Чтобы настроить SPF-запись:

1. Перейдите на сайт провайдера, у которого находится DNS-зона управления вашим доменом;
2. Введите логин и пароль для входа в «Панель управления»;
3. Перейдите в раздел управления DNS-зонами необходимого домена;
4. Добавьте новую ТХТ-запись со следующим значением: v=spf1 include:estismail.com ~all

Некоторое пояснение:

Так как у нашего домена так же настроена SPF запись и там уже перечислены все IP адреса, вам нет необходимости их перечислять у себя. К тому же, так как объемы рассылок у нас большие, то мы часто добавляем новые сервера.

Поэтому, вы прописываете в SPF записи именно include:estismail.com, что обозначает, что ваш домен поддерживает все IP адреса, которые настроены на данный домен.

Как проверить, прописалась ли запись?

Мы постоянно сканируем домены наших пользователей и выводи информацию в ваш аккаунт. Если вы правильно прописали SPF запись на вашем домене, то в разделе «Настройки отправителя» во вкладке «SPF» вы увидите статус «Активный».

Может ли быть две SPF записи?

SPF запись должна быть только одна. Если у вас, к примеру, v=spf1 include:estismail.com ~all и v=spf1 redirect=_spf.mail.ru, необходимо удалить их и добавить новую запись: v=spf1 include:estismail.com redirect=_spf.mail.ru ~all

Чтобы проверить корректность записи, обратитесь в техподдержку или используйте специализированные сервисы.

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

Добавление новой TXT записи и настройка SPF — процедура очень распространенная и для данных специалистов не будет являться сложной задачей.

www.estismail.com

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

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

В последнее время все больше и больше получателей стали жаловаться, что отправляемые нами письма у них попадают в СПАМ. При этом у пользователей MAIL.RU попадание в СПАМ было 100% вне зависимости от содержимого письма.

Официальное обращение в MAIL.RU

Я написал письмо в поддержку MAIL.RU. В ответе мне сообщили, что причиной блокировки писем является массовый спам, который отправляется от имени моего домена.

Из рекомендаций полученных от MAIL.RU мне стало ясно, чтобы письма отсылаемые нашим сервером не попадали в СПАМ у получателей мне необходимо настроить SPF, DKIM и DMARC.

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

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

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

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

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

где:

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

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

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

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

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

Таким образом, для настройки DKIM нужно сделать следующее:

• Сгенерировать пару ключей;
• Добавить открытый (публичный) ключ в TXT запись вашего домена;
• Добавить закрытый (частный) ключ на почтовый сервер Hmailserver.

Генерация пары ключей

Самый простой способ сгенерировать пару необходимых нам ключей для DKIM — это воспользоваться сервисом https://port25.com/dkim-wizard/

Поле DomainKey Selector позволяет привязать к одному домену несколько DKIM записей для разных нужд, например если у вас несколько почтовых серверов. У меня только один почтовый сервер и в роли селектора я выбрал просто «mail». Нажмите кнопку [CREATE KEYS] и вы получите пару ключей.

Настройка DKIM в Hmailserver

Приватный ключ необходимо сохранить на Windows сервер где установлен Hmailserver. Для имени файла ключа я использовал значение mail.domainname.tld.pem, а сам файл сохранил на сервере в папку C:pmta.

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

Не забывайте указать Selector, который вы назначили при генерации ключа.

Настройка DKIM подписи домена

Добавьте подобную TXT запись для вашего домена:

где:

• domainname.tld — имя вашего домена;
• mail в имени хоста — селектор выбранный при генерации ключей и указанный в настройках Hmailserver;
• p=MIIBIjANBg — открытый ключ.

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

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

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

где:

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

Проверка работы почтового сервера

После внесения указанных изменений я оправил тестовое письмо:

Как видите все три настройки произведены правильно.

moonback.ru

Проверка по спам-листам

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

Проверить наличие ip-адреса в блэк-листах можно тут: https://www.dnsbl.info/dnsbl-database-check.php

Проверить на бан от Роскомнадзора можно тут: https://blocklist.rkn.gov.ru/

Проверка основных DNS-записей

Если у вашего почтового сервера не настроены или настроены некорректно MX, A и PTR записи для IP-адреса вашего почтового сервера, то ваше письмо со 99% вероятности попадет в спам или вообще будет отклонено получающим сервером. Почтовые сервера Янедекса и Mail.ru последнее всремя вообще взяли за правило делать вид, что они письмо приняли, но внутренние фильтры его просто удаляют и вам кажется, что почта ушла и была принята принимающим сервером, но на деле ее никто не получит.

Начинаем с проверки MX-записей для домена:

# dig MX gita-dev.ru | grep -v ";" | grep -v "^$" gita-dev.ru.           3582   IN     MX     10 mail.gita-dev.ru. 

Проверяем A-запись для соответствующей MX-записи:

# dig A mail.gita-dev.ru | grep -v ";" | grep -v "^$" mail.gita-dev.ru.      3599   IN     A      93.170.131.222 

И в обратную сторону, проверяем PTR запись для IP-адреса и она должна указывать на DNS-имя сервера:

# nslookup 93.170.131.222  Server:        8.8.8.8 Address:       8.8.8.8#53  Non-authoritative answer: 222.131.170.93.in-addr.arpa    name = mail.gita-dev.ru. 

Настройка DKIM

После того как мы проверили базовые вещи, мы можем переходить к повышению уровня доверия к нашему почтовом у серверу и для этого нам потребуется настроить DKIM. По настройке DKIM есть есть много инструкций и я не буду вдаваться в подробности и скажу лишь, то что этот механизм подразумевает добавление к письму дополнительного заголовка содержащего цифровую подпись которая проверяется по ключу указанному в соответствующей TXT-записи домена. На самом деле, ничего сложного нет, просто следуем представленной ниже инструкции (настройка DKIM для Postfix). Настройку, я как обычно показываю на своем тестовом домене gita-dev.ru и думаю, что вы можете просто изменить этот домен на свой не вдаваясь в особые детали реализации, иначе пошаговое объяснение займет уйму времени.

Устанавливаем необходимые для работы пакеты:

# apt-get install opendkim opendkim-tools 

Генерируем ключ для подписи электронной почты и соответствующую DNS-запись:

# mkdir /etc/opendkim/ # opendkim-genkey --bits=1024 -D /etc/opendkim/ -d gita-dev.ru -s mail 

Файл конфигурации /etc/opendkim.conf:

Canonicalization relaxed/simple SyslogSuccess yes Syslog yes LogWhy yes Mode sv RequireSafeKeys false KeyTable file:/etc/opendkim/keytable SigningTable refile:/etc/opendkim/signingtable X-Header yes 

Файлы отвечающие за подпись писем (для каждого домена подпись естественно отдельная).

Файл /etc/opendkim/keytable:

gita-dev.ru gita-dev.ru:mail:/etc/opendkim/mail.private 

Файл /etc/opendkim/signingtable:

*@gita-dev.ru gita-dev.ru 

Настраиваем OpenDKIM на работу с IP-портом по TCP протоколу (можно оставить и на сокете, но честно говоря с правами доступа лишняя морока) и для этого в файле /etc/default/opendkim меняем параметр:

SOCKET="inet:12345@localhost" 

Настраиваем автозапуск DKIM при старте сервера и запускаем сервис:

# systemctl enable opendkim # systemctl start opendkim 

В файле /etc/opendkim/mail.txt находится DNS-запись в формате Bind которую необходимо добавить в панели управления DNS-сервером и в моей панели управления сервером это выглядит следующим образом.

Проверяем, что созданная DNS-запись доступна:

# dig TXT mail._domainkey.gita-dev.ru | grep -v "^;" | grep -v "^$" mail._domainkey.gita-dev.ru. 3599 IN   TXT    "v=DKIM1; k=rsa; p=MIGfMA0GC.....829KFZe1xFqwIDAQAB" 

Проверяем, что закрытый ключ соответствует секретному:

# opendkim-testkey -d gita-dev.ru -s mail -vvv opendkim-testkey: using default configfile /etc/opendkim.conf opendkim-testkey: checking key 'mail._domainkey.gita-dev.ru' opendkim-testkey: key not secure opendkim-testkey: key OK 

И если все правильно, то переходим к настройке Postfix в конфигурацию которого необходимо добавить параметры:

milter_default_action = accept milter_protocol = 6 smtpd_milters = inet:[127.0.0.1]:12345 non_smtpd_milters = inet:[127.0.0.1]:12345 

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

# chown -R opendkim:opendkim /etc/opendkim/ 

Перезапускаем почтовый сервер и отправляем письмо самому себе:

# /etc/init.d/postfix restart 

В теле письма должна появиться DKIM-подпись.

Настройка SPF

SPF — это еще одна TXT запись определяющая каким почтовым серверам стоит доверять, есть много статей посвященным тонкостям настройки SPF у разного рода монстроидальных конструкций, они легко гугляться, но для простых реализаций достаточно вот такой записи:

gita-dev.ru. IN TXT v=spf1 a mx ~all  

Настройка DMARK

В случае в DMARK, все аналогично SPF и вы можете использовать DNS-запись аналогичную представленной ниже:

_DMARC.gita-dev.ru IN TXT v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1 

Или использовать online-конструктор DMARK (или прочитать официальную RFC для особо тяжелых случаев).

Проверка настроек

Неплохой сервис которым можно проверить, что мы все сделали верно находится по адресу: https://www.mail-tester.com/, он правда ограничен по числу запросов в сутки, поэтому перед проверкой убедитесь, что в вашем письме имеется DKIM-подпись, убедиться можно просто визуально открыв письмо в виде исходного текста. Если вы все сделали согласно инструкции, то уровень доверия будет 10 из 10.

gita-dev.ru

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

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

Если ваши письма попадают в спам или не доходят до получателя, укажите в зоне DNS домена (раздел «Управление сайтами» → «Настройка DNS» в Панель управления) три записи: SPF, DKIM и DMARC.

Настройка SPF

SPF (Sender Policy Framework) — TXT-запись с перечнем серверов, которым разрешено отправлять почту с обратным адресом в домене.

SPF состоит из трех частей:

1. Версия,
2. Префикс и механизм,
3. Модификатор.

Версия протокола — spf1.

Префиксы:

• + — принимать сообщение. Этот параметр установлен по умолчанию;
• — — отклонить сообщение;
• ~ — отправить в спам;
• ? — требуется дополнительная проверка.

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

• all — любой сервер;
• ip4 — IP-адрес или подсеть адресов;
• a — определенный домен;
• mx — все серверы, указанные в MX-записях домена;
• include — получить данные с другого адреса.

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

• redirect — проверить SPF-запись указанного домена вместо используемого.

Пример

domain.com. TXT "v=spf1 a mx ip4:141.8.194.175 ~all" Принимать сообщения:

• c основного домена (a);
• домена из MX-записи (mx);
• IP-адреса 141.8.194.175 (ip4:141.8.194.175).

C других серверов (all) — перемещать в папку спам.

Если домен делегирован на наши NS-серверы, SPF настроена по умолчанию.

Настройка DKIM

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

Запись имеет вид: mail._domainkey.domain.com. TXT "k=rsa; t=s; p=..." где:

• mail._domainkey — имя записи типа DKIM;
• k, t, p — параметры ключа.

Включите DKIM-подпись в Панели управления, блок «Электронная почта» раздела «Управление сайтами».

Если почта обслуживается внешним сервисом:

• запросите публичный ключ у провайдера;
• перейдите в раздел «Управление сайтами» → ваш сайт → «Настройка DNS» Панели управления;
• добавьте запись DKIM, указав полученный ключ после «p=».

Настройка DMARC

После настройки SPF и DKIM укажите политику их обработки: добавьте запись DMARC.

Она выглядит так:
_dmarc.domain.com TXT «v=; p=; ...»

Параметры:

Обязательно укажите атрибуты, выделенные цветом.

Примеры

"v=DMARC1; p=quarantine; sp=quarantine; aspf=r;" Все сообщения с ящика в домене или поддомене, не прошедшие проверку записи SPF, помещать в спам.

"v=DMARC1; p=reject; sp=quarantine; ptc=50;" Отклонять 50% сообщений, не прошедших проверку.

help.sprinthost.ru

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

Если вы не знаете, что такое DNS и как вносить TXT-записи – обратитесь к вашему системному администратору. Наши сотрудники также могут настроить вам email-аутентификацию (см. ниже).

Настройка email-аутентификации пользователем

Итак, надо добавить следующие записи:

@ TXT v=spf1 include:spf.unisender.com ~all  us._domainkey TXT k=rsa; p=XXXXXXXXXXXXXXXXXXXXX  

Где XXXXXXXXXXXXXXXXXXXXX — уникальный код, чтобы его получить, перейдите по ссылке и нажмите «добавить». Во всплывающем окне ввести свой домен и нажать «Получить настройки».

Если вы отправляете рассылки на адреса группы mail.ru (inbox.ru, mail.ua, list.ru, bk.ru)

Необходимо настроить постмастер и пересылку fbl, чтобы отметки «это спам» корректно обрабатывались и ваш домен не был блокирован на mail.ru.

Для этого нужно иметь почтовый ящик на Mail.ru (лучше для этой цели завести новый отдельный ящик). Залогинившись в почте, переходите на страницу https://postmaster.mail.ru/add/ и добавляете по инструкции те домены, от имени которых отправляете рассылки. Через сутки Вам будет доступна информация, сколько писем отправлено на домены Mail.ru, сколько блокировано и сколько попало в папку «Спам», а также масса другой полезной информации.

При этом обязательно следует на странице https://postmaster.mail.ru/settings/ для всех доменов указать адрес FBL – на него поступает информация о том, какие адресаты нажали кнопку «Спам» после получения письма. В качестве такого адреса обязательно следует указать fbl@ваш_домен, а с этого адреса настроить форвард (автоматическое перенаправление писем) на адрес [email protected], чтобы письма необходимым образом обрабатывались.

Комментарии:

@ TXT v=spf1 include:spf.unisender.com ~all  

— это запись стандарта SPF. Вкратце, она гласит, что с вашего домена разрешено слать почту только серверам, перечисленным в spf.unisender.com. Но, скорее всего, вы шлёте почту не только через UniSender, но и со своих серверов, и нельзя отключать эту возможность. Чтобы корректно поступить в этом случае, рассмотрим два варианта:

1. Если у вас уже есть запись «@ TXT v=spf1», то добавьте в её конец, но перед последним выражением (перед ~all или -all или аналогичным) строку include:spf.unisender.com.
2. У вас ещё нет TXT-записи для @ с v=spf1. В этом случае вы должны выяснить, какие именно сервера используются для отправки почты с Вашего домена и добавить их наряду со строкой include:spf.unisender.com в соответствии с синтаксисом SPF.

us._domainkey TXT k=rsa; p=XXXXXXXXXXXXXXXXXXXXX  

— эта строка содержит публичный ключ для подписей, используемых по селектору «us».

Рассмотрим пример добавления TXT-записей на домене, который обслуживается Яндекс.

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

1. Первое что необходимо добавить — это spf1 запись —

   @ TXT v=spf1 include:spf.unisender.com ~all

   Согласно инструкции , описанной выше, при условии что у нас уже есть spf1 строка, требуется include:spf.unisender.com добавить в её конец, но перед последним выражением (перед ~all или -all или аналогичным) следующим образом:

   

   Примечание 1: при добавлении нужно учесть что
   @ — это имя записи (хост)
   TXT — тип записи
   include:spf.unisender.com ~all — значение записи.

   Примечание 2 : на Яндексе есть особые правила внесения SPF записей, о которых можно узнать по ссылке

   В итоге получаем :

   

2. Вносим наш DKIM ключ

   us._domainkey TXT k=rsa; p=xxx :

   

В итоге, наши записи должны выглядеть так :

Настройка завершена.

Настройка email-аутентификации службой поддержки UniSender

Если у вас возникли какие-либо проблемы, или просто нет времени и желания разбираться со всеми техническими деталями, описанными выше, вы можете создать обращение в службу поддержки UniSender, и наши специалисты внесут необходимые записи в настройки вашего домена, а также проверят корректность работы SPF/DKIM. Стоимость услуги — 20 у.е за один домен.

www.unisender.com

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

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

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

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

Точно также и в системах электронной почты. Если вам пришло письмо от дедушки [email protected], но сервер отправитель почему-то mail.spam.com, то это повод не принимать такое письмо, так как оно с большой долей вероятности является спамом.

Каким образом мы осуществили данную проверку? Очень просто, посмотрели на штемпель почтового отделения отправителя и сравнили его с обратным адресом. Например на конверте написано, что отправитель находится в городе Москва, однако на штемпеле отделения-отправителя стоит индекс 683000, который указывает на Петропавловск-Камчатский. Следовательно такое письмо мы принимать не будем, так как оно не прошло проверку отправителя.

Аналогично обстоит дело и с электронным письмом, только вместо индекса отделения-отправителя используется PTR-запись. Так получив письмо от дедушки, мы сделаем PTR-запрос и выясним, что сервер отправитель у нас mail.spam.com, в то время как согласно переданной при соединении информации должен быть mail.example.com. Все понятно, письмо падает в спам.

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

Почему так происходит? Потому что проверка по PTR-записи позволяет определить лишь то, что сервер-отправитель действительно тот, за кого себя выдает. Но никоим образом не определяет подлинность самого отправителя. Т.е. обращаясь к примеру обычной почты мы проверяем лишь то, что обратный адрес и индекс отделения отправителя совпадают, если место отправления Москва, а индекс указывает на Петропавловк-Камчатский, то проверку по PTR такое письмо не прошло, а если место отправления и индекс совпадают, то все нормально и теперь уже ваша задача думать, что делает ваш любимый дедушка в Петропавловске-Камчатском.

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

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

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

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

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

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

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

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

Приветствую, Хабр! В этой статье будет инструкция по настройке DKIM/SPF/DMARC записей. А побудило меня написать эту статью полное отсутствие документации на русском языке. Все статьи на эту тему, которые были мной найдены, были крайне не информативны.

1. DKIM

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

Зачем же он нужен?

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

Настройка DKIM подписи и DNS записей

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

openssl genrsa -out private.pem 1024 //генерируем секретный ключ длинной 1024

openssl rsa -pubout -in private.pem -out public.pem //получаем публичный ключ из секретного

Или можно воспользоваться онлайн-сервисом, чего я крайне не советую.

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

Примером записей является
mail._domainkey.your.tld TXT "v=DKIM1; k=rsa; t=s; p=<публичный ключ>"

где
mail — селектор. Можно указать несколько записей с разными селекторами, где в каждой записи будет свой ключ. Применяется тогда, когда задействовано несколько серверов. (на каждый сервер свой ключ)
v — версия DKIM, всегда принимает значение v=DKIM1. (обязательный аргумент)
k — тип ключа, всегда k=rsa. (по крайней мере, на текущий момент)
p — публичный ключ, кодированный в base64. (обязательный аргумент)
t — Флаги:
t=y — режим тестирования. Такие отличают отличаются от неподписанных и нужны лишь для отслеживания результатов.
t=s — означает, что запись будет использована только для домена, к которому относится запись, не рекомендуется, если используются субдомены.
возможные:
h — предпочитаемый hash-алгоритм, может принимать значения h=sha1 и h=sha256
s — Тип сервиса, использующего DKIM. Принимает значения s=email (электронная почта) и s=* (все сервисы) По-умолчанию "*".
; — разделитель.

Так же стоит прописать ADSP запись, которая позволяет понять, обязательно должно быть письмо подписано или нет.
_adsp._domainkey.example.com. TXT "dkim=all"

Значений может быть три:
all — Все письма должны быть подписаны
discardable — Не принимать письма без подписи
unknown — Неизвестно (что, по сути, аналогично отсутствию записи)

2. SPF

SPF (Sender Policy Framework) — расширение для протокола отправки электронной почты через SMTP. SPF определен в RFC 7208 (Wiki). Если простым языком, то SPF — механизм для проверки подлинности сообщением, путем проверки сервера отправителя. Как по мне, данная технология полезна в связке в другими (DKIM и DMARC)

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

Примером обычной SPF записи является your.tld. TXT "v=spf1 a mx ~all"
Здесь:
v=spf1 является версией, всегда spf1
a — разрешает отправляет письма с адреса, который указан в A иили AAAA записи домена отправителя
mx — разрешает отправлять письма c адреса, который указан в mx записи домена
(для a и mx можно указать и другой домен, например, при значении a:example.com, будет разрешена а запись не домена отправителя, а example.com)
Так же можно добавлять и отдельные ip адреса, используя ip4: и ip6:. Например, ip4:1.1.1.1 ip6: 2001:0DB8:AA10:0001:0000:0000:0000:00FB. Еще есть include: (include:spf.example.com), позволяющий дополнительно подключать spf записи другого домена. Это все можно комбинировать через пробел. Если же нужно просто использовать запись с другого домена, не дополняя её, то лучше всего использовать redirect: (redirect:spf.example.com)
-all — означает то, что будет происходить с письмами, которые не соответствуют политике: "-" — отклонять, "+" — пропускать, "~" — дополнительные проверки, "?" — нейтрально.

3.DMARC

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

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

Типичная запись выглядит так: _dmarc.your.tld TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
В ней не предпринимаются никакие действия, кроме подготовки и отправки отчета.

Теперь подробнее о тегах:
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:[email protected], так же можно указать несколько email через пробел (rua=mailto:[email protected] mailto:[email protected])

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

Эпилог

Мы научились настраивать DKIM/SPF/DMARC и противостоять спуфингу. К сожалению, это не гарантирует безопасность в случае взлома сервера или же отправки писем на серверы, не поддерживающие данные технологии. Благо, что популярные сервисы все же их поддерживают (а некоторые и являются инициаторами данных политик).

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

Буду рад конструктивной критике и правкам.

habr.com