SPF/DKIM проходять, але листи потрапляють у спам: приховані сигнали, які потрібно виправити

Швидкий план діагностики (знайти вузьке місце швидко)

Коли «SPF/DKIM проходять, але все одно спам» трапляється, люди панікують і починають хаотично шаритись по DNS.
Не робіть цього. Ставтесь до цього як до інциденту. Спочатку тріаж, потім виправлення.

1) Підтвердьте, що проблема — розміщення, а не прийом

• Перевірте, чи повідомлення прийняте (250 OK) і куди воно потрапляє: спам проти вкладки «Промоакції» проти вхідних — це все одно доставка, просто погане розміщення.
• Якщо ви бачите відкладення/блокування (4xx/5xx), у вас цензор з репутації або політичний шлюз, а не «фільтрація спаму». Це інша тактика.

2) Візьміть один реальний лист і читайте заголовки як детектив

• Автентифікація: SPF=pass, DKIM=pass, DMARC=pass — необхідно, але не достатньо.
• Вирівнювання: «pass» у DMARC не завжди означає те, що ви думаєте, якщо використовуєте субдомени, кілька From-ідентичностей або сторонніх відправників.
• ARC: якщо пошту пересилають (розсилки, системи тикетів), ARC може бути різницею між «pass» і «виглядає підробкою».

3) Визначте, яка вісь дає збій: ідентичність, інфраструктура чи поведінка

• Ідентичність: неправильне вирівнювання, дивні домени у From, поламані Reply-To, непослідовні DKIM-селектори.
• Інфраструктура: rDNS, HELO, TLS-параметри, репутація IP/домену, сусіди по спільному IP, патерни швидкості відправки, таймаути.
• Поведінка: гігієна списків, рівень скарг, залученість, раптові сплески обсягів, «холодні» домени, відбитки контенту.

4) Виправляйте найбільший важіль насамперед

• Високий рівень скарг і погана гігієна списків поховають ідеальні SPF/DKIM.
• Поганий rDNS/HELO і підозрілий TLS можуть зіпсувати вас ще до того, як оцінять контент.
• Невирівняний DMARC може зробити вас схожими на фішера, навіть із коректними підписами.

Перефразована ідея від Werner Vogels: «Усе ламається постійно; проектуйте так.» Доставляння пошти — те саме: припускайте недовіру, а потім заслужуйте довіру знову і знову.

Що насправді доводять SPF/DKIM/DMARC (і чого вони не доводять)

SPF: «цей IP дозволений надсилати для цього домену»

SPF перевіряє конвертного відправника (MAIL FROM / Return-Path), а не видимий для людини заголовок From.
SPF-прохід може співіснувати з From-доменом, який не має до нього відношення. Тому й існує DMARC.

DKIM: «цей домен підписав цей вміст»

DKIM перевіряє, що домен підписувача (значення d=) підписав певні заголовки й тіло.
DKIM нічого не каже про те, чи подобаєтесь ви отримувачам.

DMARC: «видимий From вирівняний з SPF або DKIM»

DMARC — це політика-обгортка. Вона перевіряє, чи домен у видимому From вирівнюється (строго або релаксовано) з SPF-аутентифікованим доменом
або з DKIM-доменом підпису.

Чого вони не доводять

• Що у вас хороша репутація відправника.
• Що ваш список — на основі дозволу й має мало скарг.
• Що ваш контент не виглядає спамним або сумнівним.
• Що ваша інфраструктура виглядає як справжня пошта (rDNS/HELO/TLS узгоджені).
• Що ваші патерни відправки стабільні й «людяні».

Автентифікація — як паспорт. Вона доводить, хто ви кажете, що ви є.
Вона не доводить, що ви крутий на вечірках. Провайдери скриньок турбуються про вечірку.

Цікаві факти та історія (8 коротких тез)

