Проблеми доставки в Gmail і Outlook: ключові перевірки 2025

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

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

Швидкий план діагностики (перші 15 хвилин)

Коли доставка в Gmail або Outlook «раптом» ламається, виникає спокуса панічно налаштовувати все одразу. Не робіть цього. Потрібно знайти вузьке місце: автентифікація, репутація, контент чи транспорт.

0. Встановіть режим збою (2 хвилини)

• Відмова (bounce): ви отримали NDR/DSN назад. Добре — там є підказки.
• Відкладення (deferral): відповіді 4xx; пошта сидить у черзі і «може зрештою» доставитися.
• Спам: доставлено, але в спамі; це часто політика + репутація.
• Мовчазна відсутність: система каже «доставлено», а отримувач не знаходить лист. Це може бути спам/карантин, відмови на транспорті або внутрішні правила маршрутизації.

1. Спочатку перевірте вирівнювання автентифікації (5 хвилин)

У 2025 році проходження SPF чи DKIM недостатнє. Важливе вирівнювання з видимим доменом From, особливо для Gmail і Microsoft.

1. Візьміть реальний лист і подивіться Authentication-Results.
2. Підтвердіть DKIM=pass для вашого домену (або вирівняного субдомену).
3. Підтвердіть SPF=pass і що домен SPF вирівнюється з From (або охоплюється релаксованим вирівнюванням DMARC).
4. Перевірте DMARC=pass. Якщо DMARC зазнає невдачі, все інше — гра в кості.

2. Далі перевірте сигнали репутації (4 хвилини)

• Раптовий сплеск відмов, скарг або «невідомих користувачів»? Це швидке вбивство репутації.
• Новий відправний IP або зміна провайдера? Прогрів має значення. Так, навіть якщо ви «лише надсилаєте квитанції».
• Чи є ви в чорних списках? Вам не потрібен PhD — просто перевірте SMTP-логи на відмови у стилі RBL.

3. Лише потім перевіряйте транспорт (4 хвилини)

• Чи не порушується TLS-узгодження, перевірки MTA-STS або чи не отримуєте лімітні відповіді?
• Чи росте ваша черга і чи відкладаються повторні спроби?
• Чи вихідні з’єднання походять з тієї IP-адреси, яку ви думаєте?

Якщо виконати ці три кроки в порядку, ви уникнете класичного інциденту, коли всі сперечаються про контент, поки у вас в DNS відсутній DKIM-селектор.

Як доставка ламається у 2025 році (і чому це здається випадковим)

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

Сучасна пошта керується політиками

Вимоги Gmail до масових відправників (і посилена фільтрація Microsoft) підштовхнули індустрію до базового стандарту: автентифікована пошта, гігієна списків, менеджмент скарг і стабільна інфраструктура. Це не «маркетингові штуки». Це операційна гігієна. Ваша поштова система — це API, а провайдери входу — одні з найвибагливіших API-шлюзів, з якими вам доведеться інтегруватися.

Чотири категорії відмов

1. Автентифікація: неправильно налаштовані SPF/DKIM/DMARC, пошкодження через DNS або прострільні пересилання/переписування.
2. Репутація: новий IP/домен, скарги, багато невідомих користувачів, скомпрометовані акаунти або бурсті патерни відправлення.
3. Контент і форматування: підозрілі URL, пошкоджений MIME, відсутній List-Unsubscribe, дивні кодування або надто «ідеальні» шаблони.
4. Транспорт і політика: помилки TLS, застосування MTA-STS, ліміти, відкладення 4xx або мережеві блоки.

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

Цитата, яку варто повісити на стіні

Надія — це не стратегія. — Генерал Гордон Р. Салліван

Правило відладки доставлюваності таке саме. Якщо ви не можете довести це заголовками, логами і DNS — ви керуєтеся «відчуттями».

Цікаві факти та історичний контекст (видання про доставку)

