Листи з вашого домену
Бот може писати вашим клієнтам електронною поштою — з адреси на вашому домені, на кшталт noreply@example.com. Сам лист при цьому надсилає наш сервер. Через це перед першою відправкою потрібно один раз додати три записи в DNS вашого домену. Нижче — навіщо це потрібно, що саме додати й що відбувається далі.
Чому без DNS-записів листи не дійдуть
Погляньте на ситуацію очима приймальної сторони — Gmail, Outlook або поштового сервера вашого клієнта. До них надходить лист, який видає себе за лист з вашого домену, але приходить із сервера, що вашому домену не належить. Це рівно та сама картина, що й підробка від вашого імені: саме так виглядає фішинг.
Відрізнити одне від іншого отримувач може єдиним способом — запитати сам домен: «цей відправник справді діє від вашого імені?» Відповідь ви публікуєте в DNS свого домену: DNS — єдине місце, яким розпоряджаєтеся тільки ви, і тому єдине, чому отримувач вірить.
Доки відповіді немає, сумлінний поштовий сервер зобов'язаний вважати лист підозрілим. У кращому разі він поїде в «Спам», у гіршому — буде відхилений, і отримувач про нього ніколи не дізнається.
Тому три записи нижче — не формальність і не галочка в інтерфейсі. Це і є ваш дозвіл.
Три записи й що робить кожен
DKIM — підпис, що доводить справжність
DKIM — криптографічний підпис, яким позначається кожен вихідний лист. Платформа генерує для вашого домену пару ключів: закритий лишається в нас і підписує листи, відкритий ви публікуєте в DNS. Отримувач бере відкритий ключ із вашого DNS і перевіряє підпис. Зійшовся — отже, лист надіслав той, у кого є закритий ключ, і текст не підмінили дорогою.
Без DKIM: перевіряти підпис нічим. Лист виглядає непідписаним, довіри до нього немає, і жодні інші налаштування цього не компенсують. DKIM — найважливіший із трьох записів.
SPF — список серверів, яким можна надсилати від вашого імені
SPF відповідає на інше питання: з яких серверів узагалі припустимі листи від цього домену. Це список джерел — поштові сервери вашого хостингу, сервіси розсилок, якими ви вже користуєтеся, і, щоб бот міг писати, наші сервери відправки.
Без SPF: лист приходить із сервера, якого ваш домен «не знає». Для фільтра це класична ознака підробки, і вона додається до всіх інших підозр.
DMARC — що робити отримувачу, якщо перевірки не пройшли
DKIM і SPF відповідають на питання «чи справжній лист». DMARC відповідає на наступне: що робити, якщо ні. Це ваша вказівка отримувачу — нічого не робити й лише надіслати звіт, відправити в спам або відхилити. Заразом DMARC — це адреса, на яку отримувачі шлють зведені звіти про пошту від вашого імені, включно з чужими спробами підробки.
Радимо починати з найм'якшої політики — «лише звіти». Посилювати її варто пізніше, коли ви переконалися, що всі ваші справжні відправники (бухгалтерія, CRM, розсилки, цей бот) перевірки проходять. Сувора політика, увімкнена зарано, починає різати вашу ж власну пошту.
Без DMARC: кожен отримувач вирішує по-своєму, а ви не дізнаєтеся, що відбувається з поштою від вашого імені.
Які записи додати
Спершу заведіть домен у кабінеті: розділ Email → «Sending domains» → кнопка «Add domain». У діалозі три поля: сам домен (наприклад shop.example.com), локальна частина адреси (частина до @, зазвичай noreply) і ім'я відправника — те, що отримувач побачить замість адреси. Після збереження на екрані з'являться ваші DNS-записи.
Усі три — записи типу TXT у DNS вашого домену. Додаються вони там само, де ви керуєте доменом: у панелі реєстратора або в DNS-провайдера.
Значення нижче показані на прикладі домену example.com — підставте свій. Точні значення для вашого домену показані в кабінеті на картці домену — копіюйте їх звідти, особливо DKIM: його значення містить ваш власний відкритий ключ, у кожного домену він свій, і з документації його взяти неможливо.
Кожен запис на екрані розбито на два окремі поля — «Host» і «Value», у кожного своя кнопка «Copy». Копіюйте їх по одному у відповідні поля панелі вашого DNS-провайдера: одним шматком ці дві частини не вставляються.
| Тип | Ім'я запису (host) | Значення |
|---|---|---|
| TXT | mybot._domainkey.example.com | v=DKIM1; k=rsa; p= і далі довгий ключ із кабінету |
| TXT | example.com (корінь домену) | v=spf1 include:esp.getmybot.dev ~all |
| TXT | _dmarc.example.com | v=DMARC1; p=none; rua=mailto:dmarc@example.com |
Дві речі, на яких спотикаються найчастіше:
- Багато панелей підставляють домен до імені запису самі. Якщо в полі імені вже написано «.example.com», уводьте лише
mybot._domainkey, а не повне ім'я — інакше вийдеmybot._domainkey.example.com.example.com. - Значення DKIM довге й не повинно містити переносів і пробілів усередині ключа. Копіюйте його кнопкою, а не виділенням мишею.
Якщо SPF-запис у домену вже є
У домену може бути лише один SPF-запис. Якщо ви вже надсилаєте пошту через хостинг, CRM чи інший сервіс розсилок, такий запис у вас є. Не додавайте другий — допишіть в наявний ще один include, перед завершальним ~all:
v=spf1 include:spf.вашпровайдер.ua include:esp.getmybot.dev ~all
Два SPF-записи на домені — та сама помилка, що й жодного: перевірка не проходить, бо отримувач не знає, якому з двох вірити.
Зверніть увагу: «покриття» через чужий запис недостатньо. Навіть якщо ваш нинішній провайдер сам включає нас у свій SPF, наш include має стояти у вашому записі напряму — чому саме так, див. нижче в розділі про перевірку домену.
Чому в SPF саме include, а не IP-адреса
Найчастіша помилка — вписати в SPF IP-адресу, підгледжену в заголовках листа або в чиємусь дописі. Так робити не треба.
include:esp.getmybot.dev — це посилання на наш власний, підтримуваний нами список серверів відправки. Сьогодні за цим іменем стоїть один сервер. Завтра їх може стати більше, вони можуть переїхати або змінитися. Коли це станеться, ми оновимо список у себе — і ваш запис продовжить працювати, чіпати нічого не доведеться. У цьому весь сенс: адреса змінюється в одному місці, а не в DNS у кожного клієнта.
Прописана руками IP-адреса в момент такої зміни просто перестане відповідати дійсності. Листи почнуть провалювати SPF без жодного попередження — ні помилки в кабінеті, ні сповіщення не буде, ви дізнаєтеся про це від клієнтів, які «нічого не отримували».
Пишіть рівно include:esp.getmybot.dev — і нічого до цього не додавайте.
Перевірка домену
Перевірка домену (верифікація) — це коли платформа сама зазирає в DNS вашого домену й переконується, що всі три записи в порядку. Якщо всі три пройшли, домен отримує статус «Перевірено» і відправку дозволено. Доки хоч один не пройшов, домен лишається в очікуванні.
Перевіряється не просто «запис існує»:
| Запис | Що саме перевіряється |
|---|---|
| DKIM | Запис опубліковано і він містить саме ваш відкритий ключ. Чужий або застарілий DKIM перевірку не пройде. |
| SPF | Запис існує і напряму містить include:esp.getmybot.dev. Схожі значення на кшталт include:esp.getmybot.dev.чужий-домен не рахуються. |
| DMARC | Запис опубліковано і він починається з v=DMARC1. Сама політика (p=, rua=) не перевіряється — це ваше рішення, а не дозвіл для нас. |
Чому DMARC перевіряється м'якше: він каже отримувачам, як діяти з результатами DKIM і SPF, але не дає нам права надсилати від вашого імені. Це право дають рівно два перші записи, і обидва перевіряються за вмістом повністю.
Чужий include не зараховується
include:esp.getmybot.dev має стояти у вашому власному SPF-записі. Якщо ваш SPF містить стороннього провайдера, а вже його запис містить нас, перевірка цього не зарахує: платформа не розгортає ланцюжки чужих include. Причина проста — так відповідь на питання «чи дозволив нам саме цей домен» лишається однозначною.
Практично це означає: навіть якщо ви впевнені, що «покриті через провайдера», допишіть наш include прямо до себе. Рівно те саме написано й на самому екрані, у поясненні до SPF-запису: якщо запис у домену вже є — додайте в нього значення include:..., а не замінюйте запис цілком, бо домен може надсилати пошту не лише через нас. Підказка там висить завжди, а не з'являється після невдалої перевірки.
DNS оновлюється не миттєво. Після збереження записів у реєстратора їм потрібно розійтися серверами імен: зазвичай це хвилини, іноді години, зрідка — до доби. Залежить від вашого провайдера й від TTL записів. Це нормально й від нас не залежить.
Чекати пасивно не потрібно. Платформа сама перевіряє домени в очікуванні раз на годину, але на картці домену є кнопка «Verify now» — та сама перевірка, запущена негайно, з результатом одразу на екрані. Натискайте її одразу після збереження записів: якщо десь одрук, ви дізнаєтеся про це за секунду, а не за годину. Натискати можна скільки завгодно разів.
Статус домену видно на картці: «Pending verification», «Verified» або «Not verified». Доки домен не підтверджено, там само висить попередження «Sending from this domain is disabled until it is verified.»
Результат перевірки — не просто «не пройшло». У кожного з трьох записів на екрані свій статус — «Passing», «Not passing» або «Not checked yet» — і свій рядок із поясненням, що саме не так.
Для SPF екран розрізняє дві ситуації, і це головна відмінність у всьому процесі:
- SPF-запису в домену немає взагалі. Опублікуйте його — значенням із таблиці вище.
- SPF-запис є, але нашого include в ньому немає. Допишіть include в наявний запис: не створюйте другий і не замінюйте його цілком. Той самий текст окремо описує й випадок із ланцюжком: якщо include доходить до нас лише через SPF-запис іншого провайдера, це не зараховується — ланцюжки не розгортаються.
Другий випадок — найзаплутаніша точка всього процесу: запис у вас уже є, ви щойно перечитали його очима, і все одно бачите відмову. Повідомлення про помилку тепер каже рівно те саме, що й постійна підказка поруч із самим записом, — дописати наш include у те, що вже є.
Якщо перевірка не проходить:
- Прочитайте, який із трьох записів отримав «Not passing» і що написано в його поясненні, — далі дійте за ним.
- Переконайтеся, що записи справді опубліковані, — багато панелей вимагають окремо натиснути «Застосувати зміни».
- Перевірте ім'я запису на подвоєний домен (див. вище).
- Перевірте, що SPF-запис на домені один і що наш include стоїть саме в ньому.
- Зачекайте й натисніть перевірку ще раз: можливо, зміни ще не розійшлися.
До перевірки відправка не працює — так задумано
Доки домен не перевірено, листи не надсилаються. Не «надсилаються й потрапляють у спам» — не йдуть узагалі: спроба завершується помилкою про непідтверджений домен, і це видно в журналі.
Це зроблено навмисно, і це не збій. Листи з домену, який сам себе не підтвердив, — це скарги на спам, а скарги псують репутацію інфраструктури відправки, спільної для всіх клієнтів платформи. Дешевше не надіслати листа, ніж надіслати його й потім півроку вибиратися з чорних списків. Тому тут заборона, а не попередження.
Якщо ви бачите таку помилку — не пишіть у підтримку одразу: спершу перевірте DNS-записи й натисніть перевірку. У переважній більшості випадків річ в одруці в імені запису.
Відписки, скарги та відмови доставки
Три правила, які дивують, якщо про них не знати заздалегідь.
У кожному рекламному листі є відписка в один клік. Платформа сама додає посилання відписки в підвал листа й службові заголовки, за якими поштовий клієнт малює кнопку «Відписатися» поруч з адресою відправника. Прибрати це не можна — ні налаштуванням, ні версткою листа. Відписка спрацьовує одразу, без відкриття листа й без підтвердження. Це вимога Gmail та інших великих поштових сервісів до масових відправників: лист без такої можливості їде в спам гарантовано.
Відписка остаточна, і скасувати її з інтерфейсу не можна. Адреса, що відписалася, більше не отримує листів цього бота. Немає ні кнопки «повернути», ні обхідного шляху через повторний імпорт списку: відписка не скасовується поза волею людини. Повернутися людина може лише сама — знову залишивши свою адресу у вашій формі підписки.
Є ще суворіший випадок: якщо людина натиснула в поштовому клієнті «Це спам», адреса закривається назавжди. Її не відкриє навіть повторна підписка через форму — бо ми вже знаємо, чим скінчилася минула спроба, а повторна розсилка на таку адресу найшвидше знищує репутацію домену. Так само поводяться адреси, закриті вручну за юридичною вимогою.
Жорстка відмова доставки закриває адресу назавжди. Якщо поштовий сервер отримувача відповів, що такої скриньки не існує, адреса позначається як недоставна й вилучається з подальших відправок. Це не тимчасовий стан: продовжувати добиватися в неіснуючу скриньку — найшвидший шлях до спам-фільтрів, разом із усіма іншими адресами.
Тимчасові відмови (переповнена скринька, недоступний сервер) адресу не закривають — відправка триває.
Чому «Відкриття» занижені
У статистиці пошти є показник відкриттів, і він завжди менший за реальний. Річ не в помилці підрахунку, а в тому, як відкриття взагалі вимірюються.
Відкриття фіксується, коли поштовий клієнт під час показу листа завантажує з сервера крихітну картинку-піксель. Сучасні клієнти віддалені картинки типово не завантажують; а ті, що завантажують (Apple Mail і подібні механізми приватності), роблять це заздалегідь і за всіх, включно з тими, хто листа так і не відкрив. У першому випадку відкриття втрачається, у другому — приписується людині, якої не було. Порахувати відкриття точніше неможливо — ні нам, ні будь-кому іншому.
Тому в інтерфейсі поруч із відкриттями стоїть застереження: це нижня межа, а не точне число. Користуйтеся ним, щоб порівнювати листи між собою, де однакова похибка діє для всіх, але не як відповіддю на питання «скільки людей прочитали лист».
Якщо потрібна надійна метрика залученості — дивіться «Link clicks». Клік за посиланням — це реальна дія живої людини, її ніхто не робить за неї наперед. «Delivered», «Unsubscribes», «Complaints» і «Bounces» теж рахуються точно: їх повідомляють поштові сервери, а не картинка в листі. Усі ці показники — у блоці «Sending stats» на тому самому екрані Email.