1. SPF виник на початку 2000-х і з’явився в епоху підроблених конвертних відправників та «Caller ID для пошти».
2. DKIM стандартизували пізніше після злиття DomainKeys і Identified Internet Mail в один механізм.
3. DMARC з’явився від операторів (великих поштових провайдерів і відправників), які хотіли шар політик, а не лише криптодоказ.
4. Вирівнювання стало ключовою інновацією: DMARC зробив примітний для людини From-домен керованим.
5. Пересилання ламає SPF за задумом, бо IP пересилальника не авторизований у SPF-реєстрі оригінального домену.
6. Розсилки часто ламають DKIM, коли змінюють тему або тіло (додають футери), що анулює підписи.
7. Системи репутації передували DMARC: провайдери давно використовували оцінки поведінки IP/домену, навіть коли автентифікація була слабкою.
8. TLS став сигналом доставності не через моду, а тому що шифрування корелює з легітимними відправниками.

Жарт №1: Доставність електронної пошти — єдиний вид спорту, де можна зробити все правильно і все одно програти через чужу кнопку «відписатися».

Приховані сигнали, які вирішують: вхідна чи спам

1) Репутація домену та IP — окремі речі, і обидва важливі

Провайдери оцінюють вас по кількох осях: IP, домен у видимому From, DKIM d= домен,
Return-Path домен і іноді домени в посиланнях. У вас може бути бездоганний домен і поганий IP (спільні пули),
або пристойний IP і зовсім новий домен, що виглядає як «одноразовий».

Якщо ви на спільній інфраструктурі, поведінка сусідів може вплинути на вас. Якщо у вас власні IP,
важливіший розігрів і послідовність, ніж правильність DNS.

2) «Pass» у DMARC не гарантує здорового брендової поверхні

DMARC може проходити, а лист виглядати підозрілим для шарів контенту й інтерфейсу. Приклад:
From: billing@yourbrand.com, але Reply-To — інший домен, посилання ведуть на третій домен,
а тіло виглядає як скидання пароля. Технічно валідно. Практично — лякає.

3) Ім’я HELO/EHLO, rDNS і послідовність — сигнали довіри

Дивно, але значну частину пошти оцінюють до того, як повністю проаналізують тіло. Якщо ваше SMTP-привітання каже
localhost або випадковий хост у хмарі, а rDNS не збігається — ви створили тертя.
Не завжди фатально. Часто накопичувально.

4) TLS-позиція: шифрування не обов’язкове скрізь, але його відсутність — запах дешевизни

Опортуністичний TLS — норма. Відсутність TLS зовсім, застарілі набори шифрів або зламані ланцюги сертифікатів можуть підштовхнути вас у «дешеві» відправники.
Додайте MTA-STS і звітування по TLS, якщо серйозно ставитесь до теми. Це не лише театр безпеки; це знижує ризики пониження рівня захисту й помилки маршрутизації.

5) Рівень скарг перемагає ваші наміри щоразу

Ви можете клястися, що отримувачі підписалися. Провайдери вірять у поведінку отримувача, а не у вашу таблицю.
Скарги — отрута; бунти — попередження; відсутність взаємодії — повільна смерть.

6) Сигнали залученості: відкриття менш надійні, але взаємодія важлива

Провайдери моделюють, чи читали, відповідали, переносили в папки, видаляли без читання або позначали як спам.
«Мій CEO відкрив» — не метрика. Сегментуйте за зацікавленими отримувачами.

7) Відбитки контенту: шаблони, репутація URL і «фішингові» структури

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

8) Заголовки List-Unsubscribe — примітиви доставності

Якщо користувачам важко вийти з розсилки, вони зроблять це грубо. Провайдери це помічають.
Реалізуйте одноклікове відписування, де це можливо, і зробіть його працюючим. Не «працює здебільшого».

9) Обробка відмов і списки придушення: нудно, але критично

Якщо ви продовжуєте надсилати на мертві адреси, ви виглядаєте як спамер, який купив список. Бо саме так і роблять спамери.
Жорсткі відмови треба швидко придушувати. М’які відмови потребують політики (вікно повтору, потім придушення).