• SPF починався як механізм проти підробки, а не як інструмент для підвищення доставлюваності. Його створили, щоб зменшити спуфінг, прив’язавши «хто може надсилати» до записів DNS.
• DKIM з’явився з експериментів підписування домену (включно з DomainKeys та Identified Internet Mail) і став способом зберегти цілісність через переходи — поки проміжні вузли не почали змінювати повідомлення.
• DMARC формалізував «вирівнювання»: недостатньо просто аутентифікуватись; аутентифікований домен має збігатися (вирівнюватися) з доменом From, який бачить отримувач.
• Google і Microsoft навчились недовіряти «ідеальним відправникам»: надзвичайно однорідний контент або неприродні патерни залучення можуть бути червоним прапором, навіть для легітимної транзакційної пошти.
• Репутація IPv4 стала продуктом: спільні пулі IP і виділені IP існують переважно через те, що провайдери входу агресивно оцінюють історію IP.
• ARC (Authenticated Received Chain) з’явився тому, що пересилання ламає SPF і може зламати DKIM; ARC дозволяє проміжним вузлам зберігати результати автентифікації через переходи.
• BIMI — це брендова фішка з наслідками: вона підштовхує відправників до суворішої політики DMARC, бо відображення логотипу вимагає міцнішої позиції політики.
• Спам-фільтри перейшли від ключових слів до моделей поведінки: взаємодія користувачів (відкриття, видалення, відповіді, позначення як спам) впливає на подальше розміщення.
• List-Unsubscribe став операційним контролем: провайдери входу використовують його, щоб зменшити кліки «це спам», пропонуючи чисте відписування.

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

Заголовки й коди відмов: припиніть гадати, почніть читати

Якщо ви не читаєте сирі заголовки й DSN, ви діагностуєте з пов’язкою на очах. Gmail і Microsoft обидва включають достатньо метаданих, щоб сказати, що саме зазнало невдачі — якщо ви знаєте, куди дивитися.

Заголовки, які мають значення

• Authentication-Results: проходження/помилки SPF/DKIM/DMARC і іноді причини.
• Received ланцюг: підтверджує хост відправника і чи переписував шлюз повідомлення.
• From, Return-Path, Sender: використовуються для вирівнювання й маршрутизації відмов.
• Message-ID: корисний для кореляції з логами; також говорить, чи генерує ваш додаток дивні ID.
• List-Unsubscribe і List-Unsubscribe-Post: дедалі важливіше для масової пошти; відсутні заголовки можуть нашкодити.

SMTP статус-коди: що вони означають операційно

• 5xx: відхилено. Це не проблема повторних спроб. Виправляйте причину.
• 4xx: відкладено / тимчасово. Часто це лімітування, м’які блоки по репутації або тимчасові політичні перевірки. Стратегія повторних спроб має значення.
• 2xx прийнято: прийнято MTA отримувача, але не обов’язково в папку «Вхідні». Для питань розміщення в папці Вхідні зосередьтесь на автентифікації + репутації + контенті.

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

Нижче наведені задачі виробничого рівня, які ви можете виконати сьогодні. Кожна містить: команду, приклад виводу, що це означає і яке рішення з цього випливає. Припускається Linux-поштова хоста з Postfix (поширено), але аналіз DNS і повідомлень підходить скрізь.

Завдання 1 — Визначте реальний egress IP (не те, що ви «думали»)

cr0x@server:~$ curl -s ifconfig.me
203.0.113.45

Що це означає: Це публічна IP-адреса, яку бачать отримувачі (якщо ви не ретраите через провайдера).

Рішення: Вся репутація, rDNS/PTR і allowlist мають відповідати цій IP. Якщо ви очікували іншу IP, зупиніться: ви налагоджуєте неправильну ідентичність відправника.

Завдання 2 — Підтвердіть зворотний DNS (PTR) і відповідність стратегії HELO

cr0x@server:~$ dig +short -x 203.0.113.45
mail1.example.com.

Що це означає: IP вказує на mail1.example.com.

Рішення: Налаштуйте Postfix smtpd_banner/myhostname і вихідний smtp_helo_name так, щоб HELO/EHLO був дійсним іменем хоста, яке вперед резолвиться на ту ж IP. Якщо PTR відсутній — виправте; Microsoft особливо не любить відсутній rDNS.

