Покупець оплатив замовлення, але не отримав підтвердження. Інший клієнт утретє просить лист для відновлення пароля. Заявка з форми лежить у базі, а менеджер про неї не знає. Формально це проблеми з поштою. Для бізнесу — зламані етапи покупки, входу й продажу.
Не починайте зі слів у темі листа. Спершу доведіть, що сайт створив повідомлення, записав його в надійну чергу, надіслав від автентифікованого домену, прийняв статуси провайдера й не залишив людину без альтернативи. SPF, DKIM і DMARC потрібні, але самі собою не утворюють систему доставки.
З’ясуйте, що означає «лист не прийшов»
Між натисканням кнопки й скринькою працює кілька незалежних систем. Статус delivered у провайдера зазвичай означає лише, що поштовий сервер отримувача прийняв повідомлення. Він не доводить, що лист потрапив у «Вхідні», одразу з’явився або був прочитаний. І навпаки: проблема може виникнути ще до відправлення — сайт не створив задачу, в адресі помилка, попередня остаточна відмова (hard bounce) заборонила повторні спроби, а посилання вже втратило чинність.
| Етап | Що перевіряти | Типова відмова |
|---|---|---|
| Подія в бізнесі | Замовлення, акаунт, рахунок або заявка | Сценарій не запустився |
| Черга | ID задачі, час, кількість спроб | Обробник зупинився або задача зникла |
| Провайдер | Message ID та відповідь API | Запит відхилено, конфігурація неправильна |
| Сервер одержувача | Delivered, deferred, bounced, complaint | Автентифікація, репутація, політика, адреса |
| Дія людини | Оплату підтверджено, пароль змінено, файл завантажено | Спам, незрозумілий текст, прострочене посилання |
Підтримці потрібен один пошук за номером замовлення або ID акаунта. Він має показувати весь шлях без зайвого розкриття змісту: «створено о 14:03, двічі відкладено Outlook, прийнято о 14:11, можна повторити». Фраза «у нас пошта працює» не допомагає ні клієнтові, ні інженеру.
Знайдіть усіх відправників до змін у DNS
Навіть невелика компанія рідко надсилає з одного місця. Google Workspace або Microsoft 365 обслуговує працівників, CMS — форми, Shopify чи WooCommerce — замовлення, платіжний сервіс — квитанції, CRM — ланцюжки для лідів, helpdesk — тікети, бухгалтерський сервіс — рахунки. Один забутий інструмент може зламатися після посилення DMARC.
Складіть реєстр: власник, призначення, видима адреса From, домен Return-Path, домен підпису DKIM, провайдер, спосіб відправлення, приблизний обсяг, тип одержувачів і канал для bounce. Перевіряйте не лише кабінети й DNS, а й заголовки справжніх отриманих листів — саме вони показують, що відбувається насправді.
Відправник: інтернет-магазин
Листи: замовлення, відправлення, повернення
From: [email protected]
Return-Path: bounce.tx.example.com
DKIM: tx.example.com
Провайдер: [назва]
Власник події: ecommerce-команда
Webhook: [endpoint]
Резерв: сторінка замовлення + повторна відправкаНе вмикайте p=reject, доки не ідентифікували й не вирівняли легітимні джерела. Початковий p=none дає зведені звіти DMARC, але хтось має регулярно розбирати джерела, а не просто складати XML-файли в окрему скриньку.
Виконайте актуальні вимоги поштових сервісів
Актуальні правила Gmail вимагають від усіх відправників SPF або DKIM. Для доменів, що надсилають понад 5 000 листів на добу на особисті адреси Gmail, потрібні SPF, DKIM, DMARC, узгодженість видимого From, TLS та інші вимоги до інфраструктури й рівня скарг. Google рахує статус масового відправника на рівні основного домену й не скасовує його автоматично після зменшення обсягу.
Yahoo Sender Hub також вимагає щонайменше SPF або DKIM від усіх. Для масових відправників додаються SPF, DKIM, узгодження DMARC, справний DNS, низька частка скарг і просте відписування для маркетингових та підписних повідомлень. В офіційному FAQ транзакційні листи — наприклад, підтвердження замовлення й відновлення пароля — відокремлені від вимоги відписування одним кліком.
Microsoft запровадила подібні SPF, DKIM і DMARC-вимоги для доменів, які надсилають понад 5 000 повідомлень на день на споживчі адреси Outlook.com. Оголошення Microsoft стосується outlook.com, hotmail.com і live.com; не варто механічно поширювати цю конкретну межу на кожного клієнта Microsoft 365.
Навіть якщо ваш сайт далеко від 5 000 листів, базовий висновок незмінний: автентифікуйте всю production-пошту, підтримуйте справну інфраструктуру й спостерігайте за репутацією. Це мінімальний допуск, а не гарантія «Вхідних».
Налаштуйте SPF, DKIM і DMARC як одну систему
- SPF дозволяє конкретним системам надсилати для домену envelope sender. Для одного домену має бути одна узгоджена SPF-політика; застарілі сервіси треба прибирати.
- DKIM підписує повідомлення доменом, який ви контролюєте. Перевіряйте результат у заголовку отриманого листа, а не лише зелену позначку в кабінеті.
- DMARC вимагає, щоб видимий домен From збігався на організаційному рівні з доменом, який успішно пройшов SPF або DKIM, задає політику й адресу звітів.
- DNS і транспорт охоплюють коректні A/PTR-записи для власних IP-адрес відправлення, послідовні імена серверів і TLS. У керованого провайдера частина цих обов’язків на його боці.
Специфікація DMARC пояснює головну деталь: протокол додає узгодження доменів, політику отримувача й звіти поверх SPF та DKIM. Лист може пройти SPF за технічним доменом провайдера, але не пройти DMARC, якщо той не узгоджений із From, який бачить клієнт.
p=none — це етап спостереження, а не фінальна відзнака безпеки. Класифікуйте кожне джерело, налаштуйте або вимкніть його, перевірте пересилання та особливості провайдерів, а потім поступово переходьте до quarantine і reject. Не копіюйте готовий TXT-запис зі статті: include, selector, Return-Path і адреса звітів залежать від вашої архітектури.
Розділіть сервісні листи й розсилки
Невдала маркетингова база не повинна тягнути за собою листи для входу. Створіть окремі потоки, а за потреби — зрозумілі піддомени на кшталт tx.example.com і news.example.com. Видима назва має залишатися впізнаваною, відповіді — потрапляти до реального власника, а домени DMARC — бути узгодженими.
Amazon SES прямо радить окремі піддомени для транзакційних і маркетингових листів, щоб вони формували власну репутацію. Розділіть також правила заборони повторних відправлень і метрики. Скарга на рекламний лист має негайно зупинити рекламу цій людині; необхідне повідомлення про вже оформлене замовлення може мати іншу підставу й політику.
Не створюйте новий піддомен для кожної кампанії. Стабільність важливіша за косметику. Не змінюйте одночасно домен, провайдера, IP-стратегію, ім’я From і частоту — у разі проблеми ви не зрозумієте причину.
Побудуйте надійний ланцюжок відправлення
Не прив’язуйте успішне оформлення замовлення до відповіді зовнішнього поштового API. Спочатку надійно збережіть замовлення та подію для листа, а окремий фоновий обробник нехай забере її з журналу вихідних подій (outbox) або черги. Сайт має показати успіх тоді, коли бізнес-транзакцію записано, а не тоді, коли Gmail прийняв повідомлення.
Бізнес-запис → надійний outbox або черга → шаблон і мова → провайдер → підписаний webhook → стрічка статусів → сповіщення або резерв.
- Стабільний ID події захищає від двох однакових листів під час повторної спроби.
- Тимчасові помилки повторюються з паузою; постійно неправильну адресу не атакують без кінця.
- Provider message ID зв’язується з конкретним замовленням, акаунтом, рахунком чи заявкою.
- Підпис webhook перевіряється, а повторний webhook не створює повторної дії.
- Версія шаблону зберігається, щоб підтримка бачила контекст.
- Секрети не потрапляють у логи, а персональні дані зведені до необхідного.
Критичні листи WordPress не варто залишати на непрозорій локальній поштовій функції. Потрібен надійний транзакційний провайдер або професійно керований поштовий сервер, правильна автентифікація та видимі помилки плагіна чи застосунку. SMTP-плагін може змінити маршрут, але не виправить автоматично узгодження доменів, відмови, дублікати й відсутність моніторингу.
Відредагуйте шаблони під дію
Лист для зміни пароля — не рекламний банер. Одразу поясніть причину, назвіть сервіс, дайте одну основну кнопку, вкажіть строк дії, опишіть кроки для людини, яка не робила запиту, і запропонуйте безпечний зв’язок із підтримкою. Акційна карусель у такому листі лише заважає.
У підтвердженні замовлення потрібні номер, правильні товари й суми, стан оплати та виконання, наступний крок і захищене посилання на статус. Надсилайте HTML і читабельну текстову версію. Посилання мають вести через HTTPS на очікуваний домен, From — бути стабільним, а Reply-To — справді оброблятися, якщо відповідь запропонована.
Українську версію треба редагувати як сервісний текст: природні назви статусів, доставки, оплати й повернення, коректні відмінки, дата, час, валюта та адреса. Не залишайте випадкову суміш «Ваш order shipped». Повний контекст запуску — від checkout до доставки — є у гайді Rendframe про запуск інтернет-магазину в Україні.
Обробляйте статуси й помилки
Прийняття провайдером, доставка, затримка, остаточна відмова, відхилення, скарга й відписування — різні стани. Документація Amazon SES про події добре показує, чому їх не можна зводити до «відправлено / не відправлено». Після остаточної відмови адресу слід заблокувати для повторних спроб до виправлення або безпечної перевірки. Тимчасова затримка лишається видимою й обробляється за правилами.
Вимірюйте окремо для кожного потоку й провайдера: прийняті запити, час від замовлення до прийняття листа, затримку доставки, остаточні відмови, скарги, запізнення вебхуків, довжину черги, найстарішу невідправлену задачу й завершення цільової дії. Піксель відкриття не є достовірним доказом прочитання та може бути недоречним у чутливих листах.
Сповіщайте не лише про сплески, а й про тишу. Якщо магазин щогодини має нові замовлення, але підтверджень нуль, це інцидент. Якщо вебхуки зникли, а відправлення триває, «спокійний» графік насправді означає втрату видимості.
Дайте клієнтові запасний шлях
Лист має підтверджувати операцію, а не бути єдиним місцем, де вона існує. Після оплати покажіть номер замовлення й подальші кроки на сайті. В особистому кабінеті дайте переглянути стан і безпечно повторити лист. Для гостьового замовлення lookup не повинен розкривати, чи належить довільна адреса реальному клієнтові.
Відновлення доступу потребує rate limit, одноразових посилань з обмеженим строком, нейтральної відповіді без розкриття існування акаунта й іншого шляху для людини без доступу до скриньки. Підтримка не повинна вручну пересилати reset link.
Заявку з форми спочатку збережіть у CRM або видимій черзі, а вже потім надсилайте повідомлення менеджеру. Інакше один відфільтрований внутрішній лист перетворюється на непомітно втраченого ліда.
Пройдіть аудит із 12 пунктів
- Перерахуйте всі застосунки, корпоративну пошту, CRM, платіжні й зовнішні сервіси, що використовують ваш домен.
- За заголовками листів зіставте From, Return-Path, SPF, DKIM і узгодження DMARC.
- Розділіть транзакційні та маркетингові потоки, власників, заборони повторних відправлень і метрики.
- Переконайтеся, що компанія контролює акаунти провайдера, домен і ключі вебхуків.
- Винесіть критичні відправлення в надійний outbox або чергу.
- Додайте захист від дублів, обмежені повторні спроби, чергу помилок і контрольований повторний запуск.
- Перевіряйте підписи webhook і зв’язуйте статус із бізнес-подією.
- Обробляйте остаточні відмови, затримки, скарги й заборони повторного надсилання відповідно до категорії листа.
- Перевірте реальні шаблони на Gmail, Outlook, Yahoo, Apple Mail і важливих регіональних сервісах.
- Перегляньте мобільну верстку, текстову версію, доступність, мови, посилання, строк дії та відповіді.
- Налаштуйте графіки й сповіщення для черги, тиші, затримки, bounce, скарг і цільової дії.
- Для кожного критичного листа створіть безпечну сторінку стану, resend або людський резерв.
Проведіть тест на нових акаунтах і справжніх production-подібних замовленнях. Повторюйте його після зміни DNS, провайдера, шаблону або автентифікації. Тестові скриньки — діагностична вибірка, а не універсальний бал потрапляння у «Вхідні».
Поширені запитання
Чому листи із сайту потрапляють у спам?
Причина може бути в автентифікації або узгодженні доменів, але перевірте весь шлях: створення події, чергу, відповідь провайдера, репутацію, якість адрес, статуси доставки, шаблон і спільну інфраструктуру з розсилками.
Чи гарантують SPF, DKIM і DMARC «Вхідні»?
Ні. Вони підтверджують дозволений та узгоджений домен і дають політику та звіти. Остаточне рішення враховує також репутацію, скарги, інфраструктуру, зміст, поведінку одержувачів і характер відправлення.
Що означає delivered у кабінеті провайдера?
Здебільшого сервер одержувача прийняв повідомлення. Це не підтвердження «Вхідних» або прочитання. Пов’язуйте поштовий статус із реальною дією: оплату підтверджено, пароль змінено, документ відкрито.
Чи потрібне «Відписатися» в листі про замовлення?
Суто транзакційне підтвердження або reset не тотожні маркетинговій підписці. Не домішуйте рекламу. Розсилка повинна мати окремі підстави, налаштування переваг і відписування за чинними правилами.
Чи вирішить SMTP-плагін проблему WordPress?
Він може відправляти через належного провайдера, що часто необхідно. Але окремо потрібні DNS та узгодження доменів, реєстр відправників, обробка відмов, захист від дублів, моніторинг черги й запасний шлях для користувача.
Сприймайте пошту як частину продукту
Надійне рішення — не скриншот DNS і не максимальний бал у spam tester. Бізнес-подія має існувати, лист — потрапити в чергу один раз, домен — пройти автентифікацію, статуси — повернутися в систему, помилки — мати власника, а клієнт — завершити дію навіть у разі затримки.
Rendframe може перевірити пошту сайту або магазину від подій застосунку й DNS до провайдера, шаблонів, вебхуків, панелі моніторингу та резервного сценарію. Перегляньте послугу продуктового інжинірингу або принесіть один приклад невдалого підтвердження чи відновлення пароля для сфокусованого аудиту.