10) Патерни відправки: сплески обсягів, зміни розкладу і штрафи за «новий потік»

Системи доставності люблять передбачуваність. Раптові сплески, нові типи повідомлень або зміна провайдера можуть виглядати як захоплення облікового запису.
Розігрівайте нові IP, плавно нарощуйте нові потоки і уникайте масових розсилок по «холодних» списках.

Жарт №2: Ваш поштовий сервер — як швейцар у нічному клубі: йому байдуже, наскільки гарний ваш SPF, його цікавлять люди, з якими ви прийшли.

Практичні завдання: команди, виводи, рішення (12+)

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

Завдання 1: Перегляньте SPF-запис і порахуйте DNS-запити

cr0x@server:~$ dig +short TXT example.com
"v=spf1 include:_spf.mailvendor.net ip4:203.0.113.10 -all"

Що це означає: SPF існує і використовує include плюс пряму IP. Хороший початок.
Рішення: Якщо бачите багато include, спростіть або “зплющіть” запис. SPF має ліміт у 10 DNS-запитів; перевищення дає permerror і тиху проблему.

Завдання 2: Оцініть SPF для конкретного відправного IP

cr0x@server:~$ spfquery --ip 203.0.113.10 --sender bounce@example.com --helo mail.example.com
pass (sender SPF authorized)

Що це означає: Цей IP авторизований для домену конверта.
Рішення: Якщо повертає fail або softfail, виправляйте SPF передусім. Якщо permerror, ймовірно, перевищено ліміт запитів або є синтаксична помилка.

Завдання 3: Перевірте, чи існує DKIM-селектор і чи він коректний

cr0x@server:~$ dig +short TXT s1._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Що це означає: Селектор s1 публікує відкритий ключ.
Рішення: Якщо запису немає, DKIM не пройде. Якщо запис розбитий на кілька рядків неправильно, деякі валідатори можуть зламатися — публікуйте коректно.

Завдання 4: Перевірте політику DMARC і режим вирівнювання

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; adkim=r; aspf=r; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com; pct=100"

Що це означає: DMARC встановлено в режим quarantine з релаксованим вирівнюванням для SPF і DKIM.
Рішення: Якщо SPF/DKIM проходять, а ви все одно у спамі, політика DMARC — не головний важіль. Використайте її для перевірки, що вирівнювання не випадково ламається для деяких потоків.

Завдання 5: Перевірте rDNS (PTR) для вашого відправного IP

cr0x@server:~$ dig +short -x 203.0.113.10
mail.example.com.

Що це означає: PTR встановлено.
Рішення: Якщо PTR відсутній, загальний або вказує на несумісні домени — виправте. Багато приймачів трактують відсутність PTR як сигнал низької довіри.

Завдання 6: Перевірте FCrDNS (повторно-підтверджений зворотний DNS)

cr0x@server:~$ dig +short A mail.example.com
203.0.113.10

Що це означає: PTR-ім’я резольвиться назад на той самий IP.
Рішення: Якщо прямий і зворотний записи не збігаються — вирівняйте їх. Це базова гігієна й знімає одну просту причину фільтрації.

Завдання 7: Перевірте SMTP-банер/HELO зовні

cr0x@server:~$ nc -v mail.example.com 25
Connection to mail.example.com 25 port [tcp/smtp] succeeded!
220 mail.example.com ESMTP Postfix

Що це означає: Банер — реальний хост, не localhost.
Рішення: Якщо банер або HELO дивний — налаштуйте Postfix smtpd_banner і myhostname. Невідповідність кричить «компрометація віртуальної машини».

Завдання 8: Перевірте STARTTLS і ланцюг сертифіката

cr0x@server:~$ openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Verification: OK
Server Temp Key: X25519, 253 bits