Завдання 3 — Перевірте форвардний DNS для імені відправника (A/AAAA)

cr0x@server:~$ dig +short mail1.example.com A
203.0.113.45

Що це означає: Ім’я вперед резолвиться назад на IP.

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

Завдання 4 — Перегляньте SPF-запис і ризик «занадто багато DNS-запитів»

cr0x@server:~$ dig +short TXT example.com | sed 's/" "/""/g'
"v=spf1 include:_spf.google.com include:spf.protection.outlook.com ip4:203.0.113.45 -all"

Що це означає: SPF дозволяє Google, Microsoft і конкретну IP.

Рішення: Підтвердіть, що ваші фактичні джерела надсилання відповідають цьому. Якщо у вас багато механізмів include:, ви можете перевищити ліміт 10 DNS-запитів SPF. Якщо SPF періодично дає «permerror», спростіть SPF (обережно «флеттенуйте» або зменшіть включення).

Завдання 5 — Перевірте SPF для конкретної IP локальним чекером

cr0x@server:~$ spfquery -ip 203.0.113.45 -sender bounce@example.com -helo mail1.example.com
result=pass
smtp.comment=domain of bounce@example.com designates 203.0.113.45 as permitted sender

Що це означає: SPF проходить для домену відправника конверта.

Рішення: Якщо це не так — виправте SPF. Якщо пройшло, але DMARC далі не проходить, проблема в вирівнюванні (домен конверта ≠ домен From, або релаксоване вирівнювання не задовольняється).

Завдання 6 — Перевірте, чи існують DKIM-селектори в DNS

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

Що це означає: Селектор s1 існує і публікує публічний ключ.

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

Завдання 7 — Переконайтесь у політиці DMARC і режимі вирівнювання

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=r; pct=100"

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

Рішення: Якщо ви використовуєте сторонніх відправників, суворе DKIM-вирівнювання (adkim=s) може їх ламати, якщо вони не підписують вашим доменом. Вирішіть, чи ослабити вирівнювання, чи налаштувати відправників на підпис з вирівняним DKIM.

Завдання 8 — Витягніть живий лист з логів (Postfix) і перегляньте відповідь від Gmail/Microsoft

cr0x@server:~$ sudo grep -E "to=|status=" /var/log/mail.log | tail -n 20
Jan  3 10:17:12 mail1 postfix/smtp[24177]: 8F2C02A1B3: to=, relay=gmail-smtp-in.l.google.com[142.250.102.27]:25, delay=2.1, delays=0.2/0.1/1.2/0.6, dsn=2.0.0, status=sent (250 2.0.0 OK  1704277032 x12-20020a1709032f4c00b003b7c2c1a8d3si1234567plb.123 - gsmtp)
Jan  3 10:18:44 mail1 postfix/smtp[24210]: 1B7D02A1C9: to=, relay=outlook-com.olc.protection.outlook.com[104.47.15.36]:25, delay=45, delays=0.3/0.2/10/34, dsn=4.7.0, status=deferred (host outlook-com.olc.protection.outlook.com[104.47.15.36] said: 451 4.7.0 Temporary server error. Please try again later. PRX4 (in reply to MAIL FROM command))

Що це означає: Gmail прийняв; Microsoft відклав з тимчасовою помилкою 4.7.0.

Рішення: Проблеми з Gmail швидше про розміщення в папках, а не транспорт. Для Outlook — перевірте лімітування, репутацію і чи ви надсилаєте в піки. Не «виправляйте» збільшенням частоти повторних спроб; це часто погіршує троттлінг.

Завдання 9 — Перегляньте чергу Postfix на застряглі або вибухові повідомлення

cr0x@server:~$ mailq | head -n 25
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
1B7D02A1C9      4123 Fri Jan  3 10:18:44  bounce@example.com
                                         user@outlook.com
                                         (host outlook-com.olc.protection.outlook.com[104.47.15.36] said: 451 4.7.0 Temporary server error. Please try again later. PRX4 (in reply to MAIL FROM command))

-- 1 Kbytes in 1 Request.

Що це означає: У вас є відкладені повідомлення, що чекають на Outlook.

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

