Доставка електронної пошти: повідомлення потрапляють у спам — реальні виправлення (SPF/DKIM/DMARC правильно)

Ви відправили лист. У SMTP-логах написано “250 2.0.0 OK”. Ваш додаток позначає його як «доставлено». Відділ продажів усе ще наполягає, що клієнт його не отримав. І коли ви просите скріншот — він там є: у папці спаму, сидить між підробленим рахунком і розсилкою «гендиректор хоче подарункові карти».

Це не загадка. Це інженерна проблема з прикріпленою системою репутації. SPF/DKIM/DMARC — базові вимоги, але більшість команд налаштовують їх як «галочку» й потім дивуються, коли Gmail ставиться до них так само.

Швидкий план діагностики

Якщо ви на чергуванні і ваш CEO щойно переслав «чому ми в спамі?» до всього листа, не починайте з переписування SPF-запису з пам’яті. Тріажуйте як SRE: швидко визначте вузьке місце, потім звужуйте пошук.

Спочатку: підтвердіть, що побачив отримувач

• Отримайте повний вихідний код повідомлення з поштової скриньки отримувача (заголовки важливіші за ваші логи).
• Знайдіть заголовки Authentication-Results і Received. Вони показують результати SPF/DKIM/DMARC за версією отримувача — єдиний вирок, який має значення.
• Перевірте, який домен у видимому From: і який домен у Return-Path (адреса для зворотних повідомлень). DMARC — це гра вирівнювання.

По-друге: визначте режим відмови

• SPF fail/softfail/permerror? Зазвичай DNS, занадто багато запитів, або невірна IP-адреса відправника.
• DKIM fail? Зазвичай невідповідність селектора, зламане канонічне відтворення через перезапис, або опублікований невірний ключ.
• DMARC fail? Зазвичай вирівнювання (домен у From не вирівнюється з аутентифікованим доменом SPF або DKIM), або помилка налаштування політики/звітності.
• Усе проходить, але спам усе одно? Тоді це питання репутації/контенту/взаємодії, або ви потрапляєте під обмеження/greylisting і доходите «дивно».

По-третє: перевірте ідентичність та транспортну гігієну

• Reverse DNS (PTR) для відправної IP має існувати і виглядати розумно.
• Ім’я HELO/EHLO має відповідати дійсному імені хоста, яке резолвиться вперед, і бажано збігатися з PTR.
• TLS і шифри не є магією для доставлюваності, але зламані переговори STARTTLS — ознака недовіри.
• Біти і скарги — ваш «артеріальний тиск». Якщо він високий, жодна DNS-гінастика вам не допоможе.

Потім: оберіть найкоротший шлях виправлення

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

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

Як фільтри справді вирішують (поза SPF/DKIM/DMARC)

SPF, DKIM і DMARC відповідають на одне питання: «Чи це повідомлення достовірно авторизоване доменом у заголовку From?» Вони не відповідають на питання: «Чи це повідомлення бажане?»

Сучасні поштові провайдери використовують багаторівневу систему оцінювання. Частина — правила. Багато — репутація. Значна частина — «фідбек користувачів без повідомлення вам», наприклад коли користувачі видаляють ваш лист, не читаючи, або позначають як спам. Неприємна правда: доставляємість — це продуктова функція, яку потрібно заробити і підтримувати, а не просто запис у конфігурації.

Сигнали, які на практиці мають значення

• Аутентифікація + вирівнювання: проста проходка SPF/DKIM не достатня; DMARC-варівнювання — фільтр-пропуск у багатьох інбоксах.
• Послідовність інфраструктури відправки: стабільні IP, послідовний HELO, сталі домени конверта відправника.
• Рівень скарг: якщо люди тиснуть «спам», вам кінець на якийсь час. Провайдери не дискутують. Вони обмежують або відправляють у смітник.
• Гігієна списків: старі списки гниють. Існують пастки для спаму. Жорсткі відмови — не «тимчасова сум», це податок на репутацію.
• Шаблони контенту: мова схожа на фішинг, поламаний HTML, скорочувачі посилань, невідповідність видимого тексту й URL, дивні кодування.
• Залучення: відкриття і кліки — недосконалі, але «читання проти видалення» і «переміщення в інбокс» — сильні сигнали.