Що це означає: STARTTLS працює, сучасний TLS, сертифікат валідний.
Рішення: Якщо валідація падає — виправте ланцюг сертифікатів. Якщо TLS відсутній — додайте його. Це не дасть вам миттєвого попадання в інбокс, але прибирає легкий привід для недовіри.

Завдання 9: Перевірте, чи потрапляєте в поширені DNS-блоклисти (сигнал, не Євангеліє)

cr0x@server:~$ for z in zen.spamhaus.org bl.spamcop.net b.barracudacentral.org; do \
  q=$(echo 10.113.0.203 | awk -F. '{print $4"."$3"."$2"."$1}'); \
  echo -n "$z: "; dig +short ${q}.${z} A; done
zen.spamhaus.org:
bl.spamcop.net:
b.barracudacentral.org:

Що це означає: Немає запису в цих зонах (порожній вивід).
Рішення: Якщо вас внесено — розбирайтеся, чому: скомпрометований хост, погана практика списків або проблеми спільного IP. Видалення з чорних списків — паперова робота; профілактика — інженерія.

Завдання 10: Перевірте чергу Postfix на накопичення (заповнена черга може виглядати як спам-сплеск)

cr0x@server:~$ mailq | head
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
3F2A01234A*     2480 Mon Jan  4 10:12:01  bounce@example.com
                                         user1@gmail.com
                                         user2@outlook.com

Що це означає: Повідомлення в черзі (зірочка означає активне).
Рішення: Якщо черга росте під час відправок — можливо, вас обмежують або ставлять у сірий список. Повільна доставка може створювати кластерні повтори й підозрілий патерн. Налаштовуйте паралельність і політику повторів обережно, не агресивно.

Завдання 11: Перегляньте SMTP-коди відповіді в логах (вас обмежують?)

cr0x@server:~$ grep -E "status=deferred|status=bounced" /var/log/mail.log | tail -n 5
Jan  4 10:14:22 mail postfix/smtp[22101]: 3F2A01234A: to=<user1@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.27.26]:25, delay=12, delays=0.1/0.02/5/6.9, dsn=4.7.28, status=deferred (host gmail-smtp-in.l.google.com[142.250.27.26] said: 421-4.7.28 [203.0.113.10] Our system has detected an unusual rate of unsolicited mail...)
Jan  4 10:14:25 mail postfix/smtp[22102]: 9ADBC1234B: to=<user2@outlook.com>, relay=outlook-com.olc.protection.outlook.com[52.101.73.8]:25, delay=8.2, delays=0.1/0.01/3.3/4.8, dsn=4.7.0, status=deferred (host outlook-com.olc.protection.outlook.com[52.101.73.8] said: 451 4.7.0 Temporary server error. Please try again later.)

Що це означає: Вас обмежують або у вас проблеми з репутацією (4.7.x).
Рішення: Припиніть «намагатися відправляти сильніше». Зменшіть обсяг, сегментуйте до зацікавлених, зменшіть скарги, розігрівайте IP і не змішуйте маркетинг з транзакційними листами на одному IP/домені.

Завдання 12: Перевірте вирівнювання в реальному отриманому заголовку (результати SPF/DKIM/DMARC)

cr0x@server:~$ sed -n '1,80p' sample-headers.txt
Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s1 header.b=abc123;
       spf=pass (google.com: domain of bounce@example.com designates 203.0.113.10 as permitted sender) smtp.mailfrom=bounce@example.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com

Що це означає: Вирівнювання в порядку: header.from збігається з DKIM-доменом і SPF mailfrom — той самий організаційний домен.
Рішення: Якщо DMARC не проходить або показує невирівнювання — виправте архітектуру ідентичностей або налаштуйте вендора так, щоб підписували вашим доменом і використовували вирівняний return-path.

Завдання 13: Перевірте заголовки List-Unsubscribe (і чи не зламана реалізація)