Завдання 10 — Підтвердіть, що ви підписуєте DKIM ті повідомлення, які вважаєте підписаними

cr0x@server:~$ sudo postcat -q 8F2C02A1B3 | sed -n '1,80p'
*** ENVELOPE RECORDS ***
message_size:            38912            392
sender: bounce@example.com
*** MESSAGE CONTENTS ***
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s1;
 t=1704277032; bh=7yQf...; h=from:to:subject:date:mime-version;
 b=Z1m...
From: Example Billing 
To: user@gmail.com
Subject: Your receipt

Що це означає: Повідомлення підписано DKIM з d=example.com, селектор s1.

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

Завдання 11 — Перевірте TLS-рукопотискання і сертифікат для MTA отримувача

cr0x@server:~$ openssl s_client -starttls smtp -connect gmail-smtp-in.l.google.com:25 -servername gmail-smtp-in.l.google.com -tls1_2 </dev/null | sed -n '1,25p'
CONNECTED(00000003)
depth=2 C=US, O=Google Trust Services LLC, CN=GTS Root R1
verify return:1
depth=1 C=US, O=Google Trust Services LLC, CN=GTS CA 1C3
verify return:1
depth=0 CN=gmail-smtp-in.l.google.com
verify return:1
---
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256

Що це означає: Отримувач підтримує сучасний TLS; ваш бік теж має це робити.

Рішення: Якщо ваш вихідний MTA погоджується на застарілий TLS або не вдається STARTTLS, ви бачитимете більше відкладень і політичних помилок. Оновіть бібліотеки й Postfix, переконайтесь, що ваша політика шифрів не застрягла у 2014 році.

Завдання 12 — Перевірте, чи домен публікує MTA-STS і чи він парситься

cr0x@server:~$ dig +short TXT _mta-sts.example.com
"v=STSv1; id=20250101T120000Z"

Що це означає: Ви публікуєте ідентифікатор політики MTA-STS.

Рішення: Якщо ви заявляєте MTA-STS, але хост політики зламаний, це може викликати проблеми з доставкою до вас (а не з вихідною доставкою). Вартує перевірити, бо тікети «електронна пошта зламана» рідко вказують напрямок.

Завдання 13 — Перевірте стан локального DNS (бо пошкоджені резолвери ламають SPF/DKIM)

cr0x@server:~$ resolvectl status | sed -n '1,35p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.0.0.53
       DNS Servers: 10.0.0.53 1.1.1.1

Що це означає: Ваш MTA залежить від цих резолверів для перевірок SPF/DKIM/DMARC.

Рішення: Якщо у вас періодичні проблеми з доставкою, перевірте таймаути резолверів і підміни NXDOMAIN. Використовуйте надійні резолвери і подумайте про локальне кешування (unbound) з розумними таймаутами.

Завдання 14 — Підтвердіть ваше ім’я HELO (Postfix) — те, що ви планували

cr0x@server:~$ postconf smtp_helo_name myhostname | sed 's/^/postfix: /'
postfix: smtp_helo_name = mail1.example.com
postfix: myhostname = mail1.example.com

Що це означає: Ваш вихідний сервер представляється як mail1.example.com.

Рішення: Якщо ви бачите загальний HELO, як-от localhost або внутрішнє ім’я хоста — виправте. Це не завжди фатально, але виглядає як «некерована» інфраструктура для систем оцінки репутації.

Завдання 15 — Швидко помітить високі показники відмов/невідомих користувачів (вибірка логів)

cr0x@server:~$ sudo grep -E "status=bounced|5\.1\.1|User unknown" /var/log/mail.log | tail -n 15
Jan  3 10:10:02 mail1 postfix/smtp[23910]: 9A1F12A0D2: to=, relay=outlook-com.olc.protection.outlook.com[104.47.15.36]:25, delay=3.2, dsn=5.1.1, status=bounced (host outlook-com.olc.protection.outlook.com[104.47.15.36] said: 550 5.1.1 RESOLVER.ADR.RecipNotFound; Recipient not found (in reply to RCPT TO command))

Що це означає: Ви відправляєте на неіснуючі адреси.

