Триколор 

Настройка электронной почты (без писем в спаме). Нежелательная почта и открытые ретрансляции. Настройка отправки писем без их попадания в спам

Примеры писем:

550 5.7.1 This message was not accepted due to domain owner DMARC policy (RFC 7489) https://help.mail.ru/mail-help/postmaster/dmarc

550-5.7.1 Unauthenticated email from mail.ru is not accepted due to domain"s 550-5.7.1 DMARC policy. Please contact administrator of mail.ru domain if this 550-5.7.1 was a legitimate mail. Please visit 550-5.7.1 https://support.google.com/mail/answer/2451690 to learn about DMARC

550 5.7.1 Email rejected per DMARC policy for ...

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

DMARC — это протокол защиты от спама и от несанкционированной рассылки почты от имени домена, основанный на существующих механизмах DKIM и SPF . Официальный сайт: dmarc.org .

Если вы получаете подобные приведённым выше сообщения, скорее всего, почта с сайта у вас отправляется от имени почтового ящика на базе @mail.ru , @bk.ru , @list.ru или @inbox.ru . Mail.Ru не принимает сообщения, отправленные через phpmail, если в почтовых заголовках числится ящик, принадлежащий mail.ru. Такие сообщения, согласно внедрённой Mail.Ru политике DMARC , отклоняются.

Как решить проблему

Решить проблему можно двумя способами:

Способ 1: изменить ящик, с которого отправляются сообщения

Обычно e-mail, от имени которого рассылаются почтовые сообщения, прописывается в административной части CMS. Также его можно изменить напрямую в скрипте, рассылающем сообщения (поле «From»).

Необходимо, чтобы сообщения рассылались с ящика на базе вашего доменного имени, например «[email protected]» , где domain.ru — ваш домен. .

Также, почтовый ящик необходимо изменить в файле php.ini :

Изменение ящика в php.ini

  1. 1 войдите в панель управления хостингом и откройте на редактирование файл php.ini : ;
  2. 2

    найдите строку вида:

    sendmail_path = "/usr/sbin/sendmail -t -i -f [email protected]"

    В данной строке вместо «[email protected]» укажите почтовый ящик, не относящийся к доменам @mail.ru , @bk.ru , @list.ru и @inbox.ru .
    Желательно указать почтовый ящик на вашем домене, например, «[email protected]» , где domain.ru — ваш домен.

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

Способ 2: использовать SMTP-авторизацию

Вы можете рассылать сообщения от имени вашего почтового ящика на базе Mail.Ru, настроив SMTP-авторизацию. В этом случае все сообщения через ваш сайт будут отправлять напрямую с серверов Mail.Ru.

Ошибки почтовой системы – это коды, которые присваиваются сообщениям во время получения или отказа в получении. Код ошибки позволяет выяснить причину, по которой возникла невозможность доставки почтового сообщения. Как правило, код ошибки представляет собой число, например #550 или #2001. Описание кодов ошибок приведено ниже.

Сообщения без кодов

Unroutable address

Не удалось определить сервер, на который нужно переслать почтовое сообщение. Возможные причины:

  • Не существует или не делегирован домен, на который посылается почта
  • Для домена не прописаны ни MX, ни A записи
  • MX запись указывает на несуществующее имя

User unknown

Данного почтового ящика не существует, либо почтовый адрес указан с ошибкой

Transmission in progress. Stay tuned

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

Over quota

LMTP error after end of data: 552 5.2.2 Over quota
Ошибка возникает, в случае если у получателя переполнен почтовый ящик.

Сообщения с кодами

#1005

