Коротка відповідь

Поштовий сервер отримувача ставить вашому листу три запитання, і на кожне відповідає окремий DNS-запис:

  • SPF - чи має цей сервер право відправляти пошту від вашого домену;
  • DKIM - чи не змінили лист дорогою і чи підписав його ваш домен;
  • DMARC - чи збігається домен, який пройшов перевірку, з тим, що стоїть у полі «Від», і що робити, якщо ні.

Щоб знайти причину, відкрийте заголовки листа і подивіться рядок Authentication-Results: там видно, яка з трьох перевірок провалилась. Найчастіше листи з сайту падають у спам не через сервер, а через форму: вона відправляє через PHP mail() і підставляє чужий домен. Лікується SMTP-плагіном з авторизацією через скриньку вашого домену.

1. SPF, DKIM і DMARC простими словами

Уявіть офіс, куди приносять конверти з печаткою вашої компанії. Охоронець на вході перевіряє три речі.

SPF - список кур'єрів. У DNS домену лежить перелік серверів, яким дозволено відправляти пошту від вашого імені. Прийшов лист з іншого IP - охоронець бачить, що кур'єра в списку немає. Важлива деталь: SPF перевіряє не адресу у полі «Від», яку бачить людина, а технічну адресу повернення (envelope, або Return-Path). Про цю різницю нижче, саме на ній ламається більшість сайтів.

DKIM - сургучна печатка. Сервер підписує кожен лист закритим ключем, а відкритий ключ лежить у DNS. Отримувач звіряє підпис: якщо дорогою змінили хоча б символ у тілі чи темі, печатка «зламана». Підпис містить домен, яким його поставлено, - це поле d=.

DMARC - інструкція для охоронця. Він вимагає, щоб домен, який пройшов SPF або DKIM, збігався з доменом у полі «Від». І каже, що робити з листом, який не пройшов: пропустити (p=none), покласти в спам (quarantine) чи відхилити (reject).

ЗаписЩо перевіряєЯку адресу береТиповий збій
SPFIP сервера-відправникаReturn-Path (envelope)лист іде через сервіс, якого немає в записі
DKIMцілісність листа і домен підписуполе d= у підписіключ у DNS обрізаний або не той селектор
DMARCзбіг домену з полем «Від»From, який бачить людинаSPF і DKIM пройшли, але для іншого домену

2. Як за хвилину побачити, що саме провалилось

Отримувач уже записав вердикт у заголовки. Надішліть лист саме тим шляхом, що падає в спам. Якщо скаржаться на заявки з сайту - заповніть форму на сайті, а не пишіть з поштової програми, це два різні маршрути.

  • Gmail: три крапки біля листа → «Показати оригінал».
  • Будь-яка скринька: сервіс mail-tester.com дає тимчасову адресу і після відправки показує оцінку з 10 з розбором кожного пункту.

У заголовках знайдіть рядок Authentication-Results. Так виглядає здоровий лист:

spf=pass smtp.mailfrom=admin@вашдомен; dkim=pass header.i=@вашдомен header.s=x; dmarc=pass header.from=вашдомен

Дивіться не тільки на слово pass, а й на домени. smtp.mailfrom - це адреса повернення, за нею перевіряли SPF. header.i - домен DKIM-підпису. header.from - те, що бачить людина. Якщо всі три закінчуються вашим доменом, з автентифікацією все гаразд і шукати треба в розділі 7. Якщо в одному з них стоїть домен сервера, чужий сервіс чи Gmail відвідувача - ви знайшли причину.

