подтвержденный домен не соответствует отправителю как исправить
Подтвержденный домен не соответствует отправителю как исправить
Вы получили данное предупреждение, т.к. мы не можем гарантировать, что адрес, написанный в поле «От кого», реальный.
Подобным образом могут действовать мошенники — отправлять письма, подделывая адрес отправителя, с целью заставить получателей поверить в содержимое писем.
Чтобы вы не попались на уловку мошенников, Mail.Ru предупреждает о подозрительных случаях, используя для этого проверку подлинности DMARC.
Для осуществления проверки, реальные владельцы домена должны разместить на своей стороне политику DMARC. Так, например, чтобы помешать мошенникам отправлять письма с адреса support@corp.mail.ru, Mail.Ru опубликовал DMARC.
Политика DMARC включает в себя проверку трех параметров:
Таким образом, если письмо не проходит проверку по этим параметрам, вы видите предупреждение о том, что мы не можем гарантировать, что письмо было отправлено с указанного адреса.
В некоторых случаях сообщение может показываться на письмах, отправленных в группы и списки рассылки, перенаправленных письмах или письмах, отправленных через серверы, которые не поддерживают проверку подлинности DKIM и SPF. В таких случаях мы рекомендуем администратору сервера-отправителя привести конфигурацию в соответствие с требованиями DMARC.
Обращаем ваше внимание на то, что мы не рекомендуем отвечать на подобные письма, а также совершать указанные в них действия: отправлять пароли и личные данные, скачивать вложения, пересылать и пр.
Если вы знаете отправителя письма, рекомендуем вам связаться с ним альтернативными способами и уточнить — отправлял ли он данное сообщение.
Типичные ошибки при подключении доменной почты
Для отправления рассылок или корпоративных писем обычный почтовый ящик не подойдет. Нужно учесть настройки вроде DKIM-подписок и MX-записей, чтобы наладить массовую рассылку и быть уверенным, что клиент или заказчик точно получит сообщение. Еще нужно пройти проверку спам-фильтров, которые могут заблокировать самые обычные письма, если они не соответствуют требованиям сервиса. Поэтому бизнесу легче создать корпоративный ящик, где большая часть настроек уже выполнена. Это можно сделать в сервисе Почта для домена от Mail.ru для бизнеса. Служба безопасности защитит ваши данные. Все параметры настроены для отправления рассылок и коммерческих сообщений. Но иногда при подключении доменного ящика могут появиться ошибки. Рассмотрим основные проблемы и расскажем, как их исправить.
Как подготовиться к рассылке?
Даже правильные настройки почтовой службы не гарантируют идеальную доставляемость писем. Особенно в первые время после подключения доменной почты. Часто письма не доходят из-за неисправностей со стороны получателя — проблемы с его сервером или ваш адрес оказался в спам-листе.
Отправку лучше начать со своего личного ящика — тестовая рассылка придет с корпоративной почты. Можно посмотреть получение письма в разных сервисах, проверить, как работает система ответов на сообщения и их принятие. В дальнейшем следите, как доставляются письма. Можно не заметить проблем с получением и продолжить рассылки. А почтовый сервис увидит, что вы не исправляете ошибки, и будет блокировать все исходящие.
Проблемы также возникают из-за ключевых параметров (DKIM- и SPF-подписки), которые мешают правильно выполнить массовую рассылку. Платформа «Mail.ru для бизнеса» помогает настроить их, а также выделяет IP, чтобы не попасть под спам-фильтры.
Сообщения от SMTP — что это?
Почтовые сервисы используют единый протокол для отправки и доставления писем — SMTP. Он помогает серверам общаться друг с другом и передавать данные о письмах. В случае возникновения неисправности протокол сообщает отправителю ее код. Например, «SMTP error» означает, что произошла критическая ошибка, а код класса «3xx» — что для отправки потребуются дополнительные действия. Во втором случае проблема, скорее всего, решится, но чуть позже. Отправителю нужно только проверить настройки.
Самые опасные и сложные ошибки — класса «4хх» и «5хх». Расскажем на примерах.
Разбор SMTP-ошибок и советы по исправлению
Ошибка 421
Это значит, что сервер недоступен. Возможно, параметры протокола SMTP заданы неверно или блокируется трафик. Необходимо посмотреть настройки:
Код 451 — проблемы с обработкой
Протокол не будет отправлять письма, если превышен их лимит. Проверьте разрешенное количество сообщений в доменной почте. На сервере также стоит задать новый лимит — не на общее число сообщений, а на количество писем по одному адресу. Также стоит проверить MX-записи — они определяют сервер получателя. Подтвердите нужные разрешения и поправьте логи.
Нехватка места на сервере
Для отправки сообщений расходуется место для хранения. Когда оно заканчивается, SMTP присылает ошибку 452. Увеличьте объем серверного пространства или очистите его от ненужных файлов.
Адресат недоступен, ошибка 550
Проблемы со стороны получателя рассылки. Возможно, допущена ошибка в указании email-адреса или сервер получателя не работает. Сообщите об этом адресату, но проверьте и свои настройки. Возможно, на вашем ПК работает вирусная программа, которая массово рассылает письма с вашего ящика. Или провайдер установил лимит на отправление. Проверьте ПК на вирусы и свяжитесь с провайдером.
Проблемы с получением писем
Код 571 — продолжение ошибки 550. Спам-фильтры или антивирус мог заблокировать IP отправителя. Или он не получил разрешение на отправку писем через сервер-посредник, с которым работает сервер получателя. Справиться с этим может администратор сети и этого сервера.
Проблемы с настройкой домена
Подтверждение домена и проблема со статусом
Иногда после выполнения всех действий для подтверждения домена могут возникнуть ошибки. Все сделано верно, но статус не меняется, и домен не подключается. Нужно проверить способ подтверждения — верно ли указаны все настройки. Смотрим код страницы, куда был добавлен метатег, или проверяем, чтобы страница открывалась (подтверждение через HTML). Для проверки способа DNS потребуется несколько дней, однако сторонние сервисы помогут получить нужную информацию быстрее (например, Digwebinterface).
Почта перестала функционировать после передачи управления
Домен делегирует управление на подключенный DNS-сервер. Если почта не работает, необходимо убедиться в корректности MХ-записей.
Как еще проверить функциональность почтового сервера?
Тестовый вариант с отправлением писем на личные ящики важен, но не всегда может определить проблему. Список ошибок при подключении доменной почты довольно большой. Часть из них можно решить самостоятельно, а с некоторыми справятся только эксперты. Но если что-то работает не так, нужно определиться, в чем заключается проблема.
Поддельные электронные письма: проблема, которая может коснуться каждого
Электронная почта появилась так давно, что в сознании закрепилась как неотрывная часть интернета. Появление других способов общения — мессенджеров, социальных сетей — не сильно снизило востребованность старой доброй собачки @. Но задумывались ли вы, что электронная почта — далеко не такой надёжный способ общения, каким кажется? Ведь подделать отправителя — дело довольно простое, об этом регулярно, раз в пару лет, выходят статьи и инструкции.
Отправителя письма можно подделать
Вот эти две свежие статьи на Geektimes сподвигнули меня высказаться о наболевшей проблеме. С неё сталкивался и я, когда настраивал VPS с почтовым сервером Exim:
Автор первой статьи истерично реагирует на обнаруженную «особенность» отправки писем и демонстрирует незнание почтовых протоколов, вторая содержит больше технических подробностей и даёт пищу для размышлений. Вдогонку ранняя статья:
Суть в том, что можно подделать отправителя имейла и получивший письмо может ничего не заподозрить. В поле «от:» письма можно вписать что угодно, как и в случае с настоящей почтой. Прокатывает только при некоторых условиях, но их достаточно, чтобы получить, например, письмо от известного зелёного банка с просьбой ввести свои данные на постороннем сайте.
Photo credit: mattwi1s0n / CC BY
Почему же нельзя проверять подлинность отправителя до того, как письмо увидит пользователь? Вот комментарий с Гиктаймса, проливающий свет на проблему:
… Защита от подделки писем должна происходить с двух сторон: владельца сервиса и получателя письма (в большинстве случаев это почтовый провайдер, например Mail.ru).
К сожалению, владельцы сервисов не очень хотят защищать пользователей от отправки поддельных писем от имени этого сервиса, что и описывалось в статье по ссылке.
Отдельная проблема — почтовые сервисы. Они должны проверять письма на подделку, но не всегда это делают (по разным причинам) или делают неправильно. Например, есть забавная уязвимость в Yahoo, которая позволяет обойти проверку DMARC и SPF и подделать письмо от абсолютно правильно настроенного сервиса. …
И дальше ведётся обсуждение: https://geektimes.ru/post/291929/#comment_10250927. Из него становится ясен масштаб беды. Дело неприятное и парадоксальное. Либо почтовые службы начнут проверять подлинность писем и отбрасывать с поддельным полем «от», но тогда перестанут приходить всякие рассылки и оповещения с некорректно настроенных серверов, либо пропускать письма с несоответствиями в заголовках и обрабатывать их различными антиспам-фильтрами в надежде, что в ящик пользователю попадёт только «правильная» корреспонденция.
Знающие люди могут поправить меня: получатель всегда может посмотреть исходник письма, по ним подлинность определяется на раз-два.
Вот только когда вы последний раз смотрели на хедеры письма? В веб-интерфейсах почты это сделать можно, но нужно понимать, что это вообще такое и зачем нужно. В школе на уроках информатики об этом не расскажут, в ВУЗах на не программно-инженерных специальностях — тоже. Так с чего бы среднеокруглённому сотруднику офиса знать, как проверять имейлы на подлинность отправителя?
Проверяем подлинность сами
Так как почтовые серверы никто настраивать не хочет, придётся научиться самим проверять подлинность особо важных писем. Расскажу, как это делать в трёх популярных почтовых сервисах. Способ не гарантирует 100% точность, зато относительно прост.
Для начала откройте само письмо, в подлинности отправителя которого вы не уверены. Затем нужно открыть исходный текст письма.
Почта от Гугла GMail: меню письма — «Показать оригинал».
Yandex: кнопка меню с тремя точками — «Свойства письма».
Mail.ru: кнопка меню справа от заголовка письма — пункт «Служебные заголовки».
Откроется простыня (ПРОСТЫНИЩЕ!) текста, в котором нужно найти три строчки (можно поиском по странице, нажав Ctrl+F, они будут в начале текста):
Если адреса первых двух полей совпадают, скорее всего, письмо не подделка.
Третий служебный заголовок письма «Reply-To» вставляется не всегда. Мошенниками он применяется для более хитрой схемы. Допустим, приходит такое письмо начальника подчинённому:
Чтобы ответ одураченного сотрудника ушёл не к настоящему боссу на boss@company.com, а на поддельный boss-company.com@drzlo.com, пригодится поле «Reply-To». Нажав на «Ответить», в окне ответа подставится адрес, для усыпления бдительности похожий на настоящий.
Это, конечно, очень примитивный пример и теоретически можно другими способами подделать имейлы. Сличая пару служебных заголовков можно защититься от самых распространённых методов, если нужно больше знаний — читайте стандарт RFC 5321 — Протокол SMTP.
Когда всё починят?
Боюсь, не в ближайшее время. Парочка статей, вышедших на популярном ресурсе, да моя скромная заметка — капля в информационное море. Как ни парадоксально, но Яндекс, Майл.ру и прочие сервисы не могут просто так взять и включить строгую проверку отправителя письма, потому что тогда перестанут приниматься письма с некорректно настроенных серверов.
Хотя есть один простой способ и принять, и пометить подозрительные письма — просто в начало темы ставить метку [UNTRUSTED] или [ОТПРАВИТЕЛЬ НЕ ПОДТВЕРЖДЁН]. Письмо пришло? Да! Почему пометка появилась? Да потому то отправляющие письма сервера не работают по стандартам. Неважно, открыто ли письмо в веб-интерфейсе почты или в Outlook/The Bat/прочей программе, пометка о не удостоверенном отправителе будет видна. Вот почему этого не сделали давно — мне сие не ведомо.
Почему письмо не проходит SPF-проверку в Gmail?
Задавайте, а мы ответим на него в блоге.
Вопрос
Почему письмо не проходит SPF-проверку в Google? SPF-запись у нас настроена и опубликована, но в постмастере видим такое:
DMARC и DKIM проходят проверку, а SPF нет
Ответ
Небольшое отступление, для тех, кто не понимает, о чём речь. SPF — это запись, которую отправитель добавляет в DNS-зону домена. В этой записи находится информация, кому мы доверяем отправку своей почты — например, сервису рассылок. Если рассылка с нашего домена будет идти через сервис, которого нет в SPF-записи, почтовая служба (тот же Gmail) её заблокирует.
Теперь отвечу на вопрос.
Проблема на скриншоте выше (на самом деле никакой проблемы нет) возникает при отправке писем через сторонних отправителей, например, через сервисы рассылок.
Любое email-сообщение имеет два технических заголовка: «From» и «Return-path». Заголовок «From» отображается в почтовике и указывает, с какого адреса пришло письмо. Например, у «Вечерней Медузы» это daily@meduza.io, у Litmus — hello@email.litmus.com.
На адрес из заголовка «Return-path» приходят отчёты о недоставке почты. Такое случается, например, когда ящик не существует либо письмо заблокировали спам-фильтры. Часто при отправке письма через сервис рассылок домены «From» и «Return-path» не совпадают. Во «From» указан домен пользователя, а в «Return-path» — email сервиса рассылок, который отвечает за своевременную обработку отчётов о недоставке.
Почта — диагностика и устранение ошибок
451 domain.ru prohibited. Disk quota exceeded
Сообщение означает, что дисковое пространство, выделенное для домена получателя, исчерпано.
Необходимо повторить отправку через некоторое время. Как правило, почтовый сервер предпринимает повторную попытку автоматически.
Для того чтобы возобновить прием почты, вы можете:
Увеличить квоту отдельного ящика можно в разделе панели управления Почта → Ваш домен → Ваш ящик.
451 Please try another server
Сообщение означает, что требуется повторить попытку подключения к другому принимающему серверу RU-CENTER. Если в результате нескольких попыток отправка сообщений заканчивается неудачно, необходимо скорректировать настройки почтового сервера отправителя:
nslookup relay05.nicmail.ru
Non-authoritative answer:
Name: relay05.nicmail.ru
Address: 194.85.88.236
Для этого IP-адреса существует PTR-запись в обратной зоне со значением relay05.nicmail.ru, т.е. совпадающая с именем сервера.
nslookup 194.85.88.236
Name: relay05.nicmail.ru
Address: 194.85.88.236
452 message sending quota exceeded, try later
Сообщение означает, что для почтового ящика достигнут лимит на отправку сообщений (50 писем в 15 минут). Возможность отправки писем будет восстановлена автоматически в течение 10 минут.
476 connections from your host are denied
Сообщение означает, что подключение с вашего IP-адреса к почтовому серверу хостинга временно заблокировано. Это происходит в результате множественных ошибок при работе с почтовым сервером:
Блокировка снимается автоматически через 15 минут. Для устранения проблемы рекомендуем проверить корректность настроек почтовых клиентов. Если проблема сохранится, сообщите о ней в службу технической поддержки, написав на адрес support@nic.ru и указав в письме
550 Your message was identified as SPAM
Сообщение означает, что входящее письмо было идентифицировано как спам на основе анализа его содержимого.
Попробуйте изменить формулировку письма и повторить отправку. Если проблема сохранится, обратитесь, пожалуйста, к получателю с помощью других средств связи с просьбой добавить ваш домен в белый список.
Если у вас нет контактных данных администратора домена получателя, воспользуйтесь сервисом Whois.
Вы можете добавить домен отправителя в белый список, тогда почта с данного домена не будет проверяться спам-фильтром. Чтобы добавить домен example.net в белый список, необходимо:
550 mailbox@domain.ru prohibited. We do not relay
Сообщение означает, что адрес mailbox@domain.ru не существует в почтовой системе хостинга RU-CENTER. Проверьте правильность написания адреса и повторите отправку.
591 mailbox@domain.ru You must authenticate first
Сообщение означает, что в почтовом клиенте не настроена авторизация на сервере исходящей почты ( SMTP ) mail.nic.ru по имени ящика и паролю (аналогично серверу входящей почты).
Рекомендуем проверить корректность настроек почтового клиента. Например, если вы используете Outlook, убедитесь, что в настройках учетной записи для сервера исходящей почты стоит галочка напротив параметра SMTP-серверу требуется проверка подлинности и Аналогично серверу для входящей почты.
550 Sender domain does not match hosting account
Сообщение означает, что доменная часть адреса отправителя в заголовке «FROM» или в поле «MAIL FROM» конверта письма пустая или содержит домен, не добавленный на вашу услугу хостинга в качестве имени почтового домена или его синонима.
Рекомендуется проверить настройки почтового клиента или иного ПО, отправляющего почту, и указать адрес отправителя в домене, добавленном на ваш хостинг.
550 Incorrect header syntax in From field
Сообщение означает, что в письме поле «From» с адресом отправителя содержит информацию, которая не соответствует требованиям rfc5321 и rfc5322.
В частности, если в поле From в дополнение к адресу электронной почты указывается имя пользователя, оно должно быть заключено в кавычки:
From: «User Name»
Рекомендуем проверить настройки почтового клиента или иного ПО, отправляющего почту, проверить текст, указанный в качестве имени отправителя, заключить его в кавычки. В некоторых почтовых клиентах использование кавычек и спецсимволов внутри имени пользователя, например, «Иван Иванов, ООО «Ромашка»» может приводить к ошибке, в этом случае кавычки или спецсимволы рекомендуется удалить, а также рассмотреть возможность обновления почтового клиента.