Чому ваші ділові електронні листи потрапляють у спам (і як SPF, DKIM та DMARC це виправляють)

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

Якщо це звучить знайомо, ви не одні. Gmail, Yahoo та Outlook тепер відхиляють або переміщують у спам листи з доменів, які не налаштували три DNS-записи: SPF, DKIM та DMARC. Починаючи з лютого 2024 року, масові відправники (приблизно 5 000 або більше повідомлень на день на акаунти Gmail) повинні автентифікуватися за допомогою всіх трьох, пропонувати скасування підписки в один клік і тримати частку скарг на спам нижче 0,3%. Контроль посилювався протягом 2025 року, а у 2026 році навіть відправники з низьким обсягом відчувають вплив: без автентифікації ваші комерційні пропозиції, рахунки та підтвердження записів значно частіше позначаються як спам.

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

Що насправді роблять SPF, DKIM та DMARC​

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

SPF: які сервери можуть надсилати листи від вашого імені​

SPF (Sender Policy Framework) — це TXT-запис у DNS вашого домену, який перелічує всі сервери, що мають право надсилати пошту від вашого імені. Коли Gmail отримує повідомлення, нібито від [email protected], він перевіряє ваш SPF-запис і з'ясовує, чи IP-адреса надсилаючого сервера є у списку.

Приклад SPF-запису для бізнесу, який використовує Google Workspace та інструмент виставлення рахунків:

v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