Дві реальності, які треба усвідомити:

1. Отримувачі довіряють доменам і IP, а не вашим намірам.
2. Отримувачі оптимізують безпеку користувача, а не вашу конверсію.

Цікавинки й коротка історія

• SMTP з’явився раніше за фільтри спаму: початкові поштові протоколи передбачали співпрацю користувачів у дружній мережі. Інтернет мав іншу думку.
• SPF виник як реакція на підроблені адреси в конверті: він за замовчуванням перевіряє домен у Return-Path (MAIL FROM), а не видимий From.
• DKIM походить з експериментів з підписуванням домену у Yahoo та інших: він створений, щоб вижити при транзиті й довести, що домен відповідає за контент.
• DMARC відносно молодий: він стандартизував вимогу вирівнювання, яку SPF і DKIM самі по собі не нав’язують.
• «p=reject» не став масовим одразу: великі бренди поступово рухалися від відсутності політик → quarantine → reject, бо невірне вирівнювання ламало легітимні потоки.
• Розсилки часто ламають DKIM: підписи псуються через додавання футерів і тегів у тему; канонізація допомагає, але не завжди.
• SPF має жорсткий ліміт DNS-запитів (10): якщо перевищити, отримаєте permerror — автентифікація провалиться навіть якщо IP реально авторизований.
• ARC існує, бо пересилання ламає аутентифікацію: це механізм ланцюгової довіри «це пройшло, коли я його отримав».
• Великі провайдери все більше вимагають аутентифікацію: з часом «без SPF/DKIM/DMARC» перейшло від «підозріло» до «недоставляється в масштабі».

SPF, DKIM, DMARC: зроблено правильно (і вирівнювання)

SPF: ваші дозволені відправники, з гострими краями

SPF — це TXT-запис у DNS, який вказує, які IP (або які інші SPF-зони) мають право відправляти від імені домену. Отримувачі порівнюють його з доменом конверта відправника (Return-Path / MAIL FROM) або, іноді, з доменом HELO.

Операційні поради:

• Тримайте SPF простим. Менше include, менше запитів, менше сюрпризів.
• Не використовуйте “+all”. Це не «помірковано», це «будь ласка, підробляйте мене».
• Використовуйте “~all” тільки під час міграції. Softfail — навчальне колесо; зрештою потрібен “-all”.
• Володійте доменом для зворотних повідомлень (Return-Path). Якщо ви відправляєте через вендора, але хочете DMARC-врівнювання, плануйте це завчасно.

DKIM: криптографічна підзвітність, якщо ви її не ламаєте

DKIM підписує частини повідомлення (заголовки й тіло) за допомогою приватного ключа. Публічний ключ живе в DNS під селектором. Отримувачі перевіряють підпис. DKIM дає стабільну ідентичність, навіть коли IP змінюються — за умови, що підписене не змінюється в дорозі.

Операційні поради:

• Підписуйте на фінальному вихідному хопі. Якщо проміжний MTA переписує контент після підписання, ви щойно підписали неправду.
• Ротируйте селектори. Не щодня. Але ставтеся до ключів як до облікових даних з життєвим циклом.
• Підписуйте потрібні заголовки: From, Date, Subject, Message-ID — звично. Уникайте надмірного підписування вразливих заголовків, які можуть переписуватися.
• Використовуйте 2048-бітні ключі, де можливо. Деякі отримувачі трактують коротші ключі як слабший сигнал.

DMARC: вирівнювання, політика і те, що не підробиш

DMARC пов’язує все докупи. Він каже отримувачам: якщо SPF і/або DKIM аутентифікуються, чи вони вирівнюються з доменом у видимому From? І що робити отримувачу, якщо вирівнювання не пройшло?

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

• DMARC стосується видимого From: домену, який бачать люди. Саме його підробляють фішери.
• Вирівнювання — це головна суть: SPF може проходити для одного домену, коли From — інший. DMARC усе одно провалиться.
• Політика не означає примус, якщо ви цього не маєте на увазі: “p=none” — це телеметрія, а не захист, і провайдери можуть трактувати її як «несерйозно».
• Піддомени важливі: вирішіть, чи використовуєте організаційне вирівнювання доменів і наскільки суворо (“adkim=s”, “aspf=s”).