cr0x@server:~$ grep -i "^List-Unsubscribe" -n sample-headers.txt
42:List-Unsubscribe: <mailto:unsubscribe@example.com?subject=unsubscribe>, <https://example.com/unsub?u=abcd>
43:List-Unsubscribe-Post: List-Unsubscribe=One-Click

Що це означає: Ви пропонуєте mailto та одноклікове відписування.
Рішення: Якщо відсутній — реалізуйте. Якщо є, але кінцева точка ненадійна — виправте надійність насамперед — зламане відписування породжує скарги.

Завдання 14: Переконайтесь, що ваш домен відправки не використовується для веб-трекінгу на «новому» хості

cr0x@server:~$ dig +short CNAME click.example.com
tracking.vendor-mail.net.

Що це означає: Ваш домен для кліків використовує домен вендора через CNAME.
Рішення: Якщо цей трекінговий домен має погану репутацію, він може потягнути вашу пошту вниз. Розгляньте відключення трекінгу кліків для чутливих потоків або перенесення на стабільний піддомен з історією.

Завдання 15: Перевірте раптові зміни обсягів, парсячи логи

cr0x@server:~$ awk '{print $1" "$2" "$3}' /var/log/mail.log | sort | uniq -c | tail
  88 Jan  4 10:12
  91 Jan  4 10:13
  96 Jan  4 10:14
 420 Jan  4 10:15
 110 Jan  4 10:16

Що це означає: Є сплеск о 10:15.
Рішення: Якщо сплески корелюють із попаданням у спам — згладьте швидкість відправки, розділіть кампанії і поступово нарощуйте. Доставність не любить несподіванок.

Три корпоративні міні-історії з передової

Міні-історія 1: Інцидент через неправильне припущення

Середня SaaS-компанія мігрувала транзакційні листи від вендора до «власного Postfix на чистому IP».
SPF і DKIM пройшли тестування. DMARC показував pass. Усі похлопали один одному по плечу й перейшли далі.

Протягом 48 годин листи для скидання паролю почали потрапляти в спам у значної частини користувачів.
Підтримка отримала класичну фразу: «Я не отримую листів». Інженери перевірили: пошту приймали (250),
немає відмов, немає блокувань. То, мабуть, «помилка користувача», так?

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

Виправлення було операційним: обмежити транзакційні відправки (так, боляче), віддати пріоритет зацікавленим отримувачам
і розігрівати IP цілеспрямовано. Вони також розділили транзакційний і маркетинговий потоки по субдоменах і IP,
щоб один не міг отруїти інший. Після кількох тижнів стабільної поведінки розміщення відновилося.

Міні-історія 2: Оптимізація, яка відвернулась назад

Рітейл-компанія вирішила «стати розумнішою». Вони хотіли зменшити час обробки відмов і «підвищити пропускну здатність»,
тому налаштували MTA на агресивніші повтори, підвищили паралельність і скоротили таймери backoff.
На папері: швидша доставка. Насправді: повільна катастрофа.

Великі поштові провайдери відповіли ще більшим обмеженням. Їх логи наповнилися 4.7.x деферами.
Черга почала осцилювати: величезні сплески повторів, потім більше дефертів, потім ще більші сплески.
Те, що виглядало як «ефективні повтори», виглядало для приймачів як відправник, який не приймає натяків.

Розміщення в спамі погіршилось по всій базі, включно з повідомленнями, які раніше добре потрапляли в інбокс.
Це не був контент. Не був DKIM. Це була поведінка на рівні SMTP: схема повторів стала голосною і машинною.

Відкат був нудним: повернути консервативні графіки повторів, зменшити паралельність і ввести обмеження на домен.
Вони також почали трактувати 4.7.x як сигнал призупинитися, а не як виклик.
Іронія: доставка стала швидшою для тих отримувачів, які мали значення, бо відправники перестали тригерити обмеження.

Міні-історія 3: Нудна, але правильна практика, яка врятувала ситуацію

