Глава 3.
Технические настройки и архитектура email-сообщений
Технические настройки и архитектура email-сообщений
Каждое письмо электронной почты должно быть отправлено с соблюдением определенных стандартов и технологий. Данные стандарты общеприняты для всех сервисов электронной почты и призваны, в первую очередь, защитить получателей от спама, фишинговых атак и другой нежелательной и вредоносной почты.
Сервера, с которых происходит отправка, помещают в так называемые технические заголовки письма определенные записи, которые однозначно информируют сервер принимающей стороны, с какими именно техническими параметрами письмо было отправлено.
На основании записи технических параметров, их правильности и полноты, а также соответствия требованиям почтовой системы (ISP) сервера входящей почты принимают решение осуществить попытку доставки сообщения до ящика получателя или отвергнуть его.
Об обязательных технических настройках будет подробно рассказано в данном разделе.
Сервера, с которых происходит отправка, помещают в так называемые технические заголовки письма определенные записи, которые однозначно информируют сервер принимающей стороны, с какими именно техническими параметрами письмо было отправлено.
На основании записи технических параметров, их правильности и полноты, а также соответствия требованиям почтовой системы (ISP) сервера входящей почты принимают решение осуществить попытку доставки сообщения до ящика получателя или отвергнуть его.
Об обязательных технических настройках будет подробно рассказано в данном разделе.
Request for Comments (RFC) — документ из серии пронумерованных информационных документов Интернета, содержащих технические спецификации и стандарты, широко применяемые во всемирной сети. Название «Request for Comments» еще можно перевести как «заявка (запрос) на отзывы» или «тема для обсуждения».
Когда волосатые дяди и умные тети начали строить интернет в разных частях нашей маленькой планеты, они довольно быстро осознали, что иногда придумывают велосипед, потому что то, что делал один, уже сделано другим и чуть раньше (хороший пример не про интернет — Попов и Белл).
И тогда мировая техническая общественность стала собирать свод правил всего, что так или иначе влияет на интернет и технологии в целом — свод стандартов отрасли. До сих пор в него добавляется все, что появляется в технологическом океане.
Когда волосатые дяди и умные тети начали строить интернет в разных частях нашей маленькой планеты, они довольно быстро осознали, что иногда придумывают велосипед, потому что то, что делал один, уже сделано другим и чуть раньше (хороший пример не про интернет — Попов и Белл).
И тогда мировая техническая общественность стала собирать свод правил всего, что так или иначе влияет на интернет и технологии в целом — свод стандартов отрасли. До сих пор в него добавляется все, что появляется в технологическом океане.
Вся электронная почта должна соответствовать стандартам RFC (например, SMTP 5321; MIME 2045, 2046, 2047, 2048, 2049);
SMTP 5321 (http://tools.ietf.org/rfc/rfc5321.txt );
MIME 2045, 2046, 2047, 2048, 2049.
http://tools.ietf.org/rfc/rfc2045.txt
http://tools.ietf.org/rfc/rfc2046.txt
http://tools.ietf.org/rfc/rfc2047.txt
http://tools.ietf.org/rfc/rfc2048.txt
http://tools.ietf.org/rfc/rfc2049.txt
Описание RFC на русском языке легко гуглится, но можно набрать эту коротенькую ссылочку: http://rfc.com.ru
SMTP 5321 (http://tools.ietf.org/rfc/rfc5321.txt );
MIME 2045, 2046, 2047, 2048, 2049.
http://tools.ietf.org/rfc/rfc2045.txt
http://tools.ietf.org/rfc/rfc2046.txt
http://tools.ietf.org/rfc/rfc2047.txt
http://tools.ietf.org/rfc/rfc2048.txt
http://tools.ietf.org/rfc/rfc2049.txt
Описание RFC на русском языке легко гуглится, но можно набрать эту коротенькую ссылочку: http://rfc.com.ru
Документ этот непонятный и наискучнейший, но любому человеку, связанному с технологиями, следует разок его прочитать, ибо все интернет-сервисы (и почтовые тоже) построены с учетом стандартов, описанных в нем.
Здесь будет уместным сравнение RFC с «самой читаемой книгой в мире», пожалуй, за исключением только того, что RFC продолжают писать.
Здесь будет уместным сравнение RFC с «самой читаемой книгой в мире», пожалуй, за исключением только того, что RFC продолжают писать.
Все почтовые серверы, осуществляющие подключения к почтовым серверам, должны иметь валидные (соответствующие действительности), осмысленные, не автоматически сгенерированные обратные DNS записи (rDNS, PTR-записи).
Наличие корректно настроенного rDNS адреса совершенно необходимо, чтобы отправлять сообщения с вашего собственного сервера. Практически все почтовые серверы отвергнут прием сообщения еще на стадии начала сессии, если у IP-адреса вашего сервера отсутствует запись в обратной зоне DNS. Причина отказа удаленным почтовым сервером, скорее всего, будет указана такой:
Наличие корректно настроенного rDNS адреса совершенно необходимо, чтобы отправлять сообщения с вашего собственного сервера. Практически все почтовые серверы отвергнут прием сообщения еще на стадии начала сессии, если у IP-адреса вашего сервера отсутствует запись в обратной зоне DNS. Причина отказа удаленным почтовым сервером, скорее всего, будет указана такой:
550-"IP address has no PTR (address to name) record in the DNS, or when the PTR record does not have a matching A (name to address) record. Pls check and correct your DNS record."
или:
550-There's no corresponding PTR for your IP address (IP-address), which is 550 required. Sorry, bye.
или просто:
550 Your IP has no PTR Record.
или:
550-There's no corresponding PTR for your IP address (IP-address), which is 550 required. Sorry, bye.
или просто:
550 Your IP has no PTR Record.
Число «550» во всех трех случаях является стандартным кодом почтового SMTP сервера, сообщающего о критической ошибке, которая непреодолимо препятствует дальнейшей работе в рамках данной почтовой сессии. Надо сказать, что вообще все ошибки серии 500 являются критическими, и продолжение передачи почты после их появления невозможно. Текст же поясняет причину отказа более подробно и сообщает, что администратор почтового сервера-получателя настроил его на проверку наличия у почтового сервера-отправителя записи в обратной зоне DNS (rDNS), и, в случае ее отсутствия, сервер-получатель обязан отказывать отправителю в соединении (SMTP-ошибки серии 5XX).
Что-нибудь стало понятно? Из описания, догадываюсь, не очень
Говоря простым языком: доменные имена и IP-адреса не могут быть в интернет-пространстве сами по себе. Владельцы доменов прописывают в настройках DNS необходимые IP-адреса, которые, в свою очередь, принадлежат кому-то, а вам (или вашему хостеру) делегируются. Для обеспечения безопасности интернет-соединения и отправки электронной почты принимающая сторона должна убедиться, что все зоны прописаны верно.
Что-нибудь стало понятно? Из описания, догадываюсь, не очень
Говоря простым языком: доменные имена и IP-адреса не могут быть в интернет-пространстве сами по себе. Владельцы доменов прописывают в настройках DNS необходимые IP-адреса, которые, в свою очередь, принадлежат кому-то, а вам (или вашему хостеру) делегируются. Для обеспечения безопасности интернет-соединения и отправки электронной почты принимающая сторона должна убедиться, что все зоны прописаны верно.
Правами на настройку обратной зоны DNS (reverse DNS) обладает лишь владелец соответствующего блока IP-адресов, которой эта зона соответствует. Как правило, этим владельцем оказывается провайдер, владеющий собственной автономной системой.
Оператору блока IP-адресов для регистрации обратной зоны DNS необходимо зарегистрировать в своем личном кабинете на сайте RIPE объект типа «domain», указать адрес DNS-серверов, которые будут поддерживать зону rDNS, и настроить поддержку зоны вида «3.2.1.in-addr.arpa» на них. За ресурсы в обратной зоне отвечает указатель (pointer) — запись типа PTR. К ней-то и идут запросы о разрешении IP-адреса и имени хоста.
Если же вы не являетесь обладателем автономной системы, то настройка rDNS для IP-адреса или адресов почтового сервера решается запросом в службу поддержки провайдера или хостера.
Когда вы припарковали какой-то домен на хостинге и решили, что с этого домена будут идти рассылки, вам необходимо обратиться в службу поддержки вашего хостинг-провайдера и попросить прописать обратную зону для вашего домена, чтобы связать его с IP-адресами хостера, с которого фактически рассылки и пойдут. Без этого не видать вам инбокса почти во всех почтовых сервисах.
В любом случае имя IP-адресу почтового сервера (а особенно корпоративного почтового сервера) следует давать осмысленно.
Оператору блока IP-адресов для регистрации обратной зоны DNS необходимо зарегистрировать в своем личном кабинете на сайте RIPE объект типа «domain», указать адрес DNS-серверов, которые будут поддерживать зону rDNS, и настроить поддержку зоны вида «3.2.1.in-addr.arpa» на них. За ресурсы в обратной зоне отвечает указатель (pointer) — запись типа PTR. К ней-то и идут запросы о разрешении IP-адреса и имени хоста.
Если же вы не являетесь обладателем автономной системы, то настройка rDNS для IP-адреса или адресов почтового сервера решается запросом в службу поддержки провайдера или хостера.
Когда вы припарковали какой-то домен на хостинге и решили, что с этого домена будут идти рассылки, вам необходимо обратиться в службу поддержки вашего хостинг-провайдера и попросить прописать обратную зону для вашего домена, чтобы связать его с IP-адресами хостера, с которого фактически рассылки и пойдут. Без этого не видать вам инбокса почти во всех почтовых сервисах.
В любом случае имя IP-адресу почтового сервера (а особенно корпоративного почтового сервера) следует давать осмысленно.
Примеры хороших имен для сервера почты:
mail.domain.ru mta.domain.ru mx.domain.ru
Примеры плохих имен:
host-192-168-0-1.domain.ru
customer192-168-0-1.domain.ru
vpn-dailup-xdsl-clients.domain.ru
и подобные.
Такие имена с высокой вероятностью попадут под фильтр, как назначенные клиентским компьютерам, на которых не может быть установлен почтовый сервер, следовательно, с них рассылается спам.
Проверка: http://remote.12dt.com
Вводим свой IP-адрес, если отображается ваш домен — настройка правильная.
mail.domain.ru mta.domain.ru mx.domain.ru
Примеры плохих имен:
host-192-168-0-1.domain.ru
customer192-168-0-1.domain.ru
vpn-dailup-xdsl-clients.domain.ru
и подобные.
Такие имена с высокой вероятностью попадут под фильтр, как назначенные клиентским компьютерам, на которых не может быть установлен почтовый сервер, следовательно, с них рассылается спам.
Проверка: http://remote.12dt.com
Вводим свой IP-адрес, если отображается ваш домен — настройка правильная.
Контактные данные по IP-адресам в «WHOIS» должны быть актуальными и доступными. Так же, как и с обратной зоной, истинный владелец IP-адресов (и доменов, кстати) не должен скрывать информацию о себе. Находясь в легальном правовом поле, это не имеет смысла, как раз наоборот, прямо и косвенно поможет вам в случае возникновения проблем.
Представьте ситуацию — хостера «сломали» и от лица его IP шлют спам. Почтовая служба или блэк-лист, куда поступают жалобы, хочет хостеру сообщить о проблеме и ищет, как это сделать через «WHOIS» адреса и/или домена. Но информации не находит. Естественная реакция — просто заблокировать такие адреса (и/или домены).
Ну и, конечно:
Про то, насколько важно следить за репутацией IP-адресов, я подробно рассказал в разделе [Причины попадания писем в спам].
Очень важно знать, что новые IP-адреса, которые вы собираетесь использовать для рассылок, требуют прогрева. Прогрев — это нарастающая отправка почты с каждого IP-адреса от малого к большему, постепенно наращивая объемы. Обычно Сервисы рассылок предоставляют своим клиентам на выбор автоматический план прогрева для выделенных IP-адресов (когда Сервис сам устанавливает лимиты отправок для каждого IP) или «ручной». В каждом Сервисе есть собственные рекомендации по «ручному» прогреву, но, в целом, они примерно схожие. Прогрев обычно рекомендуется на срок не менее 30 дней и начинается с 50-100 писем в первый день, 200-300 во второй, 500-800 в третий, 1000 в четвертый и так далее.
Уточните у вашего Сервиса, какие они дают рекомендации по прогреву адресов (или почитайте документацию), и четко следуйте инструкциям.
Представьте ситуацию — хостера «сломали» и от лица его IP шлют спам. Почтовая служба или блэк-лист, куда поступают жалобы, хочет хостеру сообщить о проблеме и ищет, как это сделать через «WHOIS» адреса и/или домена. Но информации не находит. Естественная реакция — просто заблокировать такие адреса (и/или домены).
Ну и, конечно:
- IP-адреса, с которых идут рассылки, не должны находиться в black-листах;
- Желательно использовать выделенные IP-адреса.
Про то, насколько важно следить за репутацией IP-адресов, я подробно рассказал в разделе [Причины попадания писем в спам].
Очень важно знать, что новые IP-адреса, которые вы собираетесь использовать для рассылок, требуют прогрева. Прогрев — это нарастающая отправка почты с каждого IP-адреса от малого к большему, постепенно наращивая объемы. Обычно Сервисы рассылок предоставляют своим клиентам на выбор автоматический план прогрева для выделенных IP-адресов (когда Сервис сам устанавливает лимиты отправок для каждого IP) или «ручной». В каждом Сервисе есть собственные рекомендации по «ручному» прогреву, но, в целом, они примерно схожие. Прогрев обычно рекомендуется на срок не менее 30 дней и начинается с 50-100 писем в первый день, 200-300 во второй, 500-800 в третий, 1000 в четвертый и так далее.
Уточните у вашего Сервиса, какие они дают рекомендации по прогреву адресов (или почитайте документацию), и четко следуйте инструкциям.
PTR — «обратная запись». В ней в обратном порядке записывается IP-адрес хоста, с которого в нашем случае рассылается почта. По этой записи почтовики распознают имя хоста по его IP.
Предположим, что IP вашего почтового сервера 78.56.158.23. В NS-записи сервера (или, что чаще, в настройках провайдера сервера или хостера) необходимо добавить следующую DNS запись (IP при этом «разворачиваем»):
23.158.56.78.in-addr.arpa IN PTR mail.mydomain.ru.
Проверка: http://centralops.net/co/DomainDossier.aspx
Предположим, что IP вашего почтового сервера 78.56.158.23. В NS-записи сервера (или, что чаще, в настройках провайдера сервера или хостера) необходимо добавить следующую DNS запись (IP при этом «разворачиваем»):
23.158.56.78.in-addr.arpa IN PTR mail.mydomain.ru.
Проверка: http://centralops.net/co/DomainDossier.aspx
Каждый спамер (каждый!) обладает необходимыми инструментами, чтобы попробовать отослать письмо от вашего домена. С этим можно бороться с помощью DMARC (об этом поговорим подробно позже), но лучше проверить свои сервера. Не даете ли вы всему интернету возможность рассылать письма от лица вашего домена и/или IP-адресов?
Все почтовые сервера должны быть соответствующим образом защищены от неавторизованного или анонимного использования. Убедитесь, что ваш сервер не является открытым прокси-сервером или открытым релеем.
Проверка сервера на open relay: http://tests.nettools.ru
Открытые тексты и утилиты для проверки сервера на открытый proxy:
http://www.corpit.ru/mjt/proxycheck.html
Все почтовые сервера должны быть соответствующим образом защищены от неавторизованного или анонимного использования. Убедитесь, что ваш сервер не является открытым прокси-сервером или открытым релеем.
Проверка сервера на open relay: http://tests.nettools.ru
Открытые тексты и утилиты для проверки сервера на открытый proxy:
http://www.corpit.ru/mjt/proxycheck.html
DomainKey Identified Mail (DKIM)— метод, позволяющий убедиться, что почта отправлена тем, кто имеет на это право. Это протокол цифровой подписи письма.
Принцип работы базируется на двух ключах: публичном и приватном. Публичный ключ размещается в DNS-записи в txt-поле. Приватный ключ размещается на стороне отправляющего сервера. В заголовки каждого отправляемого имейла с помощью приватного ключа в зашифрованном виде добавляются: тело письма, служебные заголовки, время отправки и другие параметры.
Почтовый провайдер обращается к домену отправителя сразу, как только получит подписанное имейл-сообщение. С помощью публичного ключа он расшифровывает заголовок и проверяет соответствие письма и информации в заголовке.
Наличие подписи в массовых имейл-рассылках является обязательным для большинства почтовых провайдеров. Она идентифицирует отправителя, и ISP считает его добросовестным. DKIM в совокупности с SPF-записью делает фишинг-атаки намного более сложными.
Если вы отправляете рассылки самостоятельно, вам нужно озаботиться созданием ключей и настройкой DKIM на стороне собственного сервера.
Пару ключей можно сгенерировать с помощью онлайн-сервисов, например, этого: http://dkimcore.org/tools/keys.html
Безусловно, все описано на сайте самого стандарта (http://www.dkim.org), однако, есть много материалов по самостоятельной настройке DKIM на русском языке. Посмотрите, например, тут: https://habr.com/post/322616/
Как пример:
используем OpenSSL:
openssl.exe genrsa -out tstpriv.pem 1024 — генерируем секретный ключ длиной 1024 бит;
openssl.exe rsa -pubout -in tstpriv.pem -out tstpub.pem — получаем публичный ключ из секретного.
Примером записей является:
mail._domainkey.your.tld TXT "v=DKIM1; k=rsa; t=s; p=<публичный ключ>",
где «mail» — селектор. Можно указать несколько записей с разными селекторами, где в каждой записи будет свой ключ. Применяется, когда задействовано несколько серверов (на каждый сервер свой ключ).
Это самый частый вопрос: сколько записей DKIM может быть в DNS домена?
Если селекторы разные, то записей может быть столько, сколько необходимо. Правда, нужно сказать, что сервисы и почтовые системы, предоставляющие услуги почты для доменов, не очень заморачиваются с названием селектора, и очень часто он просто «mail». Обращайте на это внимание, когда вносите изменения в DNS вашего домена.
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 — неизвестно (что, по сути, аналогично отсутствию записи).
Некоторое время назад основные почтовые сервисы приняли решение запретить массовые рассылки от почтовых ящиков фри-мейлеров, когда, например, в поле отправителя стоит вася@домен_фримейлера.ru. Поэтому, если вы будете пытаться отправить рассылки, где в поле «фром» стоит такой ящик — авторизация по DKIM не пройдет и, в лучшем случае, почтовик выдаст предупреждение, что не может идентифицировать отправителя, в среднем — положит письмо в спам, в худшем — не примет вообще.
Пример корректной записи DKIM в заголовке письма:
dkim=pass header.i=@get-n-post.ru;
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=get-n-post.ru; s=out;
h=Date:Message-Id:Subject:From:To:List-Unsubscribe:MIME-Version:Content-Type; bh=Z7HmzmQ4g….=;b=g7oRC+h3nKY99cnWepbAvdVMh/cqRKFtKDCYAj7Dr9UCeBoe3TZIr0/20E…=;
Помощь в настройке Dkim: http://www.port25.com/support/domainkeysdkim-wizard/
Принцип работы базируется на двух ключах: публичном и приватном. Публичный ключ размещается в DNS-записи в txt-поле. Приватный ключ размещается на стороне отправляющего сервера. В заголовки каждого отправляемого имейла с помощью приватного ключа в зашифрованном виде добавляются: тело письма, служебные заголовки, время отправки и другие параметры.
Почтовый провайдер обращается к домену отправителя сразу, как только получит подписанное имейл-сообщение. С помощью публичного ключа он расшифровывает заголовок и проверяет соответствие письма и информации в заголовке.
Наличие подписи в массовых имейл-рассылках является обязательным для большинства почтовых провайдеров. Она идентифицирует отправителя, и ISP считает его добросовестным. DKIM в совокупности с SPF-записью делает фишинг-атаки намного более сложными.
Если вы отправляете рассылки самостоятельно, вам нужно озаботиться созданием ключей и настройкой DKIM на стороне собственного сервера.
Пару ключей можно сгенерировать с помощью онлайн-сервисов, например, этого: http://dkimcore.org/tools/keys.html
Безусловно, все описано на сайте самого стандарта (http://www.dkim.org), однако, есть много материалов по самостоятельной настройке DKIM на русском языке. Посмотрите, например, тут: https://habr.com/post/322616/
Как пример:
используем OpenSSL:
openssl.exe genrsa -out tstpriv.pem 1024 — генерируем секретный ключ длиной 1024 бит;
openssl.exe rsa -pubout -in tstpriv.pem -out tstpub.pem — получаем публичный ключ из секретного.
Примером записей является:
mail._domainkey.your.tld TXT "v=DKIM1; k=rsa; t=s; p=<публичный ключ>",
где «mail» — селектор. Можно указать несколько записей с разными селекторами, где в каждой записи будет свой ключ. Применяется, когда задействовано несколько серверов (на каждый сервер свой ключ).
Это самый частый вопрос: сколько записей DKIM может быть в DNS домена?
Если селекторы разные, то записей может быть столько, сколько необходимо. Правда, нужно сказать, что сервисы и почтовые системы, предоставляющие услуги почты для доменов, не очень заморачиваются с названием селектора, и очень часто он просто «mail». Обращайте на это внимание, когда вносите изменения в DNS вашего домена.
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 — неизвестно (что, по сути, аналогично отсутствию записи).
Некоторое время назад основные почтовые сервисы приняли решение запретить массовые рассылки от почтовых ящиков фри-мейлеров, когда, например, в поле отправителя стоит вася@домен_фримейлера.ru. Поэтому, если вы будете пытаться отправить рассылки, где в поле «фром» стоит такой ящик — авторизация по DKIM не пройдет и, в лучшем случае, почтовик выдаст предупреждение, что не может идентифицировать отправителя, в среднем — положит письмо в спам, в худшем — не примет вообще.
Пример корректной записи DKIM в заголовке письма:
dkim=pass header.i=@get-n-post.ru;
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=get-n-post.ru; s=out;
h=Date:Message-Id:Subject:From:To:List-Unsubscribe:MIME-Version:Content-Type; bh=Z7HmzmQ4g….=;b=g7oRC+h3nKY99cnWepbAvdVMh/cqRKFtKDCYAj7Dr9UCeBoe3TZIr0/20E…=;
Помощь в настройке Dkim: http://www.port25.com/support/domainkeysdkim-wizard/
SPF — Sender Policy Framework — запись, которая указывает, с каких адресов (доменов и/или IP) следует ожидать почту, и как интерпретировать ошибку в случае несоответствия. По сути, это всего лишь рекомендация отправителя по проверке, но сейчас все почтовые системы обязывают отправителя иметь данную запись в DNS и, скорее всего, письма без SPF и/или выдающие ошибку проверки при приеме почтой либо отвергаются почтовым сервисом, либо помещаются в папку спам, либо будут иметь предупреждение для получателя о возможной угрозе нежелательности данного письма.
Стандарт описывает, как принимающая сторона должна обрабатывать результат, но по некоторым причинам принимающая сторона фактически может: полностью соблюсти описанные правила, интерпретировать по-своему или же вообще проигнорировать рекомендации.
Технические детали
Для размещения данных используется поле TXT в DNS.
Так IANA (функция управления пространствами IP-адресов, доменов верхнего уровня, а также регистрирующая типы данных MIME и параметры прочих протоколов Интернета. Исполняется компанией Public Technical Identifiers, которая находится под контролем ICANN) назначила DNS поле с кодом 99 для SPF.
Формат SPF поля идентичен TXT.
Некоторые системные администраторы прописывают SPF-запись как поле типа SPF и, в принципе, это правильно, но не всякий DNS сервер и клиент понимает такой тип записи. Поэтому совместное использование TXT и SPF считается хорошим подходом, обеспечивающим совместимость и будущее развитие. Но лучше, если запись будет в формате ТХТ, а когда почтовые сервисы перейдут на новый тип записи — я уверен — они оповестят всех заблаговременно.
Стандарт рекомендует доменам, удовлетворяющим требованиям SPF, иметь записи обоих типов. Вместе с тем, как минимум одна запись должна присутствовать обязательно. В случае наличия двух записей они должны быть идентичны.
Например:
example.com. IN TXT «v=spf1 +mx a:colo.example.com/28 -all»
example.com. IN SPF «v=spf1 +mx a:colo.example.com/28 -all»
Если установлена запись SPF, то TXT записи должны быть проигнорированы.
Механизм взаимодействия
Почтовый обмен с использованием SPF происходит по следующему алгоритму:
- Почтовый сервер mx.example.com отправляет письмо на адрес user@example.net.
В DNS записи example.com содержатся такие строки:
mx.example.com. IN A 208.77.188.166
example.com. IN MX 10 mx.example.com.
example.com. IN TXT «v=spf1 +mx -all»
- mx.example.com устанавливает соединение с SMTP example.net и получает от него, например:
>> 220 example.net ESMTP Service (Mailer v1.0) ready at 30.07.2009 12:28:21 UTC
- затем mx.example.com представляется через HELO/EHLO:
<< HELO mx.example.com
- В зависимости от настроек принимающей стороны после данного представления уже может быть проверка на соответствие представленного имени правилам SPF, но в данном месте это необязательно:
>> 250 example.net Hello mx.example.com., pleased to meet you
<< MAIL From:<user@example.com>
- После выдачи отправителем "MAIL FROM" должна последовать обязательная проверка, интерпретация результата и реакция на него.
- В данный момент модуль, отвечающий за проверку SPF, делает следующие вещи:
Осуществляет запрос к DNS;
Запрашивают SPF и TXT поля;
Если в полученном ответе присутствует правило SPF, то оно разбирается и происходит анализ на соответствие.
В нашем примере это правило «v=spf1 +mx -all».
- Согласно правилам проверяются MX-записи и проводится сверка указанных в записях IP-адресов, полученных из представления DNS-имени и IP-адреса подключившегося отправителя.
В данном случае все совпадает, управление возвращается почтовому серверу, и он начинает прием сообщения.
Если фактический IP подключившегося отправителя был иным, то анализатор сообщил бы почтовому серверу, что входящее сообщение невалидно, и, вероятно, его не стоит принимать или на крайний случай отмаркировать отдельно (например, «Спам»).
Формат записи
Запись SPF выглядит примерно так:
example.com. IN SPF «v=spf1 +mx a:colo.example.com/28 -all»
Эта запись содержит следующую информацию:
Вообще, в условии есть 2 части — определитель и механизм.
Определители могут быть: «+» (Pass), «-» (Fail), «~» (SoftFail), «?» (Neutral);
Механизмы: «all», «include», «A», «MX», «PTR», «IP4», «IP6», «exists».
Результатами проверки условий могут являться следующие определенные результаты:
Проблема пересылки
Достаточно часто подписчики могут переслать из своего почтового клиента ваше письмо другому получателю, в этом случае SPF не пройдет проверку и письмо придет с ошибкой в RFC-заголовках (например, «SoftFail»).
В дополнение к SPF некоторые почтовые серверы поддерживают SRS (Sender Rewriting Scheme — схема перезаписи отправителя) — механизм перезаписи адреса отправителя перенаправляемых сообщений так, чтобы они могли пройти проверку SPF. SRS помогает обеспечить доставку сообщений при использовании SPF, чтобы запись была валидной (прошла проверку легитимности).
Технология спорная. Публичные почтовые системы официально ее не поддерживают.
Стандарт описывает, как принимающая сторона должна обрабатывать результат, но по некоторым причинам принимающая сторона фактически может: полностью соблюсти описанные правила, интерпретировать по-своему или же вообще проигнорировать рекомендации.
Технические детали
Для размещения данных используется поле TXT в DNS.
Так IANA (функция управления пространствами IP-адресов, доменов верхнего уровня, а также регистрирующая типы данных MIME и параметры прочих протоколов Интернета. Исполняется компанией Public Technical Identifiers, которая находится под контролем ICANN) назначила DNS поле с кодом 99 для SPF.
Формат SPF поля идентичен TXT.
Некоторые системные администраторы прописывают SPF-запись как поле типа SPF и, в принципе, это правильно, но не всякий DNS сервер и клиент понимает такой тип записи. Поэтому совместное использование TXT и SPF считается хорошим подходом, обеспечивающим совместимость и будущее развитие. Но лучше, если запись будет в формате ТХТ, а когда почтовые сервисы перейдут на новый тип записи — я уверен — они оповестят всех заблаговременно.
Стандарт рекомендует доменам, удовлетворяющим требованиям SPF, иметь записи обоих типов. Вместе с тем, как минимум одна запись должна присутствовать обязательно. В случае наличия двух записей они должны быть идентичны.
Например:
example.com. IN TXT «v=spf1 +mx a:colo.example.com/28 -all»
example.com. IN SPF «v=spf1 +mx a:colo.example.com/28 -all»
Если установлена запись SPF, то TXT записи должны быть проигнорированы.
Механизм взаимодействия
Почтовый обмен с использованием SPF происходит по следующему алгоритму:
- Почтовый сервер mx.example.com отправляет письмо на адрес user@example.net.
В DNS записи example.com содержатся такие строки:
mx.example.com. IN A 208.77.188.166
example.com. IN MX 10 mx.example.com.
example.com. IN TXT «v=spf1 +mx -all»
- mx.example.com устанавливает соединение с SMTP example.net и получает от него, например:
>> 220 example.net ESMTP Service (Mailer v1.0) ready at 30.07.2009 12:28:21 UTC
- затем mx.example.com представляется через HELO/EHLO:
<< HELO mx.example.com
- В зависимости от настроек принимающей стороны после данного представления уже может быть проверка на соответствие представленного имени правилам SPF, но в данном месте это необязательно:
>> 250 example.net Hello mx.example.com., pleased to meet you
<< MAIL From:<user@example.com>
- После выдачи отправителем "MAIL FROM" должна последовать обязательная проверка, интерпретация результата и реакция на него.
- В данный момент модуль, отвечающий за проверку SPF, делает следующие вещи:
Осуществляет запрос к DNS;
Запрашивают SPF и TXT поля;
Если в полученном ответе присутствует правило SPF, то оно разбирается и происходит анализ на соответствие.
В нашем примере это правило «v=spf1 +mx -all».
- Согласно правилам проверяются MX-записи и проводится сверка указанных в записях IP-адресов, полученных из представления DNS-имени и IP-адреса подключившегося отправителя.
В данном случае все совпадает, управление возвращается почтовому серверу, и он начинает прием сообщения.
Если фактический IP подключившегося отправителя был иным, то анализатор сообщил бы почтовому серверу, что входящее сообщение невалидно, и, вероятно, его не стоит принимать или на крайний случай отмаркировать отдельно (например, «Спам»).
Формат записи
Запись SPF выглядит примерно так:
example.com. IN SPF «v=spf1 +mx a:colo.example.com/28 -all»
Эта запись содержит следующую информацию:
- Версия «SPF1» (кстати, пока единственная используемая);
- Письмо может иметь отправителя с IP-адресом, соответствующим записям в MX для домена example.com;
- Письмо может иметь отправителя с IP-адресом, соответствующим одному из адресов в подсети colo.example.com/28;
- Во всех остальных случаях, когда адрес не соответствует перечисленным условиям, считать отправителя недостоверным.
Вообще, в условии есть 2 части — определитель и механизм.
Определители могут быть: «+» (Pass), «-» (Fail), «~» (SoftFail), «?» (Neutral);
Механизмы: «all», «include», «A», «MX», «PTR», «IP4», «IP6», «exists».
Результатами проверки условий могут являться следующие определенные результаты:
- None — означает, что-либо в домене нет записей, либо вообще не удается проверить домен;
- Neutral — возникает в ситуации, когда хозяин домена не хочет или не может сообщить, разрешен ли IP. Этот результат должен обрабатываться так же, как и «None»;
- Pass — означает, что все ОК, и получатель может принять письмо;
- Fail — явно указывает на то, что письмо принимать не следует;
- SoftFail — находится где-то между «Fail» и «Neutral». Принимающая сторона не должна отбрасывать письмо на основании только этого результата;
- TempError — результат, возникающий, если клиент в момент проверки получает временную ошибку. Сообщение можно принять или временно отвергнуть;
- PermError — ошибка, возникающая при невозможности корректной интерпретации DNS записей отправителя.
Проблема пересылки
Достаточно часто подписчики могут переслать из своего почтового клиента ваше письмо другому получателю, в этом случае SPF не пройдет проверку и письмо придет с ошибкой в RFC-заголовках (например, «SoftFail»).
В дополнение к SPF некоторые почтовые серверы поддерживают SRS (Sender Rewriting Scheme — схема перезаписи отправителя) — механизм перезаписи адреса отправителя перенаправляемых сообщений так, чтобы они могли пройти проверку SPF. SRS помогает обеспечить доставку сообщений при использовании SPF, чтобы запись была валидной (прошла проверку легитимности).
Технология спорная. Публичные почтовые системы официально ее не поддерживают.
FeedBack Lookup (FBL) — это стандарт выдачи информации о жалобах на спам от провайдера услуг электронной почты отправителю писем.
Поддержка почтовым сервером FBL означает, что любой отправитель писем (например, веб-сервис) может получать в реальном времени информацию о том, что конкретный пользователь пожаловался (нажал кнопку «Это спам») на конкретное письмо, пришедшее от этого сервиса.
После нажатия кнопки «Спам» сервис формирует отчет в специальном формате ARF (Abuse Report Format), который содержит исходное письмо и электронный адрес пользователя; также отчет может содержать дополнительную мета-информацию.
Формат письма ARF состоит из нескольких частей:
Поддержка почтовым сервером FBL означает, что любой отправитель писем (например, веб-сервис) может получать в реальном времени информацию о том, что конкретный пользователь пожаловался (нажал кнопку «Это спам») на конкретное письмо, пришедшее от этого сервиса.
После нажатия кнопки «Спам» сервис формирует отчет в специальном формате ARF (Abuse Report Format), который содержит исходное письмо и электронный адрес пользователя; также отчет может содержать дополнительную мета-информацию.
Формат письма ARF состоит из нескольких частей:
- Текстовая версия. Предназначена для отображения пользователю, который может читать этот отчет. Может содержать некоторую подробную информацию (о чем этот отчет и почему был сгенерирован).
- Служебная информация об этом отчете (Content-Type: message/feedback-report). Содержит информацию о типе отчета (abuse — для отчетов по жалобам на письма), а также может содержать разного рода дополнительную информацию.
- Исходное письмо, на которое пожаловались, в виде вложения.
Пример ARF-отчета:
From: <abusedesk@example.com>
Date: Thu, 8 Mar 2005 17:40:36 EDT
Subject: FW: Earn money
To: <abuse@example.net>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=feedback-report;
boundary=part1_13d.2e68ed54_boundary
--part1_13d.2e68ed54_boundary
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
This is an email abuse report for an email message received from IP
10.67.41.167 on Thu, 8 Mar 2005 14:00:00 EDT. For more information
about this format please see http://www.mipassoc.org/arf/.
--part1_13d.2e68ed54_boundary
Content-Type: message/feedback-report
Feedback-Type: abuse
User-Agent: SomeGenerator/1.0
Version: 0.1
Original-Mail-From: <somespammer@example.net>
Original-Rcpt-To: <user@example.com>
Received-Date: Thu, 8 Mar 2005 14:00:00 EDT
Source-IP: 10.67.41.167
Authentication-Results: mail.example.com
smtp.mail=somespammer@example.com;
spf=fail
Reported-Domain: example.net
Reported-Uri: http://example.net/earn_money.html
Reported-Uri: mailto:user@example.com
Removal-Recipient: user@example.com
--part1_13d.2e68ed54_boundary
Content-Type: message/rfc822
Content-Disposition: inline
From: <somespammer@example.net>
Received: from mailserver.example.net (mailserver.example.net
[10.67.41.167]) by example.com with ESMTP id M63d4137594e46;
Thu, 8 Mar 2005 14:00:00 -0400
To: <Undisclosed Recipients>
Subject: Earn money
MIME-Version: 1.0
Content-type: text/plain
Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net
Date: Thu, 2 Sep 2004 12:31:03 -0500
Spam Spam Spam
--part1_13d.2e68ed54_boundary--
From: <abusedesk@example.com>
Date: Thu, 8 Mar 2005 17:40:36 EDT
Subject: FW: Earn money
To: <abuse@example.net>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=feedback-report;
boundary=part1_13d.2e68ed54_boundary
--part1_13d.2e68ed54_boundary
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
This is an email abuse report for an email message received from IP
10.67.41.167 on Thu, 8 Mar 2005 14:00:00 EDT. For more information
about this format please see http://www.mipassoc.org/arf/.
--part1_13d.2e68ed54_boundary
Content-Type: message/feedback-report
Feedback-Type: abuse
User-Agent: SomeGenerator/1.0
Version: 0.1
Original-Mail-From: <somespammer@example.net>
Original-Rcpt-To: <user@example.com>
Received-Date: Thu, 8 Mar 2005 14:00:00 EDT
Source-IP: 10.67.41.167
Authentication-Results: mail.example.com
smtp.mail=somespammer@example.com;
spf=fail
Reported-Domain: example.net
Reported-Uri: http://example.net/earn_money.html
Reported-Uri: mailto:user@example.com
Removal-Recipient: user@example.com
--part1_13d.2e68ed54_boundary
Content-Type: message/rfc822
Content-Disposition: inline
From: <somespammer@example.net>
Received: from mailserver.example.net (mailserver.example.net
[10.67.41.167]) by example.com with ESMTP id M63d4137594e46;
Thu, 8 Mar 2005 14:00:00 -0400
To: <Undisclosed Recipients>
Subject: Earn money
MIME-Version: 1.0
Content-type: text/plain
Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net
Date: Thu, 2 Sep 2004 12:31:03 -0500
Spam Spam Spam
--part1_13d.2e68ed54_boundary--
FBL поддерживает большинство крупных мировых email-провайдеров, таких, как «Hotmail», «Yahoo» и «AOL». Для использования FBL обычно надо указать и подтвердить электронный адрес с того же домена (на него будут приходить отчеты), и подтвердить диапазон IP-адресов, с которых вы отправляете почту. В случае с «Hotmail», например, необходимо еще заключить специальный договор.
«Gmail» предоставляет FBL только проверенным (прошедшим «отбор») Сервисам рассылок. В данном случае «Gmail» считает, что этот инструмент позволяет Сервисам отследить недобросовестных клиентов, у которых доля жалоб достаточно высока.
Так, Сервисам, подключенным к программе получения FBL предлагается добавить заголовок Feedback-ID, состоящий из параметров, уникально идентифицирующих кампанию (" "). Идентификаторы с повышенной вероятностью попадания в спам и идентификаторы, из-за которых могут возникать проблемы с доставкой, будут отображаться на панели FBL в "Postmaster Tools".
«Gmail» предоставляет FBL только проверенным (прошедшим «отбор») Сервисам рассылок. В данном случае «Gmail» считает, что этот инструмент позволяет Сервисам отследить недобросовестных клиентов, у которых доля жалоб достаточно высока.
Так, Сервисам, подключенным к программе получения FBL предлагается добавить заголовок Feedback-ID, состоящий из параметров, уникально идентифицирующих кампанию (" "). Идентификаторы с повышенной вероятностью попадания в спам и идентификаторы, из-за которых могут возникать проблемы с доставкой, будут отображаться на панели FBL в "Postmaster Tools".
Формат заголовка при этом рекомендуется такой:
Feedback-ID: a:b:c:SenderId,
где Feedback-ID – это имя внедряемого заголовка;
a, b, c – необязательные поля, в которые отправитель может вставить 3 идентификатора (название компании, клиента или другой параметр);.
SenderId – выбранный отправителем обязательный уникальный идентификатор (5–15 знаков, например, название Сервиса рассылок; должен быть одинаковым во всех письмах).
Feedback-ID: a:b:c:SenderId,
где Feedback-ID – это имя внедряемого заголовка;
a, b, c – необязательные поля, в которые отправитель может вставить 3 идентификатора (название компании, клиента или другой параметр);.
SenderId – выбранный отправителем обязательный уникальный идентификатор (5–15 знаков, например, название Сервиса рассылок; должен быть одинаковым во всех письмах).
В RFC-заголовке письма в записи «List-Unsubscribe» настраивается адрес электронной почты для отправки письма-отписки или URL для быстрой отмены подписки:
List-Unsubscribe: mailto:unsubscribe@youdomain.ru
Или:
List-Unsubscribe: http://my.get-n-post.ru/list/unsubscribe/484/nza1sMUvhCCUpL82ZGP8lF5g7S0nzCXU1Uo0TpuK79A3jtms+RQm2Ym6/SaMmW/T
Или:
List-Unsubscribe: http://my.get-n-post.ru/list/unsubscribe/484/nza1sMUvhCCUpL82ZGP8lF5g7S0nzCXU1Uo0TpuK79A3jtms+RQm2Ym6/SaMmW/T
Данный заголовок дает возможность пользователям почтовых сервисов совершить отписку от рассылки, даже не заходя в само письмо.
Наличие данного заголовка со стороны Сервиса рассылок — это проявление лояльности к пользователям почтовых сервисов, даже несмотря на то, что отписка через «List-Unsubscribe» у некоторых почтовиков засчитывается как жалоба на спам.
Наличие данного заголовка со стороны Сервиса рассылок — это проявление лояльности к пользователям почтовых сервисов, даже несмотря на то, что отписка через «List-Unsubscribe» у некоторых почтовиков засчитывается как жалоба на спам.
Криптографический протокол SSL позволяет общаться клиенту с сервером в сети, предотвращая перехват или фальсификацию.
Он использует асимметричную криптографию для аутентификации ключей обмена, симметричное шифрование для сохранения конфиденциальности, коды аутентификации сообщений для целостности сообщений.
SSL поддерживает 3 типа аутентификации:
Открытый протокол OpenSSL:
http://ru.wikipedia.org/wiki/OpenSSL
Если домен, с которого происходит отправка рассылок, защищен SSL — это дополнительное преимущество для отправителя, повышающее доверие к корреспонденции, которая приходит от данного домена.
Более того, SSL-аутентификация скорее обязательна, чем рекомендуема для компаний, рассылающих своим подписчикам важную информацию, требующую особой защиты, например, от фишинга. К таким отправителям можно отнести банки, государственные органы, страховые компании и так далее.
Он использует асимметричную криптографию для аутентификации ключей обмена, симметричное шифрование для сохранения конфиденциальности, коды аутентификации сообщений для целостности сообщений.
SSL поддерживает 3 типа аутентификации:
- аутентификация обеих сторон (клиент — сервер);
- аутентификация сервера с неаутентифицированным клиентом,
- полная анонимность.
Открытый протокол OpenSSL:
http://ru.wikipedia.org/wiki/OpenSSL
Если домен, с которого происходит отправка рассылок, защищен SSL — это дополнительное преимущество для отправителя, повышающее доверие к корреспонденции, которая приходит от данного домена.
Более того, SSL-аутентификация скорее обязательна, чем рекомендуема для компаний, рассылающих своим подписчикам важную информацию, требующую особой защиты, например, от фишинга. К таким отправителям можно отнести банки, государственные органы, страховые компании и так далее.
Несмотря на технические настройки, позволяющие обезопасить отправителя от подделок, а получателя от спама, злоумышленники пытаются подделывать DKIM, использовать распространенные сервисы не требующих подтверждения доменов для обеспечения валидности SPF-записи, или просто подставлять в поле «фром» ваш домен.
Cтандарты DMARC.org помогают владельцам доменов устанавливать правила, предписывающие (!) почтовым сервисам, участвующим в программе, как поступать с сообщениями, отправленными из домена соответствующего владельца, но не прошедшими аутентификацию. Это способствует борьбе c фишингом, а также помогает защитить пользователей и репутацию компаний.
Одним словом, вы сами указываете, что нужно сделать почтовой системе с письмом, если оно пришло с «битыми» техническими записями. Это очень полезный стандарт, поскольку, даже если никто не пытается отправлять почту от вашего домена, вы можете использовать DMARC как систему контроля ваших технических настроек (особенно, если для рассылок вы используете несколько Сервисов одновременно). Например, вы указали, что письма, которые не проходят проверку, должны быть отправлены в папку «Спам». В «Постмастере» вы увидели при очередной рассылке, что часть писем попадает в спам — это повод сразу же посмотреть отчеты DMARC и определить, не случились ли технические сбои на стороне вашего Сервиса (например, не проходит проверку DKIM или SPF).
Запись DMARC добавляется в TXT записи и должна иметь название: «_dmarc.vash_domen.ru», где «vash_domen.ru» необходимо заменить именем реального домена.
Примеры записей
Ниже приведены примеры записей TXT для проверки DMARC: (_dmarc.vash_domen.ru IN TXT), которые можно изменить в соответствии с потребностями. При этом не забудьте заменить строки «vash_domen.ru» и «postmaster@vash_domen.ru» реальным названием домена и адресом электронной почты.
В приведенном ниже примере записи TXT для сообщения, которое якобы исходит из вашего домена, но не проходит проверку DMARC, не выполняется никаких действий. Все такие сообщения включаются в ежедневный сводный отчет, отправляемый на адрес postmaster@vash_domen.ru:
"v=DMARC1; p=none; rua=mailto:postmaster@vash_domen.ru"
В следующем примере 5% сообщений, которые якобы исходят из вашего домена, но не проходят проверку DMARC, помещаются в карантин.
Соответствующие ежедневные сводные отчеты отправляются на адрес postmaster@vash_domen.ru.
"v=DMARC1; p=quarantine; pct=5; rua=mailto:postmaster@vash_domen.ru"
При такой записи все сообщения, которые якобы исходят из вашего домена, но не проходят проверку DMARC, отклоняются. Соответствующие ежедневные сводные отчеты отправляются на адреса postmaster@vash_domen.ru и dmarc@vash_domen.ru.
"v=DMARC1; p=reject; rua=mailto:postmaster@vash_domen.ru mailto:dmarc@vash_domen."
Ящик для получения отчетов обязательно должен быть в домене, с которого вы отправляете рассылки, и должен существовать и принимать почту. Иначе запись DMARC сама по себе не пройдет проверку и может быть отвергнута почтовым сервисом.
Полный реестр тегов DMARC:
http://dmarc.org/draft-dmarc-base-00-01.html#iana_dmarc_tags
Cтандарты DMARC.org помогают владельцам доменов устанавливать правила, предписывающие (!) почтовым сервисам, участвующим в программе, как поступать с сообщениями, отправленными из домена соответствующего владельца, но не прошедшими аутентификацию. Это способствует борьбе c фишингом, а также помогает защитить пользователей и репутацию компаний.
Одним словом, вы сами указываете, что нужно сделать почтовой системе с письмом, если оно пришло с «битыми» техническими записями. Это очень полезный стандарт, поскольку, даже если никто не пытается отправлять почту от вашего домена, вы можете использовать DMARC как систему контроля ваших технических настроек (особенно, если для рассылок вы используете несколько Сервисов одновременно). Например, вы указали, что письма, которые не проходят проверку, должны быть отправлены в папку «Спам». В «Постмастере» вы увидели при очередной рассылке, что часть писем попадает в спам — это повод сразу же посмотреть отчеты DMARC и определить, не случились ли технические сбои на стороне вашего Сервиса (например, не проходит проверку DKIM или SPF).
Запись DMARC добавляется в TXT записи и должна иметь название: «_dmarc.vash_domen.ru», где «vash_domen.ru» необходимо заменить именем реального домена.
Примеры записей
Ниже приведены примеры записей TXT для проверки DMARC: (_dmarc.vash_domen.ru IN TXT), которые можно изменить в соответствии с потребностями. При этом не забудьте заменить строки «vash_domen.ru» и «postmaster@vash_domen.ru» реальным названием домена и адресом электронной почты.
В приведенном ниже примере записи TXT для сообщения, которое якобы исходит из вашего домена, но не проходит проверку DMARC, не выполняется никаких действий. Все такие сообщения включаются в ежедневный сводный отчет, отправляемый на адрес postmaster@vash_domen.ru:
"v=DMARC1; p=none; rua=mailto:postmaster@vash_domen.ru"
В следующем примере 5% сообщений, которые якобы исходят из вашего домена, но не проходят проверку DMARC, помещаются в карантин.
Соответствующие ежедневные сводные отчеты отправляются на адрес postmaster@vash_domen.ru.
"v=DMARC1; p=quarantine; pct=5; rua=mailto:postmaster@vash_domen.ru"
При такой записи все сообщения, которые якобы исходят из вашего домена, но не проходят проверку DMARC, отклоняются. Соответствующие ежедневные сводные отчеты отправляются на адреса postmaster@vash_domen.ru и dmarc@vash_domen.ru.
"v=DMARC1; p=reject; rua=mailto:postmaster@vash_domen.ru mailto:dmarc@vash_domen."
Ящик для получения отчетов обязательно должен быть в домене, с которого вы отправляете рассылки, и должен существовать и принимать почту. Иначе запись DMARC сама по себе не пройдет проверку и может быть отвергнута почтовым сервисом.
Полный реестр тегов DMARC:
http://dmarc.org/draft-dmarc-base-00-01.html#iana_dmarc_tags
Технические заголовки писем в разных сервисах могут иметь разное местонахождение в интерфейсе и называться по-своему:
«GMAIL» — «Показать оригинал»;
«MAIL.RU» — «Служебные заголовки»;
«YANDEX» — «Свойства письма».
На следующих трех скриншотах показано, как их найти в веб-интерфейсе:
«GMAIL» — «Показать оригинал»;
«MAIL.RU» — «Служебные заголовки»;
«YANDEX» — «Свойства письма».
На следующих трех скриншотах показано, как их найти в веб-интерфейсе:
Gmail.com
Mail.ru
Mail.Yandex.ru
Каждая почтовая система добавляет в технические заголовки собственные уникальные записи, которые обеспечивают идентификацию писем и их свойства внутри почты, но общий вид технических заголовков стандартизирован.
Умение читать технические заголовки — один из первостепенных навыков, которыми должен овладеть специалист по имейл рассылкам. В заголовках столько интересных данных, что их по праву можно назвать кладезем информации о письме в целом: от кого оно, каким сервисом разослано, какие системы отправки (МТА) и сервисы используют, какой диапазон IP-адресов используют, и где он зарегистрирован, и еще много-много интересного.
Умение читать технические заголовки — один из первостепенных навыков, которыми должен овладеть специалист по имейл рассылкам. В заголовках столько интересных данных, что их по праву можно назвать кладезем информации о письме в целом: от кого оно, каким сервисом разослано, какие системы отправки (МТА) и сервисы используют, какой диапазон IP-адресов используют, и где он зарегистрирован, и еще много-много интересного.
Вот полный технический заголовок письма из моего почтового ящика в сервисе «mail.ru»:
Delivered-To: x#####@mail.ru
Return-path: <postmaster@youdrive.today>
Received-SPF: pass (mx188.mail.ru: domain of youdrive.today designates 213.109.77.56 as permitted sender) client-ip=213.109.77.56; envelope-from=postmaster@youdrive.today; helo=mx25.sendpulse.io;
Received: from mx25.sendpulse.io ([213.109.77.56]:40624)
by mx188.mail.ru with esmtp (envelope-from <postmaster@youdrive.today>)
id 1fCloh-0004qp-LA
for x####@mail.ru; Sun, 29 Apr 2018 15:52:35 +0300
Received: from [127.0.0.1] (helo=mailer02.sendpulse.io)
by sendpulse.io with esmtp (Exim 4.88_29-9c63814-XX)
(envelope-from <lab@youdrive.today>)
id 1fCloa-0000LF-8g
for x#####@mail.ru; Sun, 29 Apr 2018 14:52:28 +0200
Content-Type: multipart/alternative;
boundary="===============9125649223522575729=="
MIME-Version: 1.0
From: =?utf-8?q?YouDrive_Lab?= <lab@youdrive.today>
Precedence: bulk
Feedback-ID: 6481889:1702492:540306:409974
List-ID: 1702492@sendpulse.io
Subject: =?utf-8?b?0KPRh9GR0L3Ri9C1INC90LAg0LrQsNC90LjQutGD0LvQsNGF?=
Date: Sun, 29 Apr 2018 12:52:28 +0000 (CET)
Sender: lab@youdrive.today
X-Mailru-Msgtype: task6481889
X-Authenticated-User: ab63cdd6c739cbf7406197d84b3d159e@youdrive.today
Errors-To: postmaster@sendpulse.io
X-Complaints-To: abuse@sendpulse.io
To: x#####@mail.ru
List-Unsubscribe: <http://s540306.stat-pulse.com/unsubscribes/ru/NjQ4MTg4OQ==/bdb75dad240c2b58c5db91a6d057a13d/h/9dae6d62c816560a842268bde2cd317d>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=youdrive.today;
i=@youdrive.today; q=dns/txt; s=sign; t=1525006348; h=Subject : From :
To; bh=58M7Vv5E9jF+R+0H1HpRrcOAXVTuez9xckKy2h2QFk4=;
b=Y2mcnCeafYBQmAo+vh3Ngxe77IZWr3Pd+39No0AdO+9kCGN+AmkZtrp7GiE+HJQUlSVqlF
E5ErKAU06Hkb5jNDE4337RUM7yLp9hPPMIddals/JXiLJKdOwACjybQpssk3D1j1j2QUe/bz
/N3rNvcwUnLLlCTIKoF1tWaGuwQ+Y=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendpulse.io;
i=@sendpulse.io;
q=dns/txt; s=sign; t=1525006348; h=Subject : From : To;
bh=58M7Vv5E9jF+R+0H1HpRrcOAXVTuez9xckKy2h2QFk4=;
b=RjKvm4wLcrPoxEfgLIxtfFyns3gwwekAWSeLflou7uDmiWTZLPqtxO95fJfIPtWDCOolZN
HcQU1B/pFSkQBRPMtAH1Fgl3s5DnbYei1w6aytJSkBzWaI+FFTvBTIo6S2lttptBJl7bJaJ8
nFfWOnvAOYwY/nKquzjuD+bsQOYG0=
Message-Id: <1fCloa-0000LF-8g@mx25.sendpulse.io>
X-DMARC-Policy: none
X-DMARC-Result: pass
X-Mailru-Dmarc-Auth: dmarc=pass header.from=lab@youdrive.today
X-Mras: OK
X-Spam: undefined
Authentication-Results: mxs.mail.ru; spf=pass (mx188.mail.ru: domain of youdrive.today designates 213.109.77.56 as permitted sender) smtp.mailfrom=postmaster@youdrive.today smtp.helo=mx25.sendpulse.io;
dkim=pass header.d=youdrive.today;
dkim=pass header.d=sendpulse.io; dmarc=pass header.from=lab@youdrive.today
Разберем данный заголовок по частям:
Delivered-To: x#####@mail.ru
Return-path: <postmaster@youdrive.today>
Delivered-To: x#####@mail.ru
Return-path: <postmaster@youdrive.today>
Received-SPF: pass (mx188.mail.ru: domain of youdrive.today designates 213.109.77.56 as permitted sender) client-ip=213.109.77.56; envelope-from=postmaster@youdrive.today; helo=mx25.sendpulse.io;
Received: from mx25.sendpulse.io ([213.109.77.56]:40624)
by mx188.mail.ru with esmtp (envelope-from <postmaster@youdrive.today>)
id 1fCloh-0004qp-LA
for x####@mail.ru; Sun, 29 Apr 2018 15:52:35 +0300
Received: from [127.0.0.1] (helo=mailer02.sendpulse.io)
by sendpulse.io with esmtp (Exim 4.88_29-9c63814-XX)
(envelope-from <lab@youdrive.today>)
id 1fCloa-0000LF-8g
for x#####@mail.ru; Sun, 29 Apr 2018 14:52:28 +0200
Content-Type: multipart/alternative;
boundary="===============9125649223522575729=="
MIME-Version: 1.0
From: =?utf-8?q?YouDrive_Lab?= <lab@youdrive.today>
Precedence: bulk
Feedback-ID: 6481889:1702492:540306:409974
List-ID: 1702492@sendpulse.io
Subject: =?utf-8?b?0KPRh9GR0L3Ri9C1INC90LAg0LrQsNC90LjQutGD0LvQsNGF?=
Date: Sun, 29 Apr 2018 12:52:28 +0000 (CET)
Sender: lab@youdrive.today
X-Mailru-Msgtype: task6481889
X-Authenticated-User: ab63cdd6c739cbf7406197d84b3d159e@youdrive.today
Errors-To: postmaster@sendpulse.io
X-Complaints-To: abuse@sendpulse.io
To: x#####@mail.ru
List-Unsubscribe: <http://s540306.stat-pulse.com/unsubscribes/ru/NjQ4MTg4OQ==/bdb75dad240c2b58c5db91a6d057a13d/h/9dae6d62c816560a842268bde2cd317d>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=youdrive.today;
i=@youdrive.today; q=dns/txt; s=sign; t=1525006348; h=Subject : From :
To; bh=58M7Vv5E9jF+R+0H1HpRrcOAXVTuez9xckKy2h2QFk4=;
b=Y2mcnCeafYBQmAo+vh3Ngxe77IZWr3Pd+39No0AdO+9kCGN+AmkZtrp7GiE+HJQUlSVqlF
E5ErKAU06Hkb5jNDE4337RUM7yLp9hPPMIddals/JXiLJKdOwACjybQpssk3D1j1j2QUe/bz
/N3rNvcwUnLLlCTIKoF1tWaGuwQ+Y=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendpulse.io;
i=@sendpulse.io;
q=dns/txt; s=sign; t=1525006348; h=Subject : From : To;
bh=58M7Vv5E9jF+R+0H1HpRrcOAXVTuez9xckKy2h2QFk4=;
b=RjKvm4wLcrPoxEfgLIxtfFyns3gwwekAWSeLflou7uDmiWTZLPqtxO95fJfIPtWDCOolZN
HcQU1B/pFSkQBRPMtAH1Fgl3s5DnbYei1w6aytJSkBzWaI+FFTvBTIo6S2lttptBJl7bJaJ8
nFfWOnvAOYwY/nKquzjuD+bsQOYG0=
Message-Id: <1fCloa-0000LF-8g@mx25.sendpulse.io>
X-DMARC-Policy: none
X-DMARC-Result: pass
X-Mailru-Dmarc-Auth: dmarc=pass header.from=lab@youdrive.today
X-Mras: OK
X-Spam: undefined
Authentication-Results: mxs.mail.ru; spf=pass (mx188.mail.ru: domain of youdrive.today designates 213.109.77.56 as permitted sender) smtp.mailfrom=postmaster@youdrive.today smtp.helo=mx25.sendpulse.io;
dkim=pass header.d=youdrive.today;
dkim=pass header.d=sendpulse.io; dmarc=pass header.from=lab@youdrive.today
Разберем данный заголовок по частям:
Delivered-To: x#####@mail.ru
Return-path: <postmaster@youdrive.today>
Письмо доставлено на адрес x#####@mail.ru.
Если ящик, на который письмо было отправлено, принял письмо с ошибкой, или ящик не существует, то почтовая система отправит outloop-отчет на ящик, указанный в поле «Return-path». Такие отчеты в среде специалистов Сервисов рассылок называют «отлупами», с одной стороны, это калька с английского термина, с другой — четко доносит смысл: почтовик отлупил ваше письмо, идите, разбирайтесь, что с ним (или с получателем) не так.
В данном случает отправитель самостоятельно будет обрабатывать ошибки, в то время как обычно в «Return-path» находится специальный ящик Сервиса рассылок.
Если ящик, на который письмо было отправлено, принял письмо с ошибкой, или ящик не существует, то почтовая система отправит outloop-отчет на ящик, указанный в поле «Return-path». Такие отчеты в среде специалистов Сервисов рассылок называют «отлупами», с одной стороны, это калька с английского термина, с другой — четко доносит смысл: почтовик отлупил ваше письмо, идите, разбирайтесь, что с ним (или с получателем) не так.
В данном случает отправитель самостоятельно будет обрабатывать ошибки, в то время как обычно в «Return-path» находится специальный ящик Сервиса рассылок.
Received-SPF: pass (mx188.mail.ru: domain of youdrive.today designates 213.109.77.56 as permitted sender) client-ip=213.109.77.56; envelope-from=postmaster@youdrive.today; helo=mx25.sendpulse.io;
Received: from mx25.sendpulse.io ([213.109.77.56]:40624)
Received: from mx25.sendpulse.io ([213.109.77.56]:40624)
«SPF: pass» говорит о том, что письмо было аутентифицировано, SPF прошел проверку. В DNS домена youdrive.today прописаны необходимые записи Сервиса рассылок. В данном случае это «Sendpulse», в чем можно убедиться, если проверить IP-адрес 213.109.77.56, с которого пришло письмо.
Проверим его через «whois» — запись соответствует действительности, и данные владельца открыты, что правильно.
Проверим его через «whois» — запись соответствует действительности, и данные владельца открыты, что правильно.
inetnum: 213.109.76.0 - 213.109.77.255
netname: SendPulse
organisation: ORG-SI172-RIPE
org-name: SendPulse Inc
org-type: OTHER
address: 19 Hill S Bernardsvill, NJ 07924, USA
abuse-c: ACRO2989-RIPE
mnt-ref: MNT-SENDPULSE
mnt-by: MNT-SENDPULSE
Далее:
id 1fCloh-0004qp-LA
for x####@mail.ru; Sun, 29 Apr 2018 15:52:35 +0300
Received: from [127.0.0.1] (helo=mailer02.sendpulse.io)
by sendpulse.io with esmtp (Exim 4.88_29-9c63814-XX)
(envelope-from <lab@youdrive.today>)
id 1fCloa-0000LF-8g
for x#####@mail.ru; Sun, 29 Apr 2018 14:52:28 +0200
netname: SendPulse
organisation: ORG-SI172-RIPE
org-name: SendPulse Inc
org-type: OTHER
address: 19 Hill S Bernardsvill, NJ 07924, USA
abuse-c: ACRO2989-RIPE
mnt-ref: MNT-SENDPULSE
mnt-by: MNT-SENDPULSE
Далее:
id 1fCloh-0004qp-LA
for x####@mail.ru; Sun, 29 Apr 2018 15:52:35 +0300
Received: from [127.0.0.1] (helo=mailer02.sendpulse.io)
by sendpulse.io with esmtp (Exim 4.88_29-9c63814-XX)
(envelope-from <lab@youdrive.today>)
id 1fCloa-0000LF-8g
for x#####@mail.ru; Sun, 29 Apr 2018 14:52:28 +0200
Мы видим уникальный ID письма, по которому его можно найти в логах Сервиса рассылок, и дату/время, когда письмо было отправлено с серверов.
Precedence: bulk
Feedback-ID: 6481889:1702492:540306:409974
List-ID: 1702492@sendpulse.io
Subject: =?utf-8?b?0KPRh9GR0L3Ri9C1INC90LAg0LrQsNC90LjQutGD0LvQsNGF?=
Date: Sun, 29 Apr 2018 12:52:28 +0000 (CET)
Sender: lab@youdrive.today
X-Mailru-Msgtype: task6481889
To: x#####@mail.ru
Feedback-ID: 6481889:1702492:540306:409974
List-ID: 1702492@sendpulse.io
Subject: =?utf-8?b?0KPRh9GR0L3Ri9C1INC90LAg0LrQsNC90LjQutGD0LvQsNGF?=
Date: Sun, 29 Apr 2018 12:52:28 +0000 (CET)
Sender: lab@youdrive.today
X-Mailru-Msgtype: task6481889
To: x#####@mail.ru
«Presedence: bulk» говорит почтовому сервису, что письмо надо отнести к массовым рассылкам (во многих почтовиках это требование обязательно, массовость рассылки надо явно указать).
«X-Mailru-Msgtype: task6481889» специальный тег, по которому группу писем и/или письмо можно будет найти в «Постмастере.Mail.Ru» — это важно, в случае если письмо попадет в папку Спам, поскольку в этом случае отправитель не получит «отлуп» на ящик, указанный в "Return-path".
Запись «To: x#####@mail.ru» — говорит о том, кому предназначалось письмо. Важно помнить, что ящики в «To:» и в «Delivered-To:» могут отличаться, если у получателя настроена переадресация.
«X-Mailru-Msgtype: task6481889» специальный тег, по которому группу писем и/или письмо можно будет найти в «Постмастере.Mail.Ru» — это важно, в случае если письмо попадет в папку Спам, поскольку в этом случае отправитель не получит «отлуп» на ящик, указанный в "Return-path".
Запись «To: x#####@mail.ru» — говорит о том, кому предназначалось письмо. Важно помнить, что ящики в «To:» и в «Delivered-To:» могут отличаться, если у получателя настроена переадресация.
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=youdrive.today;
i=@youdrive.today; q=dns/txt; s=sign; t=1525006348; h=Subject : From :
To; bh=58M7Vv5E9jF+R+0H1HpRrcOAXVTuez9xckKy2h2QFk4=; b=Y2mcnCeafYBQmAo+vh3Ngxe77IZWr3Pd+39No0AdO+9kCGN+AmkZtrp7GiE+HJQUlSVqlF.........
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendpulse.io;
i=@sendpulse.io;
q=dns/txt; s=sign; t=1525006348; h=Subject : From : To;
bh=58M7Vv5E9jF+R+0H1HpRrcOAXVTuez9xckKy2h2QFk4=........
i=@youdrive.today; q=dns/txt; s=sign; t=1525006348; h=Subject : From :
To; bh=58M7Vv5E9jF+R+0H1HpRrcOAXVTuez9xckKy2h2QFk4=; b=Y2mcnCeafYBQmAo+vh3Ngxe77IZWr3Pd+39No0AdO+9kCGN+AmkZtrp7GiE+HJQUlSVqlF.........
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendpulse.io;
i=@sendpulse.io;
q=dns/txt; s=sign; t=1525006348; h=Subject : From : To;
bh=58M7Vv5E9jF+R+0H1HpRrcOAXVTuez9xckKy2h2QFk4=........
Далее следуют записи ключей DKIM отправителя и Сервиса рассылок.
Не так давно почтовые сервисы стали поддерживать множественные записи DKIM в заголовках и правильно их обрабатывать. Множественная запись дает преимущество — и отправитель рассылки, и Сервис, который фактически отправку сделал, могут видеть результаты доставки в «Постмастере». Более того, почтовый сервис отслеживает, кто именно (фактически) производит отправки тех или иных рассылок, и может помочь Сервису решить некоторые проблемы в случае возникновения проблем с доставкой.
Не так давно почтовые сервисы стали поддерживать множественные записи DKIM в заголовках и правильно их обрабатывать. Множественная запись дает преимущество — и отправитель рассылки, и Сервис, который фактически отправку сделал, могут видеть результаты доставки в «Постмастере». Более того, почтовый сервис отслеживает, кто именно (фактически) производит отправки тех или иных рассылок, и может помочь Сервису решить некоторые проблемы в случае возникновения проблем с доставкой.
Записи
dkim=pass header.d=youdrive.today;
dkim=pass header.d=sendpulse.io
говорят, что оба DKIM валидные.
Но, очевидно, есть, что улучшить в письме
X-DMARC-Policy: none
X-DMARC-Result: pass
X-Mailru-Dmarc-Auth: dmarc=pass
dkim=pass header.d=youdrive.today;
dkim=pass header.d=sendpulse.io
говорят, что оба DKIM валидные.
Но, очевидно, есть, что улучшить в письме
X-DMARC-Policy: none
X-DMARC-Result: pass
X-Mailru-Dmarc-Auth: dmarc=pass
Запись DMARC в DNS отправителя присутствует и валидная, но она прописана с ключом «none» — не предпринимать никаких действий. Это говорит о том, что в случае, если злоумышленник попробует подделать письма от домена отправителя, какая-то часть (в зависимости от репутации доменов) может попасть в инбокс получателям.
Рекомендуется прописывать политики DMARC как «quarantine» или «reject».
Рекомендуется прописывать политики DMARC как «quarantine» или «reject».
Какие проблемы можно обнаружить в заголовках
Посмотрим, что мы можем увидеть в заголовках, когда у нас возникают проблемы
• IP-адрес в Black-листе (dnsbl.info), как рассылающий спам
X-DMARC-Policy: no
X-Mailru-Noreply: yes
X-Mras: OK X-Spam: undefined
X-UBL: Black
• Проблема с DKIM записью
X-DKIM-FAIL: DKIM test failed: invalid (address=sender@get-n-post.ru domain=v####o.su reason=pubkey_syntax).
X-DMARC-Result: fail X-Mailru-Dmarc-Auth: dmarc=fail header.from=ad@v####o.su
X-Mras: OK
X-Spam: undefined
Authentication-Results: mxs.mail.ru; spf=pass (mx178.mail.ru: domain of get-n-post.ru designates 212.24.39.198 as permitted sender) smtp.mailfrom=sender@get-n-post.ru smtp.helo=out5.get-n-post.ru;
dkim=pass header.d=get-n-post.ru;
dkim=invalid reason=pubkey_syntax header.d=v####o.su; dmarc=fail header.from=ad@v###o.su
• Публичный ключ в DNS домене отправителя записан с ошибкой.
• Срабатывание или ошибка DMARC
В этом случае технические настройки в письме неверны, DMARC не прошел аутентификацию, и почтовая система отправила письмо в папку «Спам», как подозрительное.
X-DMARC-Result: fail
X-Magic: D7426F4F725623B9A9F6DBBE852452D0140F2EFE3225FE7459A0A3EE30C7B419 X-Mailru-Dmarc-Auth: dmarc=fail header.from=ras###@email2.#####ir.ru
X-Mras: PROBABLE_SPAM
X-Spam: undefined
Кстати, так сказать, «хозяйке на заметку» строка «X-Magic: D7426F4F725623B9A9F6DBBE852452D0140F2EFE3225FE7459A0A3EE30C7B419» очень пригодится вам, если ваши письма стали попадать в папку «Спам» в сервисе «Mail.ru». Именно это значение попросит вас предоставить Служба поддержки при обращении. По данному идентификатору они смогут проследить историю и причины.
• Проблема с SPF
Received-SPF: fail (mx144.mail.ru: domain of r####a.su does not designate 000.88.00.100 as permitted sender) client-ip=000.88.00.100; envelope-from=hello@r####a.su; helo=forward100p.mail.yandex.net; Received: from forward100p.mail.yandex.net ([000.88.00.100]:46112)
В данном случае письмо отправлено с IP-адреса 000.88.00.100, который не прописан в DNS домена r####a.su.
Посмотрим, что мы можем увидеть в заголовках, когда у нас возникают проблемы
• IP-адрес в Black-листе (dnsbl.info), как рассылающий спам
X-DMARC-Policy: no
X-Mailru-Noreply: yes
X-Mras: OK X-Spam: undefined
X-UBL: Black
• Проблема с DKIM записью
X-DKIM-FAIL: DKIM test failed: invalid (address=sender@get-n-post.ru domain=v####o.su reason=pubkey_syntax).
X-DMARC-Result: fail X-Mailru-Dmarc-Auth: dmarc=fail header.from=ad@v####o.su
X-Mras: OK
X-Spam: undefined
Authentication-Results: mxs.mail.ru; spf=pass (mx178.mail.ru: domain of get-n-post.ru designates 212.24.39.198 as permitted sender) smtp.mailfrom=sender@get-n-post.ru smtp.helo=out5.get-n-post.ru;
dkim=pass header.d=get-n-post.ru;
dkim=invalid reason=pubkey_syntax header.d=v####o.su; dmarc=fail header.from=ad@v###o.su
• Публичный ключ в DNS домене отправителя записан с ошибкой.
• Срабатывание или ошибка DMARC
В этом случае технические настройки в письме неверны, DMARC не прошел аутентификацию, и почтовая система отправила письмо в папку «Спам», как подозрительное.
X-DMARC-Result: fail
X-Magic: D7426F4F725623B9A9F6DBBE852452D0140F2EFE3225FE7459A0A3EE30C7B419 X-Mailru-Dmarc-Auth: dmarc=fail header.from=ras###@email2.#####ir.ru
X-Mras: PROBABLE_SPAM
X-Spam: undefined
Кстати, так сказать, «хозяйке на заметку» строка «X-Magic: D7426F4F725623B9A9F6DBBE852452D0140F2EFE3225FE7459A0A3EE30C7B419» очень пригодится вам, если ваши письма стали попадать в папку «Спам» в сервисе «Mail.ru». Именно это значение попросит вас предоставить Служба поддержки при обращении. По данному идентификатору они смогут проследить историю и причины.
• Проблема с SPF
Received-SPF: fail (mx144.mail.ru: domain of r####a.su does not designate 000.88.00.100 as permitted sender) client-ip=000.88.00.100; envelope-from=hello@r####a.su; helo=forward100p.mail.yandex.net; Received: from forward100p.mail.yandex.net ([000.88.00.100]:46112)
В данном случае письмо отправлено с IP-адреса 000.88.00.100, который не прописан в DNS домена r####a.su.
Тексты докладов
Видео мастер-классы
Онлайн-версия книг
Видео мастер-классы
Онлайн-версия книг
КОНФЕРЕНЦИИ
ВЕБИНАРЫ
Usability писем – разбор примеров
О ПРОЕКТЕ
Контакты
Партнерам
Партнерам
Про тот самый email-маркетинг
Вам будет очень интересно читать нашу рассылку. Но это не точно...
Иногда это будет просто полезно, без всякого интереса
Иногда это будет просто полезно, без всякого интереса
Не забудьте, что подписываясь, вы соглашаетесь на обработку ваших данных!