Жарт №1: SPF — як список гостей. DKIM — як браслет. DMARC — як швейцар, який перевіряє, чи браслет відповідає імені на квитку.

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

Цей розділ — те, що ви справді запускаєте. Кожне завдання містить: команду, реалістичний вивід, що це означає, і рішення, яке ви приймаєте.

Task 1: Pull the SPF TXT record and spot obvious footguns

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

Що це означає: SPF існує. Він авторизує одну IPv4 і include від вендора. Закінчується softfail (~all).

Рішення: Якщо міграцію завершено — переходьте на -all. Якщо ви ще виявляєте відправників, тимчасово залишайте ~all, але заплануйте кінцеву дату.

Task 2: Check SPF lookup count (the 10-DNS-lookup trap)

cr0x@server:~$ spfquery -m example.com -ip 198.51.100.10 -sender bounce@example.com -helo mail.example.com
pass (mechanism 'ip4:198.51.100.10' matched)
dns-lookup-count=7

Що це означає: SPF проходить для цього IP і залишається в межах 10 запитів.

Рішення: Якщо кількість запитів близька до 10, спростіть SPF (зменшіть вкладені include). Якщо більше 10 — виправте це насамперед; permerror вбиває доставку.

Task 3: Verify that your sending IP matches what the receiver sees

cr0x@server:~$ grep -E "postfix/smtp|status=sent" /var/log/mail.log | tail -n 2
Jan 03 10:12:08 mx1 postfix/smtp[21901]: 2F1C81234: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.102.26]:25, delay=1.2, delays=0.1/0/0.4/0.7, dsn=2.0.0, status=sent (250 2.0.0 OK  1704276728 a1e2b3c4d5e6-200si1234567qkb.123 - gsmtp)
Jan 03 10:12:08 mx1 postfix/qmgr[1123]: 2F1C81234: removed

Що це означає: Ви доставили до Gmail MX. Але це не доводить зовнішню вихідну IP (існують NAT і реле).

Рішення: Підтвердіть egress IP із сервера або через заголовки у отримувача. Якщо ви відправляєте через smart host, SPF має авторизувати smart host, а не сервер додатку.

Task 4: Confirm egress IP from the sending host

cr0x@server:~$ curl -s https://ifconfig.me
198.51.100.10

Що це означає: Публічна IP цього хоста — 198.51.100.10.

Рішення: Переконайтеся, що ця IP є в SPF і має PTR. Якщо ви очікували іншу IP, можливо, ви в пулі спільного NAT — погано для ізоляції репутації.

Task 5: Check reverse DNS (PTR) for your sending IP

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

Що це означає: PTR існує і вказує на mail.example.com.

Рішення: Якщо PTR відсутній — виправте це насамперед. Якщо PTR вказує на ISP-стандарт типу static-10-100-51-198.isp.net, подумайте про зміну; невідповідність ідентичності — ознака недовіри.

Task 6: Check forward DNS for the PTR hostname (FCrDNS sanity)

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

Що це означає: Форвардний запис резолвиться назад на ту ж IP. Багатьом отримувачам подобається така послідовність.

Рішення: Якщо форвард не збігається — виправте DNS. Якщо не можете (обмеження хмари), використайте їхній підтримуваний rDNS або перемістіть вихідну пошту в інше місце.

Task 7: Validate the DKIM public key exists for a selector

cr0x@server:~$ dig +short TXT s2026._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtYx...snip...QIDAQAB"

Що це означає: Селектор s2026 опублікований. Добре.

Рішення: Якщо відсутній — DKIM не пройде. Якщо ви бачите кілька TXT-строк через розбиття DNS, переконайтеся, що вони коректно конкатенуються (деякі системи це неправильно обробляють).

Task 8: Send a test message and inspect Authentication-Results

cr0x@server:~$ swaks --to you@outlook.com --from alerts@example.com --server mail.example.com --tls --header "Subject: auth test" --body "test"
=== Trying mail.example.com:25...
=== Connected to mail.example.com.
=== TLS started with cipher TLS_AES_256_GCM_SHA384
<** snip **>
<-  250 2.0.0 Ok: queued as 1234ABCD