Компанія з охорони здоров’я мала суворі вимоги до доставності нагадувань про прийоми.
Вони зробили нелюдську річ: раз на тиждень чистили списки, обробляли відмови впродовж годин
і вели список придушення, який ніхто не міг обійти без заяви й аудиту.

Одного кварталу маркетинг імпортував «реактиваційний список» зі старого CRM-експорту.
Він не був зловмисним. Він був застарілим. Перша розсилка дала хвилю жорстких відмов і помітне зростання скарг.

Саме нудка практика їх врятувала: автоматичне придушення спрацювало негайно, видаливши мертві адреси перед другою хвилею.
Системи також зафіксували сплеск скарг і призупинили подальші відправки на час розслідування. Транзакційна пошта продовжувала йти окремою інфраструктурою.

Наслідки були м’якими: невелике тимчасове падіння розміщення маркетингових повідомлень, але ніякого впливу на нагадування.
Без аварійних змін в DNS, без паніки «спростити SPF», без звинувачень вендорів. Просто дисциплінована гігієна й розділення відповідальностей.

Поширені помилки: симптом → корінь → виправлення

1) Симптом: SPF/DKIM проходять, DMARC проходить, але Gmail каже «схожі повідомлення були визначені як спам»

Корінь: погана залученість і/або скарги, часто через відправки на «холодні» списки або змішування потоків (транзакційні + маркетинг).

Виправлення: сегментуйте на зацікавлених отримувачів, поставте на паузу холодні сегменти, розділіть маркетинг і транзакції на різні субдомени/IP, додайте List-Unsubscribe і зменшіть частоту.

2) Симптом: Outlook/Hotmail час від часу кладе пошту в спам

Корінь: непослідовні інфраструктурні сигнали (несумісність rDNS/HELO, проблемний TLS, змінні IP), плюс патерни контенту, що нагадують фішинг.

Виправлення: стабілізуйте IP-відправки, виправте rDNS і EHLO, переконайтесь, що STARTTLS працює стабільно, вирівняйте From/Reply-To/домени посилань і уникайте ризикових типів вкладень.

3) Симптом: Внутрішні тести показують інбокс, реальні користувачі бачать спам

Корінь: тестові акаунти не репрезентативні; репутацію формує поведінка реальних користувачів. Також скриньки споживачів різняться історією користувача.

Виправлення: інструментуйте рівень скарг, відмов і залучення за доменами; тестуйте на реальних сегментах; орієнтуйтесь на недавніх підписників і зацікавлених отримувачів.

4) Симптом: DMARC не проходить тільки для пересланих листів

Корінь: пересилання ламає SPF; DKIM ламається, коли проміжні вузли змінюють вміст; ARC відсутній.

Виправлення: забезпечте стійкість DKIM (підписуйте стабільні заголовки, уникайте переписування), розгляньте ARC для контролюваних форвардерів і прийміть, що деяке пересилання може бути втратним.

5) Симптом: DMARC проходить, але бренд виглядає підозріло

Корінь: розбалансована «брендова поверхня» (Reply-To або посилання на несумісні домени; надмірне трекінгування; скорочувачі URL).

Виправлення: тримайте From/Reply-To/посилання в тісному, послідовному сімействі доменів; мінімізуйте редиректи; використовуйте стабільний піддомен для трекінгу з історією.

6) Симптом: Раптова поява спаму після переходу ESP

Корінь: новий потік відправки з немає історії; занадто крутий розігрів; не перенесені списки придушення.

Виправлення: розігрівайте поступово, перенесіть suppressions, почніть з зацікавлених отримувачів і уникайте зміни From-домену одночасно з інфраструктурою.

7) Симптом: Доставність була нормальною, потім впала після додавання нового шаблону

Корінь: контент-набір тригернув відбиток (фрази, патерни посилань або домен у URL з поганою репутацією).

Виправлення: порівняйте шаблони, видаліть ризикові фрази, перевірте домени URL, зменшіть дисбаланс зображень і тексту, уникайте вкладень, якщо вони не потрібні.