Рішення: Зупиніть втрати. Призупиніть масові розсилки, почистіть списки і впровадьте валідацію адрес при їхньому зборі. Високі показники 5.1.1 швидко руйнують репутацію, особливо на Microsoft.

Завдання 16 — Підтвердіть, що ви додаєте заголовки List-Unsubscribe для масових листів

cr0x@server:~$ sudo postcat -q 7C0A12A19F | grep -i -E '^List-Unsubscribe:|^List-Unsubscribe-Post:'
List-Unsubscribe: , 
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Що це означає: Масові повідомлення надають чисті опції для відписки.

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

Жарт №2: Якщо ваш SPF має 14 include, це не «безпека», а інтерпретативний DNS-танець.

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

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

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

Запустили новий бренд-домен. Маркетинг оновив видимий From: на billing@newbrand.example скрізь. Вони не торкнулися конверт-домена, який залишився bounce@oldbrand.example. SPF проходив. DKIM проходив (за старим доменом). DMARC падав. Тихо, послідовно і катастрофічно.

Неправильне припущення було тонким: «Якщо SPF і DKIM проходять, DMARC теж пройде». Це не так. DMARC дивиться на вирівнювання з доменом From, який бачить користувач. Видимість змінилась; автентифікована ідентичність — ні.

Симптоми були негарні і збиваючі з пантелику: Gmail класифікував у спам, Outlook деяку пошту відкладав і переправляв у смітник, а внутрішні зацікавлені сторони наполягали, що причина в «контенті», бо шаблон змінився того тижня.

Виправлення було нудним і миттєвим: або підписувати DKIM з d=newbrand.example і вирівняти конверт-домен, або використати релаксоване вирівнювання з контрольованою стратегією субдоменів. Коли DMARC почав надійно проходити, розміщення відновилося протягом кількох днів, а не хвилин. Системи репутації пам’ятають; вони не золота рибка.

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

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

Це спрацювало, поки не надійшов квартальний маркетинговий бюлетень. Залучення було посереднім, кількість відписок зросла, і невелика частина отримувачів натиснула «повідомити як спам», бо лист виглядав незнайомим. Наступного дня скидання паролів почали потрапляти в спам у Gmail і відкладалися в Microsoft.

Вони створили репутаційне пов’язання: найгіршоповедінковий потік пошти отруїв найважливіший бізнес-потік. Інцидент був дорогим, але урок — безцінним: розділяйте трафік за ризиком.

План відновлення не був магією. Вони розділили відправлення: один IP/домен для транзакційних листів, інший для маркетингу, з різними лімітами і суворішою гігієною списків для маркетингу. Також впровадили списки пригнічення і перестали надсилати тим, хто не взаємодіяв місяцями. Доставлюваність поступово повернулась, і ротація on-call перестала ставити дні кампаній у ранг ураганного періоду.

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

Велика B2B-платформа мала звичку, яка здавалася бюрократичною: кожна зміна DNS для автентифікації пошти вимагала peer review і «canary check» на staging-домені. Ніхто цього не любив. Всі погоджувались.

Одного п’ятничного дня інженер, що хотів як краще, намагався повернути ключі DKIM і почистити «старі селектори». Рев’ю помітило, що спадковий додаток ще підписує селектором s0, бо він був захардкочений в конфіг, що жив у контейнерному образі, який ніхто не хотів пересборювати.

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

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

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

Контрольний список A — Якщо користувачі Gmail повідомляють «не отримують»

1. Отримайте один реальний приклад отримувача: Message ID, часову позначку, домен отримувача і чи шукали в «Усі листи» і «Спам».
2. Визначте: відмова, відкладення чи доставлено по ваших логах.
3. Витягніть сирі заголовки з доставленого зразка і підтвердіть проходження DMARC і вирівнювання.
4. Перевірте DNS селектора DKIM на предмет існування і стабільності (немає періодичних NXDOMAIN).
5. Підтвердіть стабільність IP відправлення: немає несподіваних змін NAT, немає нових ретрансляторів.
6. Оцініть гігієну списків, якщо це масова розсилка: невідомі користувачі й скарги зруйнують вас.
7. Сегментуйте потоки: тримайте транзакційні окремо від маркетингових, якщо цінуєте сон.