Що це означає: Повідомлення прийнято вашим сервером для вихідної доставки. Тепер вам потрібні заголовки Received в Outlook.

Рішення: Отримайте джерело повідомлення з поштової скриньки і прочитайте Authentication-Results. Саме там — реальний вирок.

Task 9: Parse headers locally (quick and dirty)

cr0x@server:~$ sed -n '1,80p' message.eml
Authentication-Results: mx.microsoft.com;
 spf=pass (sender IP is 198.51.100.10) smtp.mailfrom=example.com;
 dkim=pass (signature was verified) header.d=example.com;
 dmarc=pass action=none header.from=example.com
Received: from mail.example.com (mail.example.com [198.51.100.10])
 by NAM11-MW2-obe.outbound.protection.outlook.com with ESMTPS id 123...
From: alerts@example.com
Return-Path: <bounce@example.com>

Що це означає: SPF, DKIM, DMARC проходять і вирівнюються (header.from — example.com; smtp.mailfrom — example.com; DKIM d=example.com).

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

Task 10: Detect DMARC alignment failure (the common “everything passes but DMARC fails” trap)

cr0x@server:~$ grep -E "Authentication-Results|From:|Return-Path:" -n message.eml | head -n 20
1:Authentication-Results: mx.google.com;
2: spf=pass (google.com: domain of bounce@vendor-mail.net designates 203.0.113.44 as permitted sender) smtp.mailfrom=bounce@vendor-mail.net;
3: dkim=pass header.d=vendor-mail.net;
4: dmarc=fail (p=quarantine sp=quarantine dis=none) header.from=example.com
12:From: Billing <billing@example.com>
13:Return-Path: <bounce@vendor-mail.net>

Що це означає: SPF і DKIM проходять, але для vendor-mail.net. DMARC оцінює вирівнювання стосовно example.com у видимому From. Вирівнювання не відбулося; DMARC провалився.

Рішення: Або налаштуйте вендора так, щоб він підписував з d=example.com (бажано), або використайте функцію вендора для власного домену bounce під example.com, або змініть From на домен, яким ви керуєте і який вирівнюється з аутентифікацією.

Task 11: Check your DMARC record

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

Що це означає: DMARC є, політика — quarantine, суворе вирівнювання для DKIM і SPF.

Рішення: Суворе вирівнювання підходить, якщо ваші системи дисципліновані. Якщо у вас багато сторонніх відправників і ви все ще стабілізуєтесь, розгляньте пом’якшення до adkim=r; aspf=r під час виправлення вирівнювання. Не тримайте lax назавжди.

Task 12: Confirm you publish a working MX and you’re not accidentally “parked”

cr0x@server:~$ dig +short MX example.com
10 mx1.example.com.
20 mx2.example.com.

Що це означає: Домен має MX-записи; це не мертва зона.

Рішення: Відсутність або дивні MX можуть вплинути на сприйняття та обробку відмов. Переконайтеся, що хоча б отримаєте відмови.

Task 13: Check your SPF for multiple TXT records (silent breakage)

cr0x@server:~$ dig TXT example.com +noall +answer
example.com. 3600 IN TXT "v=spf1 ip4:198.51.100.10 -all"
example.com. 3600 IN TXT "google-site-verification=abc123"

Що це означає: Це нормально: один SPF-запис плюс інший unrelated TXT.

Рішення: Якщо ви бачите два SPF-записи (дві TXT-строки, що починаються з v=spf1), SPF-оцінка стає permerror. Об’єднайте їх. Не «просто додайте ще один».

Task 14: Confirm Postfix is presenting a sane HELO name

cr0x@server:~$ postconf -n | grep -E "myhostname|smtp_helo_name"
myhostname = mail.example.com
smtp_helo_name = mail.example.com

Що це означає: HELO узгоджується з ім’ям хоста.

Рішення: Якщо HELO — щось на кшталт localhost або внутрішнього імені, виправте це. Багато отримувачів оцінюють це як «енергія ботнету».

Task 15: Make sure you’re not an open relay (yes, still happens)