8) Симптом: Повідомлення сильно затримуються, а потім приходять у спамі

Корінь: обмеження й шторми повторів створюють кластерні патерни; накопичення в черзі змінює таймінги і сприйняття репутації.

Виправлення: введіть обмеження по доменам, поважайте дефери, зменшіть паралельність і згладьте відправки.

Контрольні списки / покроковий план

Покроковий план для «автентифікація проходить, але спам» (робіть у порядку)

1. Візьміть одне репрезентативне повідомлення, яке потрапило в спам, і збережіть повні заголовки.
   • Рішення: якщо не можете відтворити з реальними заголовками, ви відлагоджуєте «враження».
2. Підтвердьте вирівнювання DMARC для цього повідомлення (header.from проти DKIM d= і SPF mailfrom).
   • Рішення: якщо невирівнювання — вирішіть архітектуру ідентичностей передусім.
3. Перевірте гігієну інфраструктури: PTR, FCrDNS, HELO, TLS.
   • Рішення: виправте очевидні гігієнічні проблеми; це дешеві перемоги й знижує базову підозрілість.
4. Перевірте на обмеження/дефери в логах (4.7.x — ваш канарейка).
   • Рішення: якщо обмежують — сповільніть і сегментуйте; не налаштовуйте повтори, щоб «виграти».
5. Розділіть потоки: транзакції проти маркетингу проти повідомлень.
   • Рішення: якщо сьогодні ви все змішуєте — сплануйте розділення. Це одна з найвищих ROI- змін.
6. Аудит гігієни списків: відмови, скарги, старі сегменти, реактиваційні кампанії.
   • Рішення: якщо не можете швидко виміряти скарги/відмови — виправте інструментацію перш ніж масштабувати відправки.
7. Зменшіть «підозрілі поверхні»: несумісні домени, агресивне трекінгування, скорочувачі URL, вкладення.
   • Рішення: спростіть. Мета — доставитись, а не виграти премію з маркетингу.
8. Розігрівайте і стабілізуйте: послідовний обсяг, передбачуваний розклад, поступове нарощування.
   • Рішення: розігрів — це продакшн-розгортання, а не одноразова конфігурація.

Операційний чеклист (щотижня)

• Переглядайте тренди відмов і скарг за доменами отримувачів.
• Переконайтесь, що придушення застосовуються впродовж годин, не днів.
• Ротація DKIM-ключів за контрольованим графіком (зберігайте старі селектори під час переходу).
• Підтверджуйте, що rDNS і TLS залишаються коректними після змін інфраструктури.
• Перевіряйте найчастіше клікаємі домени й ланцюги редиректів у шаблонах листів.
• Перевіряйте глибину черги та дефери; налаштовуйте ліміти швидкості, а не лише паралельність.

Архітектурний чеклист (одноразово, потім підтримка)

• Розділіть субдомени відправки по потоках (наприклад, notify., billing., marketing.).
• Вирівнюйте DKIM d= з доменом From (або організаційно вирівняним субдоменом) коли можливо.
• Використовуйте виділений IP (або хоча б пул) для критичних транзакційних повідомлень.
• Реалізуйте List-Unsubscribe і одноклікове відписування для масових розсилок.
• Переконайтесь, що обробка відмов автоматизована і надійна.

FAQ

1) Якщо SPF і DKIM проходять, чому провайдер все одно кладе мене в спам?

Тому що автентифікація доводить лише ідентичність і цілісність повідомлення. Розміщення керують репутація, поведінка, залученість, скарги і патерни контенту.
Проходження SPF/DKIM означає, що ви підтверджений відправник — не обов’язково бажаний.

2) Чи потрібен DMARC для попадання в інбокс?

Не універсально, але практично так, якщо вам важлива стабільна доставка і запобігання підробок. DMARC змушує прибрати проблему вирівнювання,
що позбавляє велику категорію сигналів «виглядає як підробка».

