Устранение неполадок, связанных с dmarc

Заблуждение: чем больше всего (a, mx, ptr, include) я включу в SPF-запись, тем лучше, потому что меньше вероятность ошибиться

На самом деле: по возможности, следует максимально сократить SPF-запись и использовать в ней только адреса сетей через /.

Объяснение: на разрешение SPF-политики отведен лимит в 10 DNS-запросов. Его превышение приведет к постоянной ошибке политики (permerror). Кроме того, DNS является ненадежной службой, и для каждого запроса есть вероятность сбоя (temperror), которая возрастает с количеством запросов. Каждая дополнительная запись или требует дополнительного DNS-запроса, для также необходимо запросить всё, что указано в include-записи. требует запроса MX-записей и дополнительного запроса A-записи для каждого MX-сервера. требует дополнительного запроса, к тому же в принципе является небезопасной. Только адреса сетей, перечисленные через /, не требуют дополнительных DNS-запросов.

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:

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

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

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

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

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

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

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

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

где:

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

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

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

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

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

где:

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

Теги записи DMARC

Как 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…

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

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

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

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

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

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

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

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

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

• 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

Настройки отображения аватара в письме и обработка нажатия на кнопку «Спам»

Настрока аватара yandex.ru и уведомления при нажатии кнопки СПАМ

Яндекс использует аватары из Gravatar.com.

Здесь можно зарегистрировать FBL-ящик — ящик, на который будет приходить информация обо всех письмах, помеченных как спам на яндексе.
Также яндекс поддерживает заголовок в письме List-Unsubscribe.

Настрока аватара gmail.com

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

Feedback Loop или информация о жалобах на спам

FBL – это стандарт выдачи информации о жалобах на спам от провайдера услуг электронной почты отправителю писем.
После нажатия пользователем кнопки «Спам» в почтовой системе, почтовая система формирует уведомление о том, что пользователеь пометил письмо как спам.
Эту систему используют такие почтовые службы как Hotmail, Yahoo, AOL, mail.ru.

Gmail не предоставляет FBL, но использует специальный заголовок List-Unsubscribe для отписки пользователя от рассылки.

При наличии в письме заголовка List-Unsubscribe у Яндекса рядом с кнопкой «Спам» добавится кнопка «Отписаться».

Обратите внимание, письма без DKIM подписи не получат возможность отправки уведомление о нажатии СПАМ. Здесь есть скрипт и сервис разбора почты и автоматической отписки

Здесь есть скрипт и сервис разбора почты и автоматической отписки.

Что нужно ещё сделать, чтобы снизить попадание в спам

Return-Pathздесь

Можно настроить postfix:
Посмотреть настройки: postconf -n
Изменить здесь: /etc/postfix/main.cf
Протокол работы: journalctl -u postfix

mydomain = htmlweb.ru

Можно его прописать в /usr/local/zend/etc/php.ini:

sendmail_path =/usr/lib/sendmail -t -i -f zakaz@htmlweb.ru

Обязательно удалите заголовок «X-PHP-Originating-Script:», который добавляет php для информирования какой скрипт и в какой строке вызвал функцию mail().
Для этого нужно в файле php.ini закоментировать строчку: «mail.add_x_header = On» и перегрузить сервер. Этот параметр показывает принимающему почтовому серверу,
что письмо отправил скрипт и существенно портит рейтинг письма.

• Читать по теме:
• Проверка вероятности попадания письма в спам
• Универсальная рассылка почты на PHP
• Как зарегистрировать доменое имя?
• Как правильно выбрать хостинг?
• Что такое доменное имя?
• Что такое DNS? Настройка DNS.
• Как вывести сайт на первые позиции в поисковых системах?
• Ошибки при поисковом продвижении.
• Разработка и продвижение сайта командой, разработавшей данный сайт.