cr0x@server:~$ swaks --server mail.example.com --to victim@external.com --from attacker@external.com --auth-user bogus --auth-password bogus
=== Trying mail.example.com:25...
<-  220 mail.example.com ESMTP Postfix
-> EHLO test
<-  250-mail.example.com
-> MAIL FROM:<attacker@external.com>
<-  554 5.7.1 <attacker@external.com>: Relay access denied

Що це означає: Реле відхилено. Добре.

Рішення: Якщо це успішно проходить без автентифікації з інтернету — вас занесуть до блоклистів до обіду. Негайно обмежте relay.

Task 16: Spot greylisting/throttling in logs

cr0x@server:~$ grep -iE "deferred|throttl|try again|4\.7\." /var/log/mail.log | tail -n 5
Jan 03 10:18:22 mx1 postfix/smtp[22555]: 9ABCD1234: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.102.27]:25, delay=120, delays=0.1/0/110/9.9, dsn=4.7.0, status=deferred (host gmail-smtp-in.l.google.com[142.250.102.27] said: 421 4.7.0 Temporary System Problem. Try again later (in reply to end of DATA command))

Що це означає: Тимчасове відкладення. Можливо, вас обмежують або ви досягли меж репутації, особливо з нових IP/доменів.

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

Пересилання, розсилки та ARC: куди вмирає хороша пошта

Пересилання — це будинок з привидами доставляємісті. Повідомлення, яке проходить SPF і DKIM у оригінального отримувача, може провалитися далі після пересилання, бо:

• SPF ламається: форвардер відправляє зі своєї IP, якої немає в оригінальному SPF.
• DKIM ламається: форвардер або список розсилки змінює тіло або заголовки (додає футери, змінює MIME, переписує тему).
• DMARC провалюється: вирівнювання неможливо задовольнити, якщо і SPF, і DKIM більше не валідні для домену у From.

ARC (Authenticated Received Chain) існує, щоб додати «ланцюг опіки». Форвардер може сказати: «Коли я отримав це повідомлення, SPF/DKIM/DMARC пройшли». Отримувачі можуть використати це як сигнал довіри. Не всі отримувачі однаково оцінюють ARC, але він допомагає в брудній зоні, де пересилання легітимне.

Що вам робити:

• Якщо ви керуєте інфраструктурою пересилання — розгляньте впровадження ARC-підписування.
• Якщо ви покладаєтеся на розсилки, будьте реалістичні: політики DMARC типу p=reject можуть спричинити проблеми з доставкою на списки, якщо список не переписує From або не підтримує DMARC-м’itigations.
• Для транзакційної пошти уникайте шляхів, які переписують контент після DKIM-підпису. Підписуйте наприкінці.

Репутація: IP, домен, контент і сигнали взаємодії

Коли аутентифікація правильна і вирівнювання налаштоване, доставка стає повільним нарощуванням довіри.

Репутація IP: район має значення

Виділена IP дає контроль над вашою репутацією. Спільна IP означає, що ви успадковуєте поведінку незнайомців. Інколи незнайомці нормальні. Інколи вони — перформанс-арт про ігнорування кнопки відписки.

Практичні поради:

• Прогрівайте нові IP: починайте з малого обсягу, поступово нарощуйте й орієнтуйтеся на найбільш залучених отримувачів.
• Розділяйте типи трафіку: транзакційна і маркетингова пошта не повинні ділити ідентичність, якщо можете уникнути. Коли маркетинг отримує скарги, транзакційна пошта не повинна платити за це.
• Будьте послідовні: раптові сплески, нові хости відправки та зміни в конвертах відправників виглядають як компрометація.

Репутація домену: повільно заробляється, швидко втрачається

Репутація домену слідує за вашим доменом у From, доменом підписання DKIM та інколи доменами посилань. Якщо ви міняєте домени, щоб обійти фільтри, ви навчаєте провайдерів, що поводитесь як спамери. Їх не вразить ваша креативність.

Контент: не «ізбягайте слів спаму», а уникайте спам-поведінки

Фільтри не тільки шукають ключові слова на кшталт «безкоштовно». Вони аналізують патерни, пов’язані з абузом:

• Скорочувачі посилань і ланцюги редиректів
• Відображуваний текст, що не відповідає реальному посиланню
• Листи, що складаються переважно з зображень з малою кількістю тексту
• Пошкоджений HTML і дивні MIME-структури
• Вкладення від невідомих джерел (особливо виконувані файли, документи з макросами або несподівані архіви)

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

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

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

Жарт №2: Якщо ви постійно пишете людям, які ніколи не відкривають, поштовий провайдер вважає, що ви або спамер, або оптиміст. Жодна з цих категорій не захищена.

Три корпоративні короткі історії з поля бою

Міні-історія 1: Інцидент через хибне припущення

Компанія: середній SaaS, стабільне зростання, один вихідний потік пошти для всього — скидання паролів, рахунки й щотижневі розсилки. Вони перенесли маркетингові розсилки до нового вендора, щоб «покращити доставляємість». План міграції був, м’яко кажучи, календарним запрошенням.

Хибне припущення було простим: «Якщо SPF і DKIM проходять, то DMARC теж пройде». Вендор надав include для SPF і DKIM-підписання для vendor-mail.net. Команда залишила видимий From як billing@example.com, бо бренд — святе.

Через кілька годин рахунки почали потрапляти в спам у частини клієнтів — переважно корпоративних із суворішими фільтрами й DMARC. Тікети підтримки надійшли потроху. Фінанси ескалували. SRE на чергуванні подивився логи Postfix і побачив чисті 250, що еквівалентно «працює на моїй машині».

Прорив стався після витягання сирих заголовків з поштової скриньки клієнта. Authentication-Results показав SPF=pass, DKIM=pass, DMARC=fail. DMARC політика для example.com була p=quarantine зі строгим вирівнюванням. SPF аутентифікував vendor-mail.net (домен Return-Path), DKIM аутентифікував vendor-mail.net (d=), і жоден не вирівнювався з From example.com.

Виправлення було не у «пом’якшенні DMARC, бо він ламає речі». Виправленням стало налаштування вендора на підписання DKIM з d=example.com (бажано) і створення спеціального bounce-домену під example.com, щоб забезпечити вирівнювання SPF. Вони поетапно впроваджували для кожного відправника, перевіряли вирівнювання в заголовках, а потім нарощували трафік. Доставляємість відновилась. Фінанси припинили ходити туди-сюди.

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

Компанія: B2C платформа з сезонними піками. Вони керували власним флотом MTA і хотіли знизити витрати. Хтось помітив, що вихідний трафік «сплесковий», і запропонував консолідувати на менше серверів з більшим пропуском, підкріплених новим NAT-шлюзом. Чудово: менше інстансів, простіша операційка, менший рахунок.

Повернення удару: репутація IP впала. Раніше вихідна пошта йшла з декількох статичних IP зі стабільними PTR. Після консолідації пошта виходила з NAT-пулу, який змінювався під час масштабування. SPF все одно авторизовував реле, DKIM проходив, DMARC проходив. І все ж — зросла кількість спаму і відкладень.

Команда спочатку ганялася за змінами в контенті, потім пробувала «прогрівати» (без контролю, яка IP прогрівається). Вони додали більше повторів (що збільшило обсяг під час тротлінгу), і відкладення погіршилися. Класичне позитивне зворотне коло, тільки результат — «усі листи запізнюються і підозрілі».

Вирішення вимагало визнання, що оптимізація — причина. Вони повернули вихідну пошту на невеликий набір відданих статичних egress IP з правильними PTR і послідовним HELO, і контролювали конкурентність. Витрати трохи зросли. Доставляємість і затримка покращилися значно. Урок засвоєно: електронна пошта — система репутації; непередбачуваність дорога.

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

Компанія: постачальник корпоративного ПЗ. У них було кілька команд, які відправляли листи: продуктові нотифікації, служба підтримки і маркетинг. Роками тому хтось, хто любив «управління», наполіг на центральному інвентарі ідентичностей пошти: кожен відправник, кожен домен, кожен вендор, кожен DKIM-селектор і точні SPF-механізми. Це зберігалося в системі контролю версій. Люди бурчали.

Потім вендор постраждав від витоку, і служба безпеки запитала: «Чи використовуємо ми будь-якого з цих відправників?» Вони використовували. Гірше того — цей вендор міг відправляти з From, що виглядало як частина компанії, бо інтеграція в поспіху була налаштована вільно.

