Настройка dkim/spf в postfix

Как DMARC защищает от спуфинга

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

DMARC всегда используется в сочетании со следующими двумя методами аутентификации:

• SPF (Sender Policy Framework) позволяет владельцу домена указывать IP-адреса, которым разрешено отправлять электронную почту от имени этого домена. Принимающие сервера могут проверить, было ли письмо с указанным исходным доменом действительно отправлено с сервера, одобренного владельцем домена.
• DKIM (Domain Keys Identified Mail) добавляет цифровую подпись к каждому отправленному электронному письму. Принимающие серверы с помощью подписи проверяют подлинность писем, чтобы убедиться, что они не были подделаны или изменены при доставке.

Аутентификация электронных писем (проверка на соответствие)

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

Подробнее …

Обработка электронных писем, не прошедших аутентификацию (правила получателя)

Если почтовый сервер получает из вашего домена письмо, которое не проходит проверку SPF и/или DKIM, DMARC сообщает серверу, что нужно сделать с этим письмом. В зависимости от правил DMARC возможен один из трех вариантов:

• Правила не заданы. Сервер не предпринимает никаких дополнительных действий и доставляет письма обычным образом.
• Письма отправляются в карантин. Сервер помечает письма как спам и отправляет в папки «Спам» получателей или в карантин.
• Письма отклоняются. Сервер отклоняет письма и не доставляет их получателям.

Подробнее …

Отчеты, позволяющие отслеживать работу DMARC и при необходимости менять правила

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

Отчеты DMARC помогают вам:

• получать сведения обо всех источниках, отправляющих электронные письма вашей организации;
• выявлять неавторизованные источники, отправляющие письма от имени вашей организации;
• определять, какие письма, отправленные вашей организацией, проходят и не проходят аутентификацию (SPF и/или DKIM).

Информация в отчетах DMARC сложна для понимания. Подробнее об использовании отчетов DMARC…

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

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

Обязательные параметры:

• v (version) — версия протокола, должен быть равен DMARC1. Используется для указания, что именно эта TXT-запись определяет политику DMARC. Этот параметр должен идти первым в записи, иначе почтовый провайдер не распознает запись в целом.
• p (Requested Mail Receiver Policy) — политика обработки писем, которую вы указываете для почтового провайдера. Три возможных варианта описаны в статье выше — none/quarantine/reject.

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

v=DMARC1; p=none

Дополнительные параметры:

• rua — определяет адрес для отправки агрегированных отчётов. Указывается в формате rua=mailto:email@domain.com.
• ruf — определяет адрес для отправки отчётов о непройденных проверках аутентификации. Каждая ошибка при проверке аутентификации генерирует отправку письма с отчётом об ошибке, поэтому на этот емейл могут сыпаться десятки, сотни и тысячи писем, если на вас будет совершена фишинговая атака или произойдёт сбой в ваших DNS/системе рассылок и аутентификация писем будет провалена. Формат параметра — rua=mailto:email@domain.com.

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

• adkim (DKIM identifier alignment) — жёсткая (strict) или мягкая (relaxed) проверка по DKIM. При значении параметра strict проваленная проверка ключа DKIM приведёт к провалу всей проверки DMARC в целом. По умолчанию значение relaxed.
• aspf (SPF identifier alignment) — жёсткая (strict) или мягкая (relaxed) проверка SPF. Работает аналогично проверке ADKIM, значение по умолчанию — relaxed.
• rf (Report Format) — формат отчёта о проваленной проверке. По умолчанию принимает значение AFRF (Authentication Failure Reporting Format).
• ri (Reporting Interval) — интервал между отправкой агрегированных отчётов, указывается в секундах. По умолчанию равен 86400 секунд (раз в сутки).
• pct (Percentage) — процент сообщений, к которым будет применяться политика DMARC. Используется для постепенного внедрения или тестирования политики DMARC — можно включить политику только для 10% писем и посмотреть по результатам отчётов, не будут ли отклоняться какие-то нужные письма.
• sp (Subdomain Policy) — политика DMARC, которая будет работать для поддоменов. Можно использовать разные политики для основного домена и поддоменов. По умолчанию остаётся такой же, как и для основного домена.
• fo (Failure reporting options) — определяет, при каких типах непройденных проверок будут отправляться отчёты владельцу домена. Могут быть следующие значения:

• 0 — отправлять отчёт, если не пройдены проверки и SPF, и DKIM. Используется по умолчанию.
• 1 — отправлять отчёт, если не пройдена одна из проверок — или SPF, или DKIM.
• d — отправлять отчёт при каждой проваленной проверке ключа DKIM.
• s — отправлять отчёт при каждой проваленной проверке механизма SPF.

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

v=DMARC1; p=quarantine; rua=mailto:rua.email@domain.com; ruf=mailto:ruf.email@domain.com; fo=1; adkim=s; aspf=s; pct=40; rf=afrf; ri=3600; sp=reject

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

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

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

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