Sender verify callout failed
Проверка отправителя письма. Ошибка может быть либо полной, как указано ниже, либо сокращённой: «Sender verify failed [#1005]». Ошибка присылается каким-либо сервером, который осуществил неудачную попытку отправить письмо нашему серверу. Наш сервер указан в строчке «… while talking to mx3.сайт.:».

The following addresses had permanent fatal errors ----- (reason: 550-Verification failed for ) ----- Transcript of session follows ----- ... while talking to mx3.сайт.: >>> MAIL From: SIZE=523 <<< 550-Verification failed for <<< 550-User unknown (200) <<< 550 Sender verify failed [#1005]. 554 5.0.0 Service unavailable

Адрес [email protected] – это адрес получателя письма, он приведён только ради полноты информации.
Адрес отправителя [email protected] не прошёл проверку, о чём и написано в сообщении.

Для каждого письма производится проверка отправителя. Для этого наш сервер пытается подсоединиться к серверу, принимающему почту для домена отправителя (в примере – example.com) и отправить письмо с адреса «<>» на адрес отправителя (в примере [email protected]). Такие письма всегда должны приниматься, потому что именно так выглядят сообщения о неудачных доставках. Если сервер отвечает, что такого ящика не существует (в примере сервер, обслуживающий домен example.com, ответил «550-User unknown (200)») или по другим причинам отвергает попытку, то письмо с адреса [email protected] не принимается.

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

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

#1004

Sorry, we don’t accept messages from the hosts without a PTR record
Ошибка возникает, когда у узла отправителя отсутствует PTR -запись.

#1007

We don’t accept dynamic ip-addresses, please use your provider’s smtp [#1007] или dynamic ip rejected [#1007]
Данная ошибка возникает у пользователей, использующих для своего подключения динамический пул адресов. Проверка осуществляется на основании IP-адреса пользователя (наличие в нём слов dial, ppp, pool, dsl, dynamic, static и другие вхождения).

#1008

Sender verify failed
В заголовке smtp-сесии mail from указан неверный обратный адрес (несуществующий домен, например).

#1009

We don’t accept dynamic ip-addresses, please use your provider’s smtp [#1009]
Данная ошибка в основном возникает у пользователей использующих DSL или DialUp подключения и отправляющих почту со своих локальных компьютеров, иными словами не использующих SMTP -сервер своего провайдера. Проверка осуществляется на основе регулярного выражения для :
^({1,3}\D+){2}({1,3}[^\d\.]*).*\.(\w|-)+\.\w{2,4}$
Если вы по какой-то причине не можете использовать SMTP -сервер вашего провайдера – напишите заявку в техническую поддержку с указанием вашего ip адреса, он будет добавлен в white-list.

#1014

Mail rejected, see http://www.spamcop.net/w3m?action=checkblock&ip=IP-адрес [#1014]
Мы используем DNS -блеклисты spamcop.net для защиты от спама. Адрес отправителя находится в блеклистах spamcop.net

#1020

Relay not permitted
Совершена попытка отправить письмо на домен, который не обслуживается нашими почтовыми серверами.

#1024

Recipient verify failed
Проверка получателя письма. Ошибка возникает, если домен обслуживается нашими серверами, но такого адреса в домене не существует.

#1025

Recipient verify callout failed
Проверка получателя письма. Ошибка возникает, если удалённый сервер отвечает, что такого получателя не существует.

#1305

You are sending too many messages
Превышен лимит по отправке писем через smtp. Для повышения лимита необходимо обратиться в службу технической поддержки.

#2002

Authentication required
Для отправки требуется пройти аутентификацию по логину и паролю.
Примеры корректной настройки почтовых клиентов можно посмотреть

Настройка отправки писем без их попадания в спам.

Вариант с отправкой писем через сторонние SMTP-серверы (Mandrill, Mailgun, Яндекс) и через личные адреса почтовых сервисов рассматривать не буду (там все очень просто, если следовать предоставляемым инструкциям по установке) - рассмотрю лишь вариант, что у нас есть свой сервер, на котором установлен соответственно почтовый сервер, например exim (как у большинства хостеров).

Нам потребуется доступ к редактированию DNS-записей и минимальное владение консолью для настройки DKIM (если есть ISPmanager - и этот пункт становится неактуальным). Всего потребуется настроить (добавить) 4 новые записи в DNS-записи вашего домена: PTR , SPF , DKIM и DMARC .

  • PTR - так называемая "обратная" DNS-запись. Должна быть обязательно, поскольку очень большое число почтовых сервисов к ее некорректному указанию нетерпимо. По-идее она должна устанавливаться вашим хостером, например DigitalOcean делает это автоматически. - но есть вариант и ее ручной настройки.
  • SPF - запись, в которой указано, что вашему серверу разрешено отправлять письма с этого домена и IP. Нет этой записи - попадание в спам практически гарантировано. Установка очень простая - исчерпывающую информацию с примерами по настройке можно получить на (информация в зеленой табличке), либо на .
  • DKIM - электронная подпись ваших писем. При наличии двух предыдущих записей - придает вашему домену и письма с него "вес", благодаря чему тот же Яндекс, например, помечает письма приятной зеленой галочкой.

Настройка этой подписи, пожалуй, самая сложная - как последствие, у 90% сайтов ее нет, но крайне рекомендуется. Очень просто настроить ее в ISPmanager: включаете поддержку DKIM на вкладке возможностей, в редактировании почтового домена ставите галочку DKIM и забираете уже готовую запись в свойствах домена (NS). Если ISPmanager нет, советую воспользоваться этой, достаточно простой статьей: .

  • DMARC - стандарт совершенно новый, но уже активно почтовыми сервисами внедряется и в этом году уже 100%-ый must have. Настройка самая простая из всех выше перечисленных записей, вам нужно лишь добавить один из примеров, указанных на этой странице снизу: - советую второй.
Сервер у вас теперь настроен и если все сделано верно - ни одно письмо в спам уже не уйдет. Для примера, подтверждающий скриншот с почтового офиса mail.ru (аналогичная ситуация с полным отсутствием определения писем как спам и по Яндексу):

Настройка сборщика возвратной почты.

В XenForo есть совершенно потрясающий механизм, который практически никем не используется - сборщик возвратной почты (bounce email). Думаю каждый встречался с ситуацией, что после совершения массовой рассылки на почтовый ящик приходит большое число писем следующего вида:

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

***@rambler.ru
SMTP error from remote mail server after RCPT TO:<***@rambler.ru>:
host imx1.rambler.ru : 540 5.7.1 <***@rambler.ru>:
Recipient address rejected: Your emails has been returned because the intented recipient"s email account has been suspended. The account must be re-activated to receive incoming messages.

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

С этим нужно бороться, потому что даже на моем форуме, где эта система работает уже не первую рассылку, "возвращенных" писем очень много, в сравнении с числом пользователей:

  • Для начала, создаем почтовый адрес, на который будем посылать возвращенные письма (ящик системный и ни для каких других целей использоваться не должен) - например , где google.com - ваш домен.
  • Заходим в раздел админки Настройки - Настройки электронной почты . В поле адрес для возврата писем указываем созданный вами почтовый ящик. Ставим галочку автоматической обработки недоставленных писем и указываем данные для захода на ваш служебный почтовый ящик, которые вы создали ранее: адрес (в случае собственного SMTP-сервера - свой и указывайте), логин (адрес, который вы создали) и пароль от ящика. Приведу пример своих настроек - у меня бизнес-почта от Mail.ru - следовательно к их серверу для получения почты со служебного ящика я и подключаюсь

В принципе, это вся настройка. Форум автоматически с определенными интервалами будет заходить на указанный вами служебный почтовый ящик, скачивать копии возвращенных писем, которые на него поступили и удалять их оттуда. В разделе Инструменты - Журнал отказов в доставке писем вы эту статистику сможете просмотреть. Особо подчеркиваю, что ни для каких других целей этот ящик использовать нельзя, а то рискуете получить несколько достаточно забавных багов в логах админки.

Согласно заданным вами условиям, при возврате, к примеру, 3 писем с одного адреса, пользователь будет отправляться на автоматическую реактивацию - ему будет предложено указать актуальный адрес электронной почты и заново активировать аккаунт. Какое либо ваше участие при этом не требуется - пользователи будут сами указывать свои актуальные адреса электронной почты, а следовательно проблема уйдет со временем. А при рассылках, пользователей с некорректным адресом электронной почты можно будет исключить из нее - тем самым избежав возможного попадания в спам листы.

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

Для некоторого упрощения части задач, описанных выше, можно использовать либо - что вам больше нравится. Я использую первый - но выбор полностью за вами. Добавление ваших доменов туда даст удобные, неограниченные по размеру почтовые ящики с уже встроенными спам-фильтрами + некоторое упрощение настройки сервера (часть записей будет предоставлена автоматически (за исключением DKIM, которую для отправки почты со своего сервера надо генерировать вручную так или иначе)).

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

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

Проблема с отправкой сообщений с сайта

Пожалуйста, убедитесь, что вы точно выполняете все советы статьи .

Самое важное:

1) Обратный адрес письма должен быть зарегистрированным ящиком на нашем хостинге!
2) Массовые рассылки запрещены, по умолчанию, с сайта можно отправить до 500 писем в день.
3) Письмо должно соответствовать почтовым стандартам. Ваш скрипт самостоятельно формирует письмо и если оно получилось не очень качественным, оно будет принято нашим сервером, но его доставка не произойдет, т.к. его задержат фильтры нашей системы или у получателя.

Проблема с отправкой сообщений от человека

Ситуация 1

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

  • Письмо не поступало на наш SMTP сервер: ваша почтовая программа не отправила сообщение. Источником или решением проблем может быть следующее -
    • Настройки учетной записи вашей почтовой программы, точнее - настройки SMTP сервера. Помните, что SMTP сервер требует авторизации, тем же логином и паролем, что и сервер входящей почты.
    • Антивирус, система безопасности, прокси-сервер.
  • Письмо поступило в систему, но было отклонено, т.к. не содержало правильного обратного адреса. Обратный адрес письма должен точно соответствовать либо адресу названия ящика, либо одному из псевдонимов.

Ситуация 2

Письмо присутствует в списке сообщений в очереди.
Необходимо открыть «статистика доставки почты», «SMTP доставка».

Ситуация 2.1

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

Ситуация 2.1.1

Блок «лог доставки» оканчивается сообщением 250 OK или любым другим сообщением, которое начинается с кода 250 (кроме последней строки «Connection closed normally» - её учитывать не нужно).
Это означает, что следующий в цепочке доставки почтовый сервер принял письмо и подтвердил факт получения сообщения. Все последующие вопросы о судьбе сообщения необходимо направлять администратору этого почтового сервера. Информация из блока «лог доставки», одновременно с датой и временем, поможет администратору понять судьбу сообщения и при необходимости устранить проблему.

Ситуация 2.1.2

Блок «лог доставки» оканчивается сообщением, которое начинается кодом, отличным от 250, либо сопровождается сообщением «Processing of job XXXXXXX incomplete or failed».
Это означает, что наш почтовый сервер не смог доставить сообщение адресату. При этом вы должны получить сообщение о недоставке почтового сообщения («возврат»). Дополнительная информация доступна из лога SMTP доставки, которую вы сейчас просматриваете.

  • Сообщение может быть отклонено сервером получателя из-за некорректной фильтрации спама. Ответственность за возврат письма лежит на администраторе сервера, почтовый сервер которого принял решение о том, что письмо является спамом. Спам с адресов нашего почтового сервера не рассылается, поэтому решение об отклонении письма на основании IP адреса или иных формальных признаков является заведомо ошибочным.
    Расследовать данную проблему с нашей стороны нет смысла, т.к. цитируется ответ принимающего сервера. Необходимо обратиться к администратору принимающего сервера.
    Примеры сообщений о том, что почтовый сервер адресата отклонил сообщение по подозрению в спаме:
    • 591 your host is blacklisted
    • 450 5.7.1 ... Mail from a.b.c.d refused - see http://spamcop.net ...
    • 553 5.3.0 Spam blocked see: http://spamcop.net/ ...
    • 550 5.7.0 Your server IP address is in the SpamCop database, bye
    • 554 Service unavailable; Sender address blocked using list.dsbl.org
    • 550-Message rejected because … (…)
    • 591 your host is blacklisted, see ...
    • Сообщение с кодом 4xx или 5xx, упоминающее слова spam, blocked, Spamcop, Spamhaus, RBL, SBL, XBL, SPEWS, policy analysis, denied, или аналогичные.
  • Сообщение может быть отклонено сервером получателя в том случае, если адресат на сервере отсутствует, т.е. по причине ошибки адреса.
    Уточните адрес до символа @.
    Расследовать данную проблему с нашей стороны нет смысла, т.к. цитируется ответ принимающего сервера. Если вы считаете, что адрес точен, то необходимо обратиться к администратору принимающего сервера для уточнения причины отказа принять письмо.
    Примеры сообщений об отсутствующем адресе:
    • 550 , Recipient unknown
    • 553 We do not relay without RFC2554 authentication
    • 550 Message was not accepted -- invalid mailbox
    • 554 … This account has been disabled or discontinued
  • Сообщение об ошибке в почтовом адресе после символа @. Уточните почтовый адрес, а также то, что домен получателя активен и работает.

    Примеры сообщения об ошибке после @:
    • Temporary error XXX (temporary MX resolution error) resolving "aaa.bb"
  • Техническая ошибка при отправке сообщения. Вы можете попытаться отправить письмо повторно, либо уточнить у получателя, нормально ли работает его сервер электронной почты.
    Вы можете обратиться к службе поддержки с просьбой прокомментировать ситуацию точнее.
    Примеры сообщений о технических ошибках:
    • Error connecting to primary server "a.b.c.d"
    • Error connecting to alternate server " a.b.c.d"

Ситуация 2.2

Письмо отсутствует в списке SMTP доставки. Обратитесь в службу поддержки.

Проблема с получением сообщений

Вам необходимо зайти в личный кабинет, выбрать «статистика доставки почты», «очередь сообщений» для нужного вам ящика.
ВАЖНО: расследовать проблему такого вида можно только для сообщений, которые были доставлены в ящик непосредственно, без участия списка рассылки либо спам-фильтра. Если ваш ящик получает сообщение косвенным образом (через список рассылки), вам необходимо расследовать проблему для ящика, который является основным ящиком списка рассылки. Если включен спам-фильтр - его необходимо выключить.

Ситуация 3

Сообщение присутствует в списке.
Это означает, что сообщение было принято сервером и размещено в ваш почтовый ящик. Проблемы с получением такого письма связаны с вашей системой либо её настройками.

  • Проверьте настройки системы фильтрации спама («полный список функций», «фильтрация нежелательных сообщений»). Если спам-фильтр включен, письмо могло быть перемещено либо отклонено (в зависимости от ваших настроек). Письмо также могло быть уничтожено вне зависимости от настроек, если содержало вирус.
    Следует попробовать отключить фильтрацию почты либо проверить все ящики, куда могло быть перемещено письмо, если выбран такой режим.
  • Ваша почтовая система может вообще не принимать почту с нашего сервера. Для уточнения этого случая посмотрите содержимое вашего почтового ящика через веб-доступ к почте, см. ссылку напротив нужного ящика на странице «пароли на ресурсы» личного кабинета.
  • Иногда почтовая система компьютера или организации принимает сообщение, а затем по какой-то причине удаляет его с сервера, никуда далее не передав и не сохранив. Вам необходимо обратиться к администратору вашей почтовой системы для расследования проблем такого типа.
    Расследовать данную проблему с нашей стороны нет смысла, т.к. письмо было размещено в ваш ящик и могло быть удалено из него только с помощью команд с вашего компьютера с помощью протокола POP3 или IMAP.

Ситуация 4

Сообщение отсутствует в списке.
Это означает, что наш почтовый сервер не принимал сообщение.
Расследовать данную проблему с нашей стороны нет смысла. Это представляет собой проблему нашей почтовой системы только в том случае, если есть доказательства того, что сообщение было доставлено на наш сервер. Доказательством служит кусок лога SMTP клиента отправляющего сервера (случай, зеркально аналогичный ситуации 2.2.1 выше). Если такого доказательства нет, значит, расследовать данный случай недоставки должен администратор почтового сервера отправляющей стороны.

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

  • Убедитесь, что домен активен (DELEGATED), что DNS сервера соответствуют DNS серверам сайт (ns1.сайт, ns2.сайт).
    • Если домен обслуживается другими DNS серверами, убедитесь, что MX запись домена показывает на наш почтовый сервер (если не сообщено иначе, это должен быть mail.сайт).
    • Если домен обслуживается нашими DNS серверами, зайдите в «полный список функций», «редактор DNS зон», выберите домен, убедитесь, что стоит галка «1Gb..
  • Убедитесь, что домен зарегистрирован более 3х дней назад.