Оскільки інвентар був, вони швидко визначили, які потоки використовують вендора, які домени постраждали і яка у них автентикаційна постава. Вони посилили DMARC на піддомені, який використовувався лише для стороннього маркетингу, ввели суворе вирівнювання для критичної транзакційної пошти і ротували селектори DKIM там, де потрібно.

Доставляємість не постраждала під час змін, бо вони робили їх обережно, перевіряли заголовки на вирівнювання і уникали ризикованих змін під час піків. «Нудна» практика — документована власність і контрольовані зміни DNS — дозволила діяти швидко без вгадувань. Героїчного постмортему ніхто не писав. У цьому і суть.

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

1) “SPF pass, DKIM pass, still DMARC fail”

Симптом: Authentication-Results показує spf=pass, dkim=pass, але dmarc=fail.

Корінь: Невідповідність вирівнювання. SPF аутентифікував домен Return-Path (часто це домен вендора). DKIM аутентифікував d=vendor. From — ваш домен.

Виправлення: Налаштуйте власний bounce-домен під вашим доменом для вирівнювання SPF і/або DKIM-підписання з d=yourdomain. Перевірте вирівнювання в заголовках.

2) “SPF permerror”

Симптом: Результат SPF — permerror, або отримувачі трактують його як помилку.

Корінь: Більше ніж 10 DNS-запитів через вкладені include, редиректи або макроси; або наявність кількох SPF-записів.

Виправлення: Вирівняйте SPF. Видаліть зайві include. Об’єднайте в один SPF-запис. Тримайте кількість запитів значно нижче 10.

3) “DKIM fail only at some providers”

Симптом: DKIM проходить у одного провайдера, але падає в іншого, або проходить періодично.

Корінь: Нерівномірна DNS-пропагація, розбиття TXT, або проміжні модифікації після підписання (футери списку розсилки, шлюзи безпеки, переписування CRM).

Виправлення: Переконайтеся, що DNS повертає стабільний ключ усюди. Підписуйте на фінальному вихідному хопі. Уникайте переписування підписаних частин. Розгляньте пом’якшену канонізацію, але не використовуйте її як пластир для дикого переписування.

4) “Everything passes; still spam”

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

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

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

5) “Messages disappear, no bounce”

Симптом: Логи відправника показують прийняття, але отримувачі ніколи не бачать повідомлення (навіть у спамі), і немає NDR.

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

Виправлення: Використовуйте тестові облікові записи по всіх провайдерах, щоб збирати заголовки і розміщення. Зменшіть обсяг, виправте аутентифікацію/вирівнювання і працюйте з репутацією. Переконайтеся, що відмови маршрутизуються і обробляються коректно.

6) “Forwarded mail fails DMARC”

Симптом: Лист, що надіслано на форвардер (або список розсилки), відхиляється або потрапляє в спам далі по ланцюгу.

Корінь: SPF ламається при пересиланні, DKIM ламається при модифікації; DMARC провалюється.

Виправлення: Для власного пересилання впровадьте ARC і уникайте ламання DKIM. Для списків розсилки використовуйте DMARC-дружню поведінку (переписування From або інші пом’якшення), якщо ви ними керуєте.

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

Checklist A: Stabilize authentication and alignment (the “stop bleeding” plan)

1. Виберіть ідентичність, яку ви дійсно хочете: вирішіть канонічні домени From для транзакційних і для маркетингових.
2. Зробіть інвентар усіх відправників: сервери додатків, системи тикетингу, CRM, маркетингові платформи, інструменти моніторингу.
3. Гарантуйте один SPF-запис на домен і тримайте кількість запитів нижче 10.
4. Забезпечте DKIM-підписання для кожного потоку, бажано з d=, що відповідає домену From (або вирівняному піддомену).
5. Розгорніть DMARC з телеметрією спочатку: почніть з p=none лише щоб зібрати реальність.
6. Виправте невідповідності вирівнювання для кожного відправника: кастомні bounce-домени, кастомні DKIM-домени або змініть From-домени.
7. Перейдіть до примусу: p=quarantine, потім p=reject, коли впевнені.
8. Закріпіть стратегію піддоменів: відокремте піддомени для маркетингу і транзакцій з відповідними політиками.

