Технічні та адміністративні вимоги до надсилання електронних повідомлень на Mail.Ru

Дані вимоги розроблено з урахуванням стандартів, розроблених і прийнятих учасниками глобальних робочих груп з протидії спаму, шахрайству та іншим формам електронних зловживань.
Невідповідність вимогам може призвести до часткової або повної недоставки вашої електронної пошти.


Технічні вимоги

  • вся електронна пошта повинна відповідати стандартам RFC (наприклад, SMTP 5321; MIME 2045, 2046, 2047, 20482049);
  • приналежність до масової розсилки повинна бути вказана в листах у заголовку Precedence: bulk;
  • усі поштові сервери, що здійснюють підключення до серверів Mail.Ru, повинні мати валідні (що відповідають дійсності), осмислені, не автоматично згенеровані зворотні DNS записи (rDNS, PTR-записи). Контактні дані по IP-адресам в WHOIS повинні бути актуальними  та доступними.

    Приклади rDNS:
           Правильна rDNS: mail.domain.com 
           Згенерована неправильна rDNS: 231.2.53.243.domain.isp.com

  • усі поштові сервери, що підключаються до поштових серверів Mail.Ru, повинні бути відповідно захищені від неавторизованого або анонімного використання. Переконайтеся, що ваш сервер не є відкритим проксі-сервером або відкритим релеєм.
  • переконайтеся, що всі веб-форми на ваших сайтах безпечні;
  • якщо ви використовуєте скрипти, що відправляють повідомлення електронної пошти з веб-форми, переконайтеся, що вони не можуть бути використані для надсилання спаму;
  • прямі з'єднання на поштові MX-сервери Mail.Ru з динамічних IP-адрес та адрес домашніх мереж не дозволені;
  • не дозволяється жорстко ставити в конфігураційних файлах серверів, що надсилають, MX-записи Mail.Ru;
  • при використанні HTML у ваших повідомленнях, переконайтеся що дотримано валідної  структури HTML-документу. Заборонено використовувати потенційно небезпечні об'єкти, такі як ActiveX, JavaScript, VBScript, Java-аплети, Frames та IFrames, що підключаються із зовнішніх сайтів CSS, Meta Refresh тощо (використання таких елементів може привести до блокування ваших розсилок);
  • спроба використовувати сторонні сервіси (редиректори, «скорочувачі посилань») для приховування інформації про справжню цільову сторінку будь-якого з веб-посилань у листі може привести до того, що розсилку буде заблоковано;
  • неприпустимо використовувати в листах в якості посилань IP-адрес і доменних імен в кодуванні URL-encode.

Адміністративні вимоги

  • розсилка повинна здійснюватися виключно на очевидну та пряму вимогу або за згодою одержувача (opt-in);
  • всі розсилки, що надсилаються за підпискою, повинні мати в тексті кожного повідомлення валідну не електронну контактну інформацію про організацію, що здійснює розсилку, включаючи телефонний номер і фізичну адресу;
  • масові розсилки повинні мати простий і очевидний механізм відписки. Процес відписки не повинен вимагати від користувача складних дій, таких як введення або відновлення пароля, реєстрація тощо. Ми рекомендуємо в якості механізму відписки додавати в кожен лист добре помітне посилання з можливістю відписатися одним переходом за ним. Користувачі не повинні авторизуватися на сайті, щоб відписатися від розсилки;
  • розсильники не повинні здійснювати дії з приховування, підробки або спотворення відправника повідомлення та джерела надсилання;
  • інформація про підписку, включаючи те, як було отримано електронну адресу одержувача, дата й час передплати, а також IP-адреса, звідки користувач здійснив підписку, повинні бути доступні за запитом користувача;
  • у розсилках необхідно вказати інформацію про те, звідки було взято адресу користувача і його згоду на отримання розсилки. Наприклад, «Ви отримали цього листа, оскільки підписалися на розсилку на нашому сайті…»;
  • сервіси, які здійснюють розсилки на основі підписки, повинні безумовно видаляти з бази підписаних або вживати заходів щодо припинення розсилок на адреси, які генерують помилку протоколу SMTP: 550 user not found (відстеження валідності бази одержувачів - необхідна умова для підтримання позитивної репутації розсильників).

Скарги користувачів, надсилання на неіснуючі адреси одержувачів (зокрема та, що існували раніше, але були видалені), неможливість отримання відправником звітів про недоставку, потрапляння повідомлень у спам-пастки Mail.Ru впливають на репутацію відправника. Будь-якому відправникові з негативною репутаційною характеристикою може бути заблоковано можливість доставки повідомлень на Mail.Ru. Серія порушень від одного розсильника може привести до часткового або повного блокування його IP-адрес в Mail.Ru.

Рекомендуємо вам почати стежити на своїми розсилками в режимі реального часу, зареєструвавши свій домен на Postmaster@Mail.Ru — це сервіс, створений спеціально для відправників пошти, які хочуть поліпшити не тільки доставку, але й якість своїх розсилок.

Was this information helpful?