• v=spf1 ідентифікує запис як SPF.
• Кожен include: авторизує сервери конкретного провайдера.
• ~all (м'який збій) вказує отримувачам ставитися до невказаних серверів із підозрою; -all (жорсткий збій) наказує відхиляти їх повністю.

SPF сам по собі недостатній, оскільки він перевіряє лише адресанта конверта (прихований Return-Path), а не адресу, яку ваш клієнт бачить у полі "Від". Пересилання також порушує SPF. Саме тому вам також потрібен DKIM.

DKIM: захищений від підробки підпис на кожному повідомленні​

DKIM (DomainKeys Identified Mail) додає криптографічний підпис до заголовків кожного вихідного повідомлення. Ваш поштовий провайдер зберігає приватний ключ; ви публікуєте відповідний відкритий ключ як TXT-запис у DNS. Сервер отримувача перевіряє підпис, щоб підтвердити, що повідомлення справді надійшло з вашого домену та не було змінено під час передачі.

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

Налаштування DKIM зазвичай означає:

1. Увімкнення підписування DKIM у вашому провайдері (Google Workspace, Microsoft 365, Mailchimp та подібні інструменти мають крок увімкнення в один клік).
2. Копіювання TXT-запису, який вони вам надають (селектор плюс довгий відкритий ключ), у ваш DNS.
3. Очікування на поширення, а потім підтвердження в панелі керування провайдера.

DMARC: ваша політика щодо того, що станеться, коли перевірки не пройдуть​

DMARC (Domain-based Message Authentication, Reporting, and Conformance) пов'язує SPF і DKIM воєдино. Це TXT-запис на _dmarc.yourdomain.com, який повідомляє серверам отримувача, що робити, коли повідомлення, яке стверджує, що воно від вас, не проходить автентифікацію — а також куди надсилати вам звіти про це.

Стартовий DMARC-запис у режимі моніторингу:

v=DMARC1; p=none; rua=mailto:[email protected]; pct=100;

• p=none означає поки що не вживати жодних дій, лише надсилати звіти. Почніть із цього.
• rua= — це адреса, куди надходять агреговані звіти. Використовуйте поштову скриньку, яку ви справді перевіряєте.
• Як тільки легітимні листи стабільно проходять перевірку, переходьте на p=quarantine (відправляти невдалі листи у спам), а потім на p=reject (блокувати їх). Така поступовість — це те, що зупиняє спамерів від видавання себе за ваш домен.

DMARC також вимагає узгодження: домен у заголовку "Від" має збігатися з доменом, який пройшов SPF або DKIM. Це крок, який багато компаній пропускають — SPF і DKIM можуть показувати "pass", але DMARC все одно не проходить, оскільки домени не збігаються.

Правила Gmail і Yahoo, яких ви маєте дотримуватися​

Навіть якщо ви ніколи не надсилаєте 5 000 повідомлень на день, сприймайте це як свій базовий рівень. Gmail зараховує всю пошту з одного основного домену (включно з субдоменами) до масового порогу, статус масового відправника ніколи не зникає після присвоєння, і кожен відправник — масовий чи ні — повинен автентифікуватися.

Ось практичний контрольний список на 2026 рік:

• Автентифікуйтеся за допомогою SPF або DKIM як мінімум; обох, якщо надсилаєте масові розсилки. Масові відправники потребують SPF і DKIM, а також опублікованого DMARC-запису (принаймні p=none) із узгодженням домену "Від".
• Тримайте частку скарг на спам нижче 0,3%. Google Postmaster Tools показує ваш показник; стабільні показники вище 0,3% спричиняють фільтрацію. Прагніть триматися значно нижче 0,1%.
• Полегшуйте скасування підписки на маркетингові листи. Включіть видимий заголовок List-Unsubscribe з підтримкою скасування підписки в один клік і виконуйте запити протягом двох днів.
• Використовуйте дійсні прямі та зворотні DNS-записи, а також узгоджений домен у полі "Від". Не надсилайте ділові листи з адрес безкоштовних поштових скриньок або з мінливих імен у полі "Від".
• Не видавайте себе за заголовки Gmail і не купуйте списки розсилки. Небажані листи породжують скарги, які найшвидше руйнують вашу репутацію.

Yahoo та Outlook застосовують практично той самий набір правил, тож одне правильне налаштування покриває всі три сервіси.

Налаштування всього приблизно за годину​

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

Крок 1: Складіть перелік того, хто надсилає пошту від вашого імені​

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

Крок 2: Опублікуйте SPF, не порушуючи ліміт у 10 пошуків​

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

• Почніть із рекомендованого запису вашого провайдера; не об'єднуйте випадкові фрагменти з блогів.
• Тримайте всі джерела відправлення в одному SPF TXT-записі на кореневому домені. Кілька SPF-записів роблять усі їх недійсними.
• Якщо ви близькі до ліміту, попросіть провайдерів спростити include або видаліть сервіси, якими більше не користуєтеся.
• Перевірте за допомогою безкоштовного SPF-перевірника, перш ніж рухатися далі.

Поширене налаштування SPF:

Крок 3: Увімкніть DKIM скрізь, звідки ви надсилаєте​

Увімкніть підписування DKIM у кожній платформі відправлення та опублікуйте кожен запис селектора, який вона вам надає. Домен часто має кілька селекторів DKIM (по одному на провайдера) — це нормально. Перевірте, що кожен показує статус "активний" у консолі провайдера, і надішліть тестовий лист на адресу Gmail, щоб підтвердити, що заголовок Authentication-Results показує dkim=pass.

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

Крок 4: Опублікуйте DMARC у режимі моніторингу, потім перейдіть до примусу​

1. Опублікуйте _dmarc із p=none та адресою rua=.
2. Спостерігайте за агрегованими звітами протягом двох-чотирьох тижнів. Безкоштовні програми для читання DMARC-звітів перетворюють XML на зрозумілі таблиці, які показують, які сервери проходять, а які ні.
3. Виправте кожне легітимне джерело, яке не проходить (зазвичай це відсутній підпис DKIM або неузгодженість доменів).
4. Перейдіть на p=quarantine, поспостерігайте ще один цикл, а потім переходьте на p=reject.

Перехід одразу на p=reject у перший день — це найпоширеніший самостійно спричинений збій у всьому цьому процесі: легітимні рахунки та квитанції блокуються, бо один недоглянутий відправник ніколи не був автентифікований.

7 помилок, через які малий бізнес залишається у спамі​

1. Взагалі немає SPF, DKIM або DMARC. Це досі найпоширеніша знахідка на доменах малого бізнесу. Перевірте свій домен будь-яким безкоштовним тестером автентифікації, перш ніж припускати, що ваш провайдер "усе зробив".
2. Два SPF-записи. DNS дозволяє лише один. Об'єднайте все в один TXT-запис, що починається з v=spf1.
3. SPF перевищує ліміт пошуків. Забагато include означає, що SPF дає збій. Проводьте аудит щороку та видаляйте мертвих провайдерів.
4. DKIM увімкнено в застосунку, але ніколи не опубліковано в DNS. Перемикач підписування без TXT-запису нічого не робить.
5. DMARC не проходить через неузгодженість. SPF або DKIM проходить, але під іншим доменом, ніж ваша адреса "Від" — це часто трапляється, коли розсилки надсилаються з домену провайдера, а не з вашого. Налаштуйте власний домен відправлення, щоб узгодження проходило.
6. Ніхто не читає DMARC-звіти. Поштова скринька rua= заповнюється, попередження про новий інструмент, що дає збій, залишаються непоміченими, а проблема спливає лише тоді, коли клієнти починають скаржитися.
7. Гігієна списків і контент зводять нанівець добру автентифікацію. Куплені списки, відсутність посилання на скасування підписки, оманливі теми листів та листи лише з зображеннями породжують скарги, які руйнують репутацію навіть за бездоганного DNS.

Як зрозуміти, що це спрацювало​

• Надішліть тестові листи на адреси Gmail, Yahoo та Outlook (включно з новим акаунтом, який ніколи не взаємодіяв із вами) і підтвердьте, що вони потрапляють у вхідні, а не у спам.
• Перевірте заголовки. У Gmail відкрийте повідомлення, виберіть "Показати оригінал" і підтвердьте spf=pass, dkim=pass та dmarc=pass із узгодженням вашого домену.
• Зареєструйтеся в Google Postmaster Tools. Додайте свій домен, підтвердьте право власності та спостерігайте за часткою спаму, показниками успішної автентифікації та репутацією протягом наступних тижнів.
• Відстежуйте реальні метрики. Порівняйте показники відкриттів, відповідей та — найголовніше — скарги клієнтів "я так і не отримав ваш рахунок" до та після зміни.

Як це пов'язано з вашою бухгалтерією​

Доставка електронної пошти — це проблема грошового потоку, замаскована під IT-завдання. Коли рахунки потрапляють у спам, клієнти платять із запізненням не з власної вини, ваш показник днів продажів у дебіторці (DSO) повзе вгору, і ви витрачаєте години, нагадуючи про платежі, які ніхто не бачив. Те саме стосується комерційних пропозицій, на які ніхто не відповідає, і серій нагадувань про оплату, які йдуть у порожнечу.

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

Більше про підтримання дебіторки в належному стані — у посібниках /docs/ про робочі процеси виставлення рахунків та у переглядах панелі /fava/, які показують прострочені залишки з першого погляду.

Спростіть управління своїми фінансами​

Щойно ваші рахунки надійно потрапляють у вхідні, переконайтеся, що подальше так само чисте: чіткі записи про те, що було виставлено, оплачено та залишилося несплаченим. Beancount.io надає бухгалтерію у форматі звичайного тексту, яка дає вам повну прозорість і контроль над вашими фінансовими даними — жодних чорних скриньок, жодної залежності від одного постачальника. Почніть безкоштовно і тримайте кожну гривню простежуваною від рахунку до облікового запису.