3. SPF: чотири помилки, на які я натрапляю найчастіше

  • Два SPF-записи на одному домені. Хтось додав окремий TXT v=spf1 include:сервіс-розсилок ~all поруч зі старим. За стандартом два записи - це помилка, і отримувач вважає, що SPF немає зовсім. Запис має бути один, усі джерела в ньому через пробіл.
  • Забутий сторонній відправник. CRM, сервіс розсилок, онлайн-бухгалтерія шлють рахунки від вашої адреси, але зі своїх серверів. Кожен такий сервіс дає рядок include:... у своїй документації - його треба дописати в SPF.
  • Більше 10 DNS-запитів. Кожен include, a і mx змушує отримувача робити запит, а ліміт стандарту - 10. Після п'яти-шести сервісів SPF мовчки стає permerror. Зайві include від сервісів, якими вже не користуєтесь, прибирайте.
  • +all або ?all в кінці. +all дозволяє слати від вашого домену будь-кому на планеті. Нормальні варіанти - ~all (м'яко) або -all (жорстко), коли ви впевнені, що перелічили всі джерела.

Базовий SPF, який DirectAdmin створює на нашому сервері сам, виглядає так: v=spf1 a mx ip4:IP_сервера ip6:... ~all. Якщо пошта і сайт живуть на хостингу і сторонніх сервісів немає, його не треба чіпати. Якщо ж DNS домену у Cloudflare чи в реєстратора, запис треба перенести туди руками - DirectAdmin створює його лише у своїй зоні.

4. DKIM: чому підпис є, а перевірку не проходить

На сервері Hosturm DKIM увімкнений для всіх доменів: ключ RSA 2048 біт, селектор x, тобто запис у DNS називається x._domainkey.вашдомен. Коли DKIM усе ж падає, причина зазвичай одна з трьох.

Ключ зіпсувався під час копіювання

2048-бітний ключ довший за 255 символів, а один рядок TXT більшим бути не може. Частина DNS-панелей ділить його на шматки сама, частина обрізає мовчки. Перевірте результат командою nslookup -type=txt x._domainkey.вашдомен: ключ має закінчуватися так само, як у DNS Management в DirectAdmin.

DNS домену не на хостингу

Якщо ви перенесли NS у Cloudflare, а запис x._domainkey туди не додали, сервер підписує листи, але отримувач не знаходить ключа. У заголовках це видно як dkim=neutral або no key.

Лист змінили після підпису

Антивірус на пересилці дописав рядок чи шлюз переписав посилання - і в заголовках з'являється body hash did not verify.

5. DMARC і вирівнювання: чому два PASS не рятують

Можна мати spf=pass і dkim=pass і все одно отримати dmarc=fail. Так буває, коли обидві перевірки пройдені для іншого домену, ніж той, що в полі «Від». Типовий приклад: сервіс розсилок підписує листи своїм доменом і ставить свою адресу повернення. Він чесно проходить SPF і DKIM - але як сервіс, а не як ви.

Щоб DMARC пройшов, достатньо одного вирівнювання: або SPF для домену з поля «Від», або DKIM-підпис з d= вашим доменом. Піддомени рахуються: адреса повернення bounce@mail.вашдомен вирівняна з info@вашдомен. У сторонніх сервісах шукайте в налаштуваннях пункт на кшталт «автентифікація домену» - він додає ваш DKIM.

Сам запис DMARC DirectAdmin не створює, його додаєте ви: TXT з ім'ям _dmarc. Розумний шлях - у три етапи. Спершу p=none з адресою для звітів у rua=, щоб за два-три тижні побачити всіх, хто шле від вашого імені. Потім p=quarantine. І лише коли у звітах місяць немає легітимних провалів - p=reject, який захищає від листів шахраїв від вашого імені. Покрокове налаштування скриньки і всіх записів з нуля - в інструкції пошта на власному домені за 15 хвилин.

6. Листи з форм сайту - головне джерело проблем

Листи з Outlook доходять, а заявки з форми - у спамі: це два різні відправники.

Коли WordPress, OpenCart чи самописний скрипт відправляє лист функцією PHP mail(), лист іде через локальний sendmail. На нашому сервері адреса повернення для таких листів - поштова адреса власника акаунта на основному домені, і DKIM-підпис ставиться саме за нею. Для сайту на основному домені це працює: і SPF, і DKIM вирівняні. А от два сценарії дають провал DMARC:

  • Сайт на додатковому домені акаунта. From - noreply@другийдомен, а підпис і адреса повернення - від основного. Для DMARC другого домену обидві перевірки «чужі».
  • Форма ставить у From адресу відвідувача. Лист «від» [email protected] відправлено не з серверів Google, тож DMARC gmail.com його провалює. Для yahoo.com з політикою reject такий лист не дійде зовсім. Адресу клієнта кладіть у Reply-To - кнопка «Відповісти» працюватиме так само.

Як виправити у WordPress

Поставте плагін SMTP (WP Mail SMTP, FluentSMTP або аналог), створіть окрему скриньку, наприклад noreply@вашдомен, і вкажіть: хост - той, що вказаний у листі-активації тарифу, порт 465, SSL, логін - повна адреса скриньки. Тоді лист іде як від звичайної поштової програми: адреса повернення, підпис і From в одному домені. У Contact Form 7 чи Elementor у полі «Від» залиште цю ж скриньку. Що ще варто перевірити в тарифі під WordPress, я розібрав в окремій статті.

OpenCart та інші CMS

В OpenCart це Налаштування → Пошта: протокол SMTP замість Mail, ті самі сервер, порт 465 і повна адреса скриньки як логін. У PrestaShop і Joomla так само: сайт має логінитися в скриньку свого домену, а не віддавати лист системі анонімно.

7. Коли автентифікація в порядку, а лист усе одно в спамі

Три PASS з однаковим доменом означають, що вас впізнали. Далі фільтр оцінює, чи ви поводитесь як спамер:

  • Репутація IP сервера. На шареді IP спільний, і за чорні списки та зворотний запис (PTR) відповідає хостер, а не ви. 29 вересня я перевірив IP сервера в Spamhaus ZEN, Barracuda і SpamCop - у жодному його немає. Перевірити самостійно можна на mxtoolbox.com → Blacklist Check.
  • Молодий домен. Домен, зареєстрований тиждень тому, який одразу пише сотням адрес, виглядає підозріло. Репутація накопичується тижнями нормального листування, на яке люди відповідають.
  • Однакові листи пачкою. Сервер пропускає до 200 листів за добу від кожної скриньки, а на весь акаунт - до 1000. Розсилку на базу краще віддати сервісу з відпискою, інакше скарги отримувачів вдарять по домену, з якого ви пишете клієнтам.
  • Зміст. Тема капсом, одне посилання на скорочувач, вкладений архів чи лист-картинка без тексту - кожне з цього додає балів у спам-фільтрі.
  • Скринька чи сайт відправляють спам без вашого відома. Якщо лічильник відправлених росте сам, пароль скриньки вкрали або в сайт підкинули скрипт-розсильник. Що робити в такому разі, розписано у статті сайт зламали: порядок дій.

8. Що налаштовано на хостингу, а що лишається вам

Хто за що відповідає на тарифах Hosturm:

ЩоХто робитьСтан за замовчуванням
SPFпанель, автоматичностворюється в зоні DirectAdmin, якщо NS домену на Hosturm
DKIMпанель, автоматично2048 біт, селектор x, підписує кожен лист
DMARCвине створюється, додається одним TXT-записом
Записи у Cloudflare чи в реєстраторавиусі переносяться вручну
SMTP для форм сайтувиза замовчуванням CMS шле через PHP mail()
Репутація IP, чорні спискихостерPTR і IP за хостером, масову відправку стримують ліміти 200/1000

Пошта з DKIM є в усіх планах, різниця - у кількості скриньок і місці: Старт за 142 грн/міс дає 15 скриньок і 10 GB NVMe на сайт разом з поштою, Оптимал за 229 грн/міс - 25 скриньок і 20 GB, Бізнес за 350 грн/міс - 50 і 30 GB, Pro за 800 грн/міс - без ліміту скриньок і 100 GB. Це ціни при оплаті на рік; якщо платити щомісяця, Старт обійдеться в 479 грн. Порівняти плани повністю можна на сторінці тарифів хостингу або в блоці тарифів на головній.

Якщо щось не працює

  1. Відправте тестовий лист тим самим шляхом, що падає в спам, - форма сайту, CRM або програма.
  2. Знайдіть Authentication-Results і випишіть три домени: smtp.mailfrom, header.i, header.from.
  3. Провалений SPF - перевірте, що запис один і в ньому є всі відправники.
  4. Провалений DKIM - порівняйте ключ x._domainkey у публічному DNS з тим, що в DirectAdmin.
  5. Провалений DMARC при двох PASS - домени не збігаються. Для сайту підключіть SMTP, для сервісу увімкніть автентифікацію домену.
  6. Усе PASS, а лист у спамі - дивіться зміст, обсяги відправки і чорні списки.

Коли пройшли всі шість пунктів, а лист однаково в спамі, напишіть у Telegram-підтримку і додайте повний заголовок тестового листа. У логах поштового сервера за хвилину видно, що відповів сервер отримувача, і пошук причини займає одну розмову.

Підсумок

SPF каже, хто може відправляти, DKIM доводить, що лист справжній, DMARC вимагає, щоб усе це стосувалося домену з поля «Від». На хостингу перші два записи вже працюють, DMARC і SMTP для форм сайту лишаються за вами. Почніть із заголовка Authentication-Results: три домени в ньому показують причину швидше, ніж будь-які здогадки.