Контрольний список B — Якщо Outlook/Microsoft відкладає або відхиляє

1. Читайте розширений SMTP-код стану: 4.7.x (троттл), 5.7.x (політика/автентифікація), 5.1.1 (некоректні отримувачі).
2. Перевірте rDNS і HELO: Microsoft не сентиментальний до неправильно налаштованих відправників.
3. Згладьте та обмежте: бурстові відправлення викликають відкладення; знизьте паралелізм і нарощуйте поступово.
4. Перевірте на скомпрометовані акаунти: відкладення Microsoft часто збігаються з раптовими сплесками від однієї ідентичності відправника.
5. Розділіть bulk і transactional по IP/домену, якщо ще цього не зробили.
6. Підтвердіть вирівнювання DKIM/DMARC і що заголовки не переписуються проміжними ретрансляторами.

Контрольний список C — Базова автентифікація для 2025 року (зробіть один раз, потім моніторте)

• SPF: мінімум include; -all коли будете впевнені; тримайтеся в межах 10 DNS-запитів.
• DKIM: 2048-бітні ключі де можливо; ротація; документуйте селектори.
• DMARC: почніть з p=none для спостереження, потім quarantine, а далі reject, коли потоки вирівняні і чисті.
• Стратегія вирівнювання: вирішіть, чи From використовує кореневий домен або виділений субдомен; тримайте послідовність.
• ARC: якщо ви надаєте служби пересилання (helpdesk, тикетинг), впровадьте ARC, щоб зберегти довіру автентифікації.
• List-Unsubscribe: додавайте для масових розсилок; підтримуйте one-click, якщо можете.

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

Це помилки, які я бачу повторно в продакшні. Вони не гламурні, але саме вони причина того, що ваша пошта «все гаразд у staging», а в реальному житті — проклята.

1) Симптом: Gmail приймає (250 OK), але користувачі знаходять лист у Спамі

• Корінь: DMARC падає або проходить непослідовно; репутація відправника погіршена; відсутні масові заголовки.
• Виправлення: Зробіть DMARC проходження вирівняним через SPF або DKIM. Додайте List-Unsubscribe для масових листів. Розділіть маркетинг і транзакційні потоки. Перестаньте надсилати на холодні списки.

2) Симптом: Outlook повертає 451 4.7.0 тимчасову помилку для багатьох отримувачів

• Корінь: Троттл через репутацію, сплески відправлень або погана IP-гігієна (rDNS/HELO mismatch).
• Виправлення: Згладьте відправлення (зменшіть паралелізм, стабілізуйте каденс). Виправте rDNS і HELO. Розділіть потоки. Почистіть списки з великою кількістю відмов.

3) Симптом: «SPF проходить», але DMARC падає

• Корінь: Домен SPF — це домен конверта, який не вирівнюється з From.
• Виправлення: Використовуйте вирівняний return-path домен (або субдомен) і переконайтесь, що SPF авторизує фактичне джерело; або покладайтесь на вирівняний DKIM, щоб DMARC пройшов.

4) Симптом: DKIM іноді падає лише для певних типів повідомлень

• Корінь: Множинні вихідні шляхи; один шлях не підписує, або ретранслятор змінює тіло/заголовки після підпису.
• Виправлення: Централізуйте підписування на останньому довіреному хопі. Переконайтесь, що канонізація підходить. Уникайте проміжних вузлів, які переписують контент після підпису.

5) Симптом: Раптовий крах після «чистки» DNS

• Корінь: Видалено активний DKIM-селектор; зламався ланцюжок include SPF; занадто агресивно змінено політику DMARC.
• Виправлення: Відновіть селектори. Впроваджуйте DMARC поступово (pct, моніторинг звітів). Ставтеся до DNS для автентифікації як до production-конфігу, а не до хобі.

6) Симптом: Високий рівень відмов (5.1.1) і потім все погіршується

