• Главная
  • Карта сайта
Не найдено

Як налаштувати і правильно прописати SFP, DKIM і DMARC для домену - інструкція (доповнено 9.12.2016)

Gmail зараз нещадно ріже будь-яку пошту, яка здається йому підозрілою, в спам. Гаразд ще коли розсилки не доходили, але тут в спам стали потрапляти одноразові адресні листи. Вирішуємо цю проблему ...

Google прямо вказує на 3 настройки для відправника, за допомогою яких він може підтвердити що він не спамер а чесний власник домену з якого надійшов лист Google прямо вказує на 3 настройки для відправника, за допомогою яких він може підтвердити що він не спамер а чесний власник домену з якого надійшов лист ... Три настройки - це SPF, DKIM і DMARC.

Розберемо їх по порядку:

  1. SPF - Sender Policy Framework. Це посто запис в DNS'ке домену, в якій ми прописуємо які виходять IP-адреси проходять через наш домен повідомлень вважати коректними, а які спамом ... Нам просто потрібно вказати там свої IPшкі, які потрібно вважати коректними, і вказати, що інші IPшкі повідомлень, які маскуються під наш домен і у яких навіть вихідний мейл може мати назву нашого домену - слід вважати спамом.
    Поштовий сервер приймає повідомлення від якоїсь домену, і звіряється з його DNS'кой на предмет, чи відповідає цьому домену IPшка відправника. Після перевірки вирішує, доставляти чи повідомлення одержувачу, або зарізати повідомлення як spam.
    З SPF все простіше простого. Просто беремо і прописуємо все що гугл хоче в DNS. Створюємо наступну TXT-запис:
    v = spf1 a mx include: mydomain.com ~ all
    До речі, деякі DNS-редактори мають user-friendly інтерфейс, і вже мають поле SPF, в якому можна вказати цю ж саму запис: v = spf1 a mx include: mydomain.com ~ all. Але дублювати її не треба. SPF це той же TXT, і немає необхідності прописувати одну і ту ж запис двічі.
    Вступ параметри:
    v - це версія SPF, в даному випадку spf1 означає першу версію.
    a і mx вказують що IPшкі перчісленние в A і MX-записах домену автоматично вважати хорошими.
    include: ... перераховуємо IPшкі і хости які сервер одержувача повинен вважати хорошими.
    -all або ~ all або? all - визначає, що сервер одержувача повинен робити з листом.
    ? all (безвідмовна доставка) означає що бажано доставляти всі листи домену відправлені з будь-IPшкі незалежно ні від чого.
    -all (жорсткий відмова) означає що сервер одержувача повинен однозначно різати всі листи від IPшек, які не відповідають домену як спам. (Але тут можуть виникнути проблеми з автоматичним форвардного поштових повідомлень. Наприклад, хтось відправляє лист на вашу поштову адресу, з якого лист негайно форвард далі, наприклад на ваш @ gmail'овскій ящик. -All по ідеї повинен рубати такі повідомлення, але в реальності тести показали що гугл приймає такі отфорваржение повідомлення, вважаючи їх, однак, трохи підозрілими, позначаючи статус перевірки SPF'кі як softfail (Received-SPF: softfail ...)
    ~ all (м'який відмова) означає що рішення про доставку чи про зарубиваніі листи залишається на розсуд сервера. Такі листи будуть позначені на заголовку листа відміткою (Received-SPF: pass ...) при успішній перевірці, і (Received-SPF: softfail ...) при неуспішною. Рішення про відправку листа в спам або про доставку відстає за алгоритмом сортування лист на сервері одержувача. Я у себе прописав саме м'який відмова, з тильдой (~ all), оскільки я форваржу деяку свою пошту (публічні адреси, на які валить купа спаму) на свій gmail-аккаунт. Просто на моєму сервері у мене немає свого спам-фільтра, і я хочу щоб роботу із сортування спаму за мене зробив google / gmail.
  2. DKIM. Тут трохи складніше. Тут нам потрібно згенерувати електронний ключ, що складається з приватної і 1024-байтной публічної частини. Приватну частину підв'язуємо до EXIM'у на нашому сервері, а публічну, знову таки, суём в DNS.
    покроково:
    1. Йдемо кудись, і генерітся собі RSA-ключ для домену. Згенерувати ключ для DKIM'a собі можна наприклад тут: https://luxsci.com/extranet/dkim.html або тут: https://www.socketlabs.com/domainkey-dkim-generation-wizard/ або тут: http://www.port25.com/support/domainkeysdkim-wizard/ .
      (Тільки, пам'ятаємо, що він повинен бути як мінімум 1024-байтним. Гугл не зважає на ключами меншої довжини. Вважаючи їх ненадійними.)
      При генерації ключа нам потрібно вказати своє домен і якийсь ідентифікатор ключа, selector. Нехай буде key1, для цього прикладу, але він може називатися як завгодно, наприклад dkim.
    2. Публічну частину ключа прописуємо собі в DNS'ку. Створюємо дві нових TXT-записи і пишемо
      в першу:
      _domainkey. mydomain.com TXT o = ~;
      До речі, деякі генератори намагаються підсунути ще параметр t = y, але це параметр для тесту. Тест нам не потрібен, тому пишемо тільки o = ~;
      в другу:
      key1 ._domainkey. mydomain.com TXT v = DKIM1; k = rsa; p = MIGfMA0G ..... IDAQAB
      (Замість mydomain.com звичайно підставляємо ім'я свого домену, замість key1 обраний селектор, а в параметрі p = вказуємо власне публічну частину RSA-ключа.)
      Ще, важливо! , Щоб в публічному ключі не було прогалин, символів розриву рядків, табуляції і т.д .. Публічний ключ - це один рядок, який пише разом. Тестувати DKIM-запис прописану в DNS'ке можна тут http://dkimcore.org/c/keycheck (Але можливо доведеться почекати до 48 годин до поновлення DNS'ок.
    3. Приватну частину ключа зберігаємо в якийсь файлик, який записуємо в секретне місце на сервері, а в конфіги EXIM'a (exim.conf) прописуємо наступне:
      Десь на початку так:
      # DKIM
      DKIM_ENABLE = yes # якщо ми захочемо відключити DKIM в майбутньому, можна буде закомментировать цей рядок
      DKIM_DOMAIN = $ {lc: $ {domain: $ h_from:}}
      DKIM_FILE = / etc / exim / dkim / $ {lc: $ {domain: $ h_from:}} .key
      DKIM_PRIVATE_KEY = $ {if exists {DKIM_FILE} {DKIM_FILE} {0}}
      а в блоці опису транспортів пишемо якось так:
      begin transports
      remote_smtp:
      driver = smtp
      .ifdef DKIM_ENABLE
      dkim_domain = DKIM_DOMAIN
      dkim_selector = key1
      dkim_private_key = DKIM_PRIVATE_KEY
      .endif
      Домен тут підставить автоматично, замість key1 потрібно буде вказати обраний нами селектор, а файлик з приватної частиною ключа покласти за адресою, вказаною у змінній DKIM_FILE.
      Це буде щось на зразок / etc / exim / dkim / mydomain.com .key
    4. Це все. Для початку підписування - перезапускаємо EXIM: /etc/init.d/exim restart
      Ще можливо буде потрібно почекати до 48 годин для поновлення DNSок, щоб сервер одержувача побачив публічну частину ключа.
  3. DMARC. Налаштування DMARC описана тут , Але повторюватися лінь, просто створюємо парочку нових TXT-записів у себе в DNS'ках і прописуємо правила:
    _adsp._domainkey. mydomain.com TXT dkim = all
    _dmarc. mydomain.com TXT v = DMARC1; p = quarantine; adkim = s; aspf = s;
    Популярно про параметри-тегах DMARC'a - описано на http://dmarc.org/draft-dmarc-base-00-01.html#iana_dmarc_tags (Тестувати DMARC-запис можна тут: http://mxtoolbox.com/SuperTool.aspx ).
    параметри:
    • v - version (версія DMARC)
    • p - policy (політика, може бути none, quarantine або reject).
      • none - ніяких активних дій з боку приймаючої сервера не буде, крім запису в балці (або звіту до відправника, якщо у того налаштований параметр rua, в якому можна вказати мейл, на який будуть надходити відгуки від приймаючої серверів. Детально можна вивчити в доках DMARC 'a, я цей параметр не використовую, логи отримувати і читати не хочу).
      • quarantine - повідомлення буде доставлено, але позначено як спам (одержувач сам буде вивуджувати його з спаму / карантину).
      • reject - лист одержувачу не доходить, відбуватися отлуп відправнику, вказаною в поле From. (Приблизний вид відлупцювали - нижче.)
    • adkim і aspf - режим звірки (alignment mode) підписів DKIM і SPF. Останні два параметри можуть мати значення r (relaxed) або s (strict). Якщо ви використовуєте пошту в піддоменів, типу @ news.domain.com, то ставте r (збіг по організації, по головному домену). Якщо все поштові скриньки знаходяться в межах одного домену @ domain.com - ставте s (буде сувора перевірка по повній назві домену).
    • ... більше параметрів в описі на https://support.google.com/a/answer/2466563?hl=ru .
    Нам тут важливий лише один параметр, параметр p (Policy). Це дає вказівку почтовик адресата, що робити з листами, які надійшли НЕ з домену зазначеного в mydomain.com. У цього p [olicy] можливі три значення: none, quarantine або reject. Скажу лише про reject 'е (який, на перший погляд, здається найправильнішою політикою. Це типу вказівку відхиляти всі листи від @ mydomain.com в поле From, які реально надходять від іншого сервера, які не mydomain.com) ...
    Я тестував все три настройки, пересилаючи листи через @ hotmail.com на @ gmail.com. Подальший текст - мій особистий досвід, без претензії на об'єктивність. REJECT. За ідеєю reject - найправильніша настройка. Листи, які йдуть не з вашого домену, але в полях From вказують ваш домен, повинні бути відхилені. Однак, люди часто користуються форвардера. Наприклад, адресат, маючи поштову скриньку на @ hotmail.com в реальності не користуються ним, налаштовуючи редирект на свій @ gmail.com. І ось при політиці такої reject-політиці, замість благополучної доставки листа на имя@hotmail.com, ви отримаєте отлуп. Через те, що SPF-тест буде провалений, лист прийшов з IP-шки відрізняється від домену. DKIM-тест, який містить відкритий ключ, буде пройеден, але отлуп відбудеться навіть через заваленого SPF. Так відбувається, наприклад, при відправці листа на @ hotmail.com, коли адресат налаштував перенаправлення на @gmail. Виходить такий ось отлуп: Delivery Status Notification (Failure) -------------------------------------- This is an automatically generated Delivery Status Notification. Delivery to the following recipients failed. [email protected] -------------------------------------- Reporting-MTA: dns; COL004 -OMC4S7.hotmail.com Received-From-MTA: dns; EUR02-AM5-obe.outbound.protection.outlook.com Arrival-Date: Fri, 9 Dec 2016 5:34:01 -0800 Final-Recipient: Action: failed Status: 5.5.0 Diagnostic-Code: smtp; 550-5.7.1 Unauthenticated email from yourdomain.com is not accepted due to 550-5.7.1 domain's DMARC policy. Please contact the administrator of 550-5.7.1 yourdomain.com domain if this was a legitimate mail. Please visit 550-5.7.1 https://support.google.com/mail/answer/2451690 to learn about the 550 5.7.1 DMARC initiative. f16si33975676pli.56 - gsmtp NONE. Я поставив none, для гарантії того, що листи не будуть відкинуті. Однак, на мою думку, що gmail не сприймає політику none і ігнорує її. Щонайменше при пересиланні пошти з hotmail. Саме з hotmail, тому що при пересиланні через yandex все пройшло. Детально не заглиблювався, мені для мого завдання важлива саме пересилання через hotmail / outlook. Я навіть вказав параметр rua, так що мій запис виглядала наступним чином:
    v = DMARC1; p = none; adkim = s; aspf = s; rua = mailto: [email protected]
    Однак у прибуваючих звітах бачив наступне:

    <Policy_published>
    <Domain> mydomain.com </ domain>
    <Adkim> s </ adkim>
    <Aspf> s </ aspf>
    <P> reject </ p>
    <Sp> reject </ sp>
    <Pct> 100 </ pct>
    </ Policy_published>

    Тобто, очевидно, політика none не спрацював, перетворюючись в reject.
    QUARANTINE. Раптово з p = quarantine все запрацювало. Листи через hotmail проходять, і навіть не потрапляють в спам. (Але в моєму випадку мене б влаштовувало навіть якби і потрапляло в спам, я б звертав на це увагу адресата.)
    Таким чином, особисто я для себе вирішив, що найбезпечніше зробити політику quarantine (для більшої гарантії отримання листа адресатом, в разі, якщо він користується Форвардери).

Тестування за все:

  1. DKIM-запис з публічним RSA-ключем тестуємо тут: http://dkimcore.org/c/keycheck . Відмінна тулза, яка вкаже на помилки синтаксису.
    Альтернативно - тут: https://www.mail-tester.com/spf-dkim-check . Ця тулза заодно перевірить і SPF, але на помилки не вкаже.
  2. Перевірка доставки листів (тестує ВСЕ, і SPF, і DKIM і DMARC):
    https://www.port25.com/authentication-checker/ .
    Коротенько ... Щоб потестить результати по IPшке отпрпавітеля - надішліть тестовий лист на [email protected] .
  3. Ще DMARC і купу інших записів DNS: http://mxtoolbox.com/SuperTool.aspx

І ще:

Якщо щось не виходить, не переживайте. Все вийде. Налаштування всіх цих записів для недосвідченого людини - завдання не на один день. Тут проблема в тому, що оновлення DNS-записів можна очікувати до 2 діб. Поки DNS не оновиться, немає приводу нервувати про те, що щось все ще не працює. Якщо настройки правильні, то через деякий час зароблять самі собою.

Однак, навіть коли все буде налаштоване і запрацює при прямій доставці на gmail, обов'язково тестируйте доставку листа при пересиланні. Наприклад, через hotmail.com. Там легко налаштовується форвардер.

Com/a/answer/2466563?
Провайдеры:
  • 08.09.2015

    Batyevka.NET предоставляет услуги доступа к сети Интернет на территории Соломенского района г. Киева.Наша миссия —... 
    Читать полностью

  • 08.09.2015
    IPNET

    Компания IPNET — это крупнейший оператор и технологический лидер на рынке телекоммуникаций Киева. Мы предоставляем... 
    Читать полностью

  • 08.09.2015
    Boryspil.Net

    Интернет-провайдер «Boryspil.net» начал свою работу в 2008 году и на данный момент является одним из крупнейших поставщиков... 
    Читать полностью

  • 08.09.2015
    4OKNET

    Наша компания работает в сфере телекоммуникационных услуг, а именно — предоставлении доступа в сеть интернет.Уже... 
    Читать полностью

  • 08.09.2015
    Телегруп

    ДП «Телегруп-Украина» – IT-компания с 15-летним опытом работы на рынке телекоммуникационных услуг, а также официальный... 
    Читать полностью

  • 08.09.2015
    Софтлинк

    Высокая скоростьМы являемся участником Украинского центра обмена трафиком (UA — IX) с включением 10 Гбит / сек... 
    Читать полностью