Синтаксис DKIM

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

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

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

Но у некоторых хостингов и это не работает, обратитесь в поддержку вашего хостинга, чтобы узнать это заранее.

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

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, как я упоминала ранее):

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

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

Пример фишингового письма

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

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

Теги записи DMARC

rDNS

Where needs to be configured?

To have a perfect match between the rDNS and the SMTP Banner of the server, need to have the next:

• In the public DNS of the ISP provider. Or if you have control of the public DNS of your IP range, then you can add the rDNS by yourself.
• In the Zimbra Server, need to edit the HELO to match between it and the rDNS record.

How to configure it?

To modify the Public DNS to match the IP and the rDNS, you need to contact with your ISP provider, or if you have acces to edit the DNS record of your IP, then change it by yourself.
For example, if you have the IP 60.60.60.60 and needs to resolve to mail.example.com.

To edit the SMTP Banner and match it with the external rDNS. Need to edit the next in Zimbra:
Zimbra 8.0.X

zmlocalconfig -e postfix_smtpd_banner="mail.example.com"
zmcontrol restart

Zimbra 8.5, 8.6, and above

zmprov ms  `zmhostname` zimbraMtaSmtpdBanner mail.example.com
zmcontrol restart

How to test it

Use the next tool — and fill it with your Public IP, if you have everything well configured, will return the name that you want.

SPF

How to configure it?

• The A entry — mail.domain.com
• The MX entry — srvmta.domain.com
• The IPv4 entry — 60.70.80.90

• include:servers.mcsv.net (Mailchimp)
• include:_spf.salesforce.com (Salesforce)
• include:_spf.google.com (Google Apps)

An example will look like:

Understand the «all» feature in the SPF entry

Difference between ~all and -all

If your domain is under an SPAM attack trying to spoofing your domain, try to change the SPF to -all for a while, and reset to ~all when the attack ends.
Keep selected the -all if you want to be strict with the SPF entry and you are sure that your DNS entry is correct.

How to test it

Have a lot of SPF tools to check if the DNS entry is correct, for example:

• (will show an overview of all the allowed IPS that can send using the domain)
• (Simple but effective, will show the SPF DNs entry and also the result: pass, softfail, fail, neutral, etc.)
• A Classic

Deprecated SPF RR, use TXT RR only

In April 2014, the SPF DNS record was deprecated in the RFC, and the correct way to implement the SPF is using only a TXT DNS record.
For example, this was a valid DNS entries before April 2014, TXT and SPF:

And here the RFC text where you can find the part about use only TXT:

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

SPF и DKIM подпись не гарантируют 100% защиты от мошенников. Даже если все прописано верно, не исключено, что оригинальные перенаправленные мейлы будут хорошо обработаны или идентификация отправителя пройдет без сучка и задоринки. Также нередки случаи, когда отчет о сбоях в доставке отправителю не приходил. В общем, технология не совершенна.

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

Вот как выглядит работа DMARC и весь процесс распознавания отправителя:

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

• Мы не советуем публиковать политику даже с тегом до того, как для основных потоков писем будет внедрен хотя бы один из механизмов аутентификации SPF или DKIM.
• Запись должна начинаться именно с v=DMARC1, и регистр букв имеет значение.
• Некоторые клиенты DNS показывают обратные слеши перед точками с запятой — но в записях DNS-зоны обратный слеш добавлять, как правило, не требуется.
• Адреса rua/ruf должны принадлежать тому же организационному домену, для которого публикуется политика, либо принимающий домен должен опубликовать специальную политику, показывающую согласие на прием репортов. Не получится принимать репорты на адреса, например, публичных почт.
• Если вы еще не закончили внедрение DKIM, то вы будете получать достаточно много нарушений DMARC с IP-адресов публичных почт (Mail.Ru, Gmail, Hotmail/Outlook, Yahoo и т. п.). Это связано с тем, что пользователи данных сервисов часто используют перенаправления в другие ящики, и это приводит к нарушению аутентификации SPF. Устраняется проблема внедрением подписи DKIM.
• Есть неплохие инструменты для визуализации отчетов DMARC. Dmarcian предоставляет платные и бесплатные (для небольших объемов почты) сервисы, и удобный удобный бесплатный инструмент XML-To-Human Converter для просмотра DMARC-отчетов. Agari и proofpoint также предлагают коммерческие сервисы для внедрения и поддержки DMARC.

Как SPF защищает домен от спуфинга и предотвращает попадание подлинных писем в спам

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

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

Чтобы защитить домен организации от спуфинга и других атак через электронную почту, рекомендуем также настроить DKIM и DMARC.

Как SPF помогает с безошибочной доставкой писем

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

В результате сервер может отклонить подлинные письма или поместить их в папку «Спам».

Что делать дальше?

После создания и проверки, дело за малым – разместить DMARC в DNS-записи сайта. К примеру, если строка сгенерирована автоматически, то запись в DNS для адреса dmarc@example.com имеет следующий вид:

DMARC – не панацея от мошенников. Но он заставляет их в поле «FROM» указывать домен, который отличается от оригинального, что облегчает обнаружение спама. Как почтовым провайдерам, так и самим отправителям. Через механизм отчетов бренды могут не только контролировать безопасность своего домена и отслеживать попытки мошенничества с рассылками, но и определять нарушителей.

Мы дали только базовую настройку DMARC, которая поможет поставить «первый уровень» защиты для одного домена и одного IP, с которого делаются рассылки. Напомним, чтобы настроить DMARC в сервисе Estismail — читайте инструкцию. Если у вас более 2-х IP, как у пользователей тарифа CLOUD, то рекомендуем обратиться в нашу техподдержку. Время это сэкономит точно 🙂

Безопасных рассылок и эффективных кампаний!

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

Создание SPF — простая операция. В большинстве случаев для установки базовой защиты достаточно прописать одну строку в TXT-записи домена. Но и здесь есть много подводных камней:

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

• В проверке домена SPF ориентируется исключительно на поле “FROM”, поэтому она работает вместе с DKIM и DMARC, которые задают параметры поиска мошенника не только в поле “Отправитель”, но и в тексте сообщения.

Процесс настройки SPF-записи проходит на сайте провайдера и состоит из 5 этапов. Последний из них — проверка работоспособности и правильности SPF. Ее можно провести на одном из специальных сервисах:

• ;

или в личном аккаунте почтового сервиса Estismail. Зеленая галочка в разделе “Статус” означает, что SPF прописана и внедрена в TXT — запись домена верно:

Поздравляем, теперь Вы можете самостоятельно за несколько минут настроить SPF-запись для своего домена и обеспечить мощную защиту репутации отправителя. Тем не менее, одному лишь SPF не под силу полностью оградить домен от фишинга и спуфинга. Для полной защиты нужно действие трех магов: SPF, DMARC и DKIM. Если хотя бы один из них будет не настроен, то в защите отправляющего домена образуется брешь, через которую спуферы смогут подменить информацию об отправителе. В результате — ваши клиенты от вашего же имени получают спам или вирус, а вы —  ни сном ни духом.  Чтобы избежать такой ситуации — проверьте все записи или обратитесь в нашу службу поддержки. Мы всегда поможем.

Механизмы записи SPF

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

Полезно знать

• Помимо механизмов можно использовать необязательные .
• В записи TXT для SPF можно упоминать не более 10 других доменов и серверов. Эти упоминания называются запросами. Подробнее о том, …

Внедрите DKIM

• Убедитесь, что генерируемые серверами письма соответствуют рекомендациям по структуре, кодировкам и количеству заголовков, иначе возможна ситуация, что при передаче почтовым релеем письмо будет изменено для приведения его в соответствие со стандартами (чаще всего происходит разбивка длинных строк), отчего нарушится DKIM-сигнатура.
• Используйте ключ длиной 1024 или 2048 бит.
• Убедитесь что ваш DNS-сервер поддерживает разрешение больших записей. Обычно для этого помимо доступа к серверу по порту UDP/53 необходимо дополнительно разрешить доступ по TCP/53. Убедитесь что TXT-запись с ключом DKIM корректно разрешается из внешних сетей.
• Используйте режим канонизации relaxed/relaxed, он реже приводит к проблемам, связанным с нормализацией письма при передаче.
• Не подписывайте заголовки, которые меняются при доставке письма (такие как Received: и Return-Path:), убедитесь, что обязательные заголовки (Date:, Message-ID:, From:) формируются до наложения DKIM-подписи
• Внедрите DKIM на всех источниках писем для всех поддоменов.
• Используйте отдельные селекторы с отдельными ключами для внешних источников (провайдеров услуг по рассылке почты), чтобы была возможность отозвать ключ при необходимости.
• Для DMARC необходимо, чтобы домен, используемый в DKIM-подписи, совпадал с точностью до организационного домена с доменом из заголовка From. При этом могут присутствовать и другие DKIM-подписи, но они будут игнорироваться.
• Контролируйте внедрение DKIM по статистическим отчетам от внешних сервисов.
• Используйте в политике DMARC, это позволит получать forensic-репорты по всем проблемам с SPF и DKIM, даже для писем, проходящих авторизацию DMARC.

DMARC

How to configure it?

Using the domain example.com, a possible option can be the next, please note that all the default options will be included implicit, even if you don’t select them in the generator:

This configuration will generate the next DNS entry

• DMARC record for: example.com
• Record should be published at _dmarc.example.com
• v=DMARC1; p=quarantine; rua=dmarc@example.com; ruf=dmarc@example.com; sp=quarantine

And will looks like this in a DNS with web interface:

How to test it

One of the best Sites to test the DMARC is the next link — is coming with the google.com domain per default. This website will show you all the DMARC information about your domain.