• Корінь: Погана гігієна списків; старі списки; опечатки; зловживання підпискою.
• Виправлення: Впровадьте suppression, валідацію і double opt-in там, де потрібно. Перестаньте надсилати тим, хто жорстко відхиляється — негайно і автоматично.

7) Симптом: Повідомлення зникають при пересиланні (особливо в Gmail)

• Корінь: Пересилання ламає SPF; DKIM зламано змінами; політика DMARC викликає відхилення/карантин.
• Виправлення: Заохочуйте сучасне пересилання з підтримкою ARC. Для власних сервісів пересилання впровадьте ARC і уникайте переписування контенту.

8) Симптом: Внутрішні тести проходять, зовнішні отримувачі — ні

• Корінь: Ви тестуєте проти лояльних внутрішніх MTA. Зовнішні провайдери застосовують суворішу політику і оцінку репутації.
• Виправлення: Тестуйте з реальними зовнішніми поштовими скриньками, аналізуйте заголовки і стадіруйте зміни автентифікації з canary-доменами.

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

1) «Ми не масовий відправник. Чи важливі Gmail-правила для масових?»

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

2) Якщо SPF проходить, чому Outlook все ще троттлить нас?

Бо SPF — це ідентичність, а не репутація. Троттл часто стосується патернів швидкості, невідомих користувачів, сигналів скарг і гігієни інфраструктури (rDNS/HELO). Проходження SPF не дає вам «швидкої смуги».

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

Лише якщо ви впевнені, що кожний легітимний потік вирівняний (SPF або DKIM) і ви досить довго аналізували звіти, щоб виявити дивні спадкові відправники. Інакше ви будете відхиляти власну пошту і називати це «безпекою».

4) Що важливіше у 2025 — DKIM чи SPF?

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

5) Чи може одна лише зміна контенту спричинити потрапляння в спам?

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

6) Чому деякі отримувачі отримують лист, а інші ні?

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

7) Який найкорисніший артефакт запросити у користувача?

Повні заголовки повідомлення, що опинилося в спамі, або точний текст bounce/NDR. Скриншоти — декорація; заголовки — доказ.

8) Чи допоможе нам зміна IP?

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

9) Ми використовуємо сторонню платформу для пошти. Що ми реально можемо контролювати?

Більше, ніж здається: стратегія From-доменів, вирівнювання DKIM, політика DMARC, гігієна списків, сегментація (транзакційні проти маркетингу), контент/домени посилань та каденс відправлення. Також ви контролюєте вибір shared vs dedicated IP і як відбувається onboarding/прогрів.

10) Чому «доставлені» дашборди не відповідають реальності?

Багато дашбордів означають «прийнято MTA отримувача», а не «потрапило в папку Вхідні». Розміщення в папці Вхідні — окремий результат. Використовуйте заголовки, зворотні цикли отримувачів (де є) і власні метрики взаємодії для валідації.

Висновок: наступні кроки, що витримають навантаження

Інциденти з доставкою відчуваються особистими, бо вони блокують гроші й довіру. Але виправлення механічні: доведіть ідентичність (вирівняні SPF/DKIM/DMARC), захищайте репутацію (гігієна і сегментація) і тримайте транспорт нудним (rDNS, forward DNS, ім’я HELO, та стабільна egress IP).

Наступні кроки, які реально змінюють ситуацію:

1. Візьміть один приклад збою (отримувач + часову позначку) і простежте його повністю через логи і заголовки.
2. Забезпечте постійне проходження DMARC з вирівнюванням. Не торгуйтесь з цією вимогою.
3. Розділіть транзакційні й масові потоки по IP і/або домену, і застосуйте суворішу гігієну до масових листів.
4. Стабілізуйте ідентичність інфраструктури: rDNS, форвардний DNS, HELO-ім’я і послідовна egress IP.
5. Додайте операційні запобіжники: рев’ю змін DNS, інвентар селекторів DKIM, моніторинг черг, алерти за рівнем відмов.

Провайдери входу не ваші друзі, але вони передбачувані, якщо ви ставитеся до пошти як до production-трафіку. Вимірюйте. Перевіряйте. Міняйте по одному елементу. І тримайте логи під рукою.