3) Яке найшвидше покращення, якщо ми потрапляємо в спам?

Припиніть надсилати тим, хто не взаємодіє. Сегментуйте агресивно: недавні відкриття/кліки/відповіді (що можете достовірно виміряти),
недавні реєстрації і підписники, які взаємодіяли. Репутація відновлюється швидше, коли ви перестаєте дратувати людей.

4) Чи перейти на виділений IP?

Якщо у вас достатній обсяг, щоб виправдати розігрів і підтримку — так, особливо для транзакційних потоків.
Якщо обсяг низький або нестабільний, виділений IP може бути гіршим, бо ви не зможете побудувати стабільну репутацію.

5) Чи дійсно контент важливий, якщо репутація хороша?

Так. Репутація відкриває двері; контент вирішує, чи залишитися в кімнаті. Фішингова структура, ризикові URL,
надмірне трекінгування і дивне форматування можуть потопити поштy з хорошою репутацією.

6) Наша пошта пересилається через системи тикетів і потім ламається. Що робити?

Пересилання ламає SPF, а модифікації ламають DKIM. Якщо ви контролюєте форвардер, розгляньте імплементацію ARC.
Інакше зосередьтесь на стійкості DKIM (підписуйте стабільні заголовки) і прийміть, що деякі сценарії пересилання знизять довіру.

7) Ми додали більше DKIM-ключів/селекторів. Чи може це нашкодити?

Саме по собі — ні. Шкодить непослідовне підписування (іноді підписано, іноді ні), биті DNS-записи або ротація селекторів без перехідного періоду.
Залишайте старі селектори активними, поки пошта з ними ще в дорозі.

8) Чи варто ставити «p=reject» у DMARC, щоб покращити доставність?

Запровадження DMARC може зменшити підробки і зловживання брендом, що опосередковано допомагає репутації.
Але це не виправить погану гігієну списків або високі скарги. Не сприймайте p=reject як кнопку для покращення доставності.

9) Чому тести на «seed» показують інбокс, а реальні користувачі бачать спам?

Тестові акаунти не поводяться як реальні отримувачі й не мають тієї ж історії. Провайдери персоналізують фільтрування.
Поведінка вашої аудиторії (видалення, скарги, відсутність читань) — це сироватка правди.

10) Чи блок-листи DNS — причина, що ми в спамі?

Іноді, але зазвичай не вся історія для споживчих інбоксів. Блок-листи краще пояснюють жорсткі блоки, ніж тонкі випадки розміщення у спамі.
Використовуйте їх як сигнал для розслідування компрометації або поганої поведінки, а не як єдину метрику.

Висновок: наступні кроки, які справді дають результат

Якщо SPF і DKIM проходять, але ви все одно потрапляєте в спам, перестаньте трактувати доставність як DNS-головоломку.
Це система довіри. Довіру заслужують через послідовну ідентичність, чисту інфраструктуру та шанобливу поведінку при надсиланні.

Зробіть наступне, у порядку:

1. Витягніть одне заспамлене повідомлення, збережіть повні заголовки й підтвердіть вирівнювання DMARC та консистентність доменів (From/Reply-To/посилання).
2. Виправте гігієну інфраструктури: rDNS, FCrDNS, HELO і STARTTLS з валідними сертифікатами.
3. Перевірте логи на предмет обмежень (4.7.x). Якщо бачите — сповільніть і сегментуйте негайно.
4. Розділіть транзакційні й маркетингові потоки по субдоменах і, по можливості, IP/пулу.
5. Реалізуйте й протестуйте одноклікове відписування; посиліть обробку відмов і швидко придушуйте жорсткі відмови.
6. Розігрівайте нові IP/домени так само, як розгортали б новий кластер бази даних: поступово, прозоро і з планами відкату.

Приховані сигнали насправді не такі вже й приховані. Вони не в зоні вашого DNS.
Вони в логах, у поведінці аудиторії і в нудній послідовності ваших систем.