Checklist B: Transport and identity hygiene (the “look like a real mail system” plan)

1. Налаштуйте стабільні вихідні IP де можливо; уникайте NAT-пулів для основної ідентичності пошти.
2. Налаштуйте PTR так, щоб він відповідав імені вашого поштового хоста; переконайтеся, що форвардний DNS відповідає IP.
3. Встановіть HELO/EHLO на дійсне ім’я хоста і тримайте його послідовним між MTA.
4. Правильно пропонуйте STARTTLS; уникайте зламаних TLS-конфігів, що викликають fallback-патерни.
5. Обробляйте відмови: обробляйте DSN, видаляйте жорсткі відмови і досліджуйте сплески.
6. Тримайте черги вихідних повідомлень здоровими; великі затримки можуть викликати підозру і скарги («ваша пошта прийшла через два дні»).

Checklist C: Reputation and volume management (the “earn trust” plan)

1. Сегментуйте трафік: транзакційна на власній ідентичності та діапазоні IP, якщо можете.
2. Прогрівайте: нарощуйте обсяг поступово; починайте з найбільш залучених адресатів.
3. Гігієна списків: видаляйте жорсткі відмови негайно; відмовтеся від неактивних отримувачів.
4. Робоче відписування: зробіть його простим; зламаний unsubscribe — джерело скарг.
5. Санація контенту: послідовні шаблони, мінімум редиректів посилань, коректний MIME і уникнення підозрілих вкладень.
6. Вимірюйте розміщення: тестові скриньки, збір заголовків, відстеження спаму проти інбоксу по провайдерах.

Питання й відповіді

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

Бо аутентифікація доводить ідентичність, а не бажаність. Потрапляння в спам може бути спричинене репутацією (домена/IP), рівнем скарг, гігієною списку, сплесками обсягу та шаблонами контенту.

2) Чи варто відразу ставити DMARC p=reject?

Ні, якщо ви не знаєте всіх легітимних відправників, які мають вирівнюватися. Почніть з p=none, щоб побачити, хто відправляє, виправте вирівнювання, потім переходьте до quarantine і reject.

3) Що означає вирівнювання DMARC насправді?

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

4) Що важливіше для DMARC — SPF чи DKIM?

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

5) Чому пересилання ламає SPF?

SPF перевіряє, чи авторизована IP-адреса відправника для домену в конверті. Коли форвардер ретранслює лист, IP стає IP форвардера, якого зазвичай немає в оригінальному SPF.

6) У чому різниця між Return-Path і From?

From — те, що бачать користувачі і куди вони відповідають. Return-Path (envelope sender) — куди йдуть відмови. SPF за замовчуванням аутентифікує Return-Path; DMARC оцінює вирівнювання з From.

7) Чи можна мати кілька SPF-записів?

Ні. Один SPF-запис на домен. Кілька TXT-рядків, що починаються з v=spf1, зазвичай призводять до permerror, який отримувачі трактують як провал.

8) Чи потрібна мені виділена IP?

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

9) Чи мають маркетинг і транзакційна пошта ділити домен?

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

10) Який найшвидший шлях, якщо ми раптово в спамі?

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

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

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

Практичні наступні кроки:

1. Зберіть три реальні джерела повідомлень з уражених скриньок (Gmail, Outlook і один корпоративний домен, якщо можливо). Порівняйте Authentication-Results і вирівнювання.
2. Явно визначте вирівнювання: вирішіть, чи стандартом для кожного відправника буде SPF-врівнювання bounce-доменів і/або DKIM-врівнювання доменів підписання.
3. Стабілізуйте ідентичність інфраструктури: PTR, форвардний DNS, HELO і послідовні вихідні IP.
4. Відокремте ризики: розділіть транзакційну і маркетингову ідентичності, щоб одна погана кампанія не спалила скидання паролів.
5. Гігієна важливіша за героїчні заходи: припиніть писати тим, хто не взаємодіє, обробляйте відмови і знижуйте рівень скарг. DNS не врятує список, який вас ненавидить.

Доставляємість електронної пошти — нудна, коли все в порядку, і дорога, коли ні. Стріляйте на нудне.