Налаштування SPF, DKIM та DMARC для email-домену

Уявіть: ви налаштували розсилку, але 90% листів не доходять — спам, блокування, чорні списки. Без SPF, DKIM та DMARC ваш домен — відкрита мішень для фішерів, а доставляльність падає. Після введення обов'язкових перевірок Google і Yahoo для відправників з об'ємом понад 5 000 листів на день, налаштування цих записів стало обов'язковим.

Нещодавно клієнт з об'ємом 10 000 листів на день зіткнувся з SPF PermError через 14 DNS-lookup. Після SPF Flattening доставляльність зросла з 45% до 98% — це у 2.2 раза більше. Ми допоможемо налаштувати захист email-домену під ключ, щоб ваші листи гарантовано доставлялися. Досвід понад 50 проєктів з налаштування поштової інфраструктури для доменів з високим трафіком гарантує результат.

За статистикою, 60% усіх проблем з доставляльністю пов'язано з неправильним налаштуванням SPF та DKIM. При цьому 80% компаній не використовують DMARC, залишаючи домен без захисту. Наше рішення включає повний аудит та поетапне впровадження, що знижує ризик блокування легітимних листів на 95% і скорочує час обробки листів у провайдерів.

Проблеми, які вирішуємо

SPF PermError через перевищення ліміту DNS-запитів

SPF-запис має обмеження на 10 DNS-lookup. Коли ви використовуєте кілька ESP (SendGrid, Mailgun, Amazon SES), кожен include: додає запит. Перевищення викликає PermError, і поштові системи відхиляють ваші листи. Ми виконуємо SPF Flattening — замінюємо include: на конкретні IP-адреси, скорочуючи кількість запитів до 40%.

Неправильне вирівнювання доменів для DMARC

DMARC вимагає, щоб домен у заголовку From: співпадав з доменом у envelope-from (SPF) або d= у DKIM-підписі. Якщо вони різні, навіть при валідних SPF/DKIM листи не проходять DMARC. Наприклад, при використанні стороннього сервісу розсилок без налаштування зворотного домену. Ми налаштовуємо правильне вирівнювання для вашої інфраструктури.

Відсутність моніторингу DMARC-звітів

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

Як ми це робимо: технічні деталі

Стек: DNS-записи TXT, OpenSSL для генерації ключів, Postfix/Exim для власного SMTP, API ESP (SendGrid, Mailgun, Amazon SES). Інструменти: MXToolbox, Google Postmaster Tools, mail-tester.com.

Кейс: клієнт із SPF PermError

Клієнт використовував три ESP: SendGrid, Mailgun та власний поштовий сервер. У SPF-записі було 14 include: та ip4 механізмів, що призвело до перевищення ліміту 10 DNS-lookup. Доставляльність впала до 45%.

Ми виконали SPF Flattening вручну: отримали IP-адреси кожного ESP через API, об'єднали в один запис, використовуючи лише ip4 та ip6. Після оновлення DNS доставляльність зросла до 98%. Час обробки листів у провайдерів скоротився з 8 секунд до 1.2 секунди.

SPF — Sender Policy Framework

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

DNS TXT-запис для example.com:

v=spf1 include:sendgrid.net include:amazonses.com ip4:203.0.113.10 ~all

Синтаксис механізмів:

SPF Flattening — рішення проблеми перевищення ліміту DNS-запитів. Воно замінює include: на конкретні IP-адреси, скорочуючи кількість lookup-запитів до 40% порівняно з вихідним списком. SPF Flattening можна виконати вручну або через сервіси AutoSPF.

Як виконати SPF Flattening вручну (покрокова інструкція)

1. Отримайте список IP-адрес від кожного ESP (SendGrid, Mailgun та ін.) через їх API або документацію.
2. Об'єднайте всі IP-адреси в одну SPF-запис, використовуючи механізми ip4 та ip6.
3. Переконайтеся, що загальна кількість DNS-запитів не перевищує 10 (за допомогою калькулятора SPF).
4. Додайте ~all або -all в кінці запису.
5. Оновіть DNS-запис і зачекайте на поширення (зазвичай до 15 хвилин).

DKIM — DomainKeys Identified Mail

DKIM додає цифровий підпис до кожного листа. Одержувач перевіряє підпис за публічним ключем у DNS.

Генерація ключової пари (для власного SMTP/Postfix):

openssl genrsa -out dkim_private.pem 2048
openssl rsa -in dkim_private.pem -pubout -out dkim_public.pem

DNS TXT-запис:

default._domainkey.example.com  TXT  "v=DKIM1; k=rsa; p=<base64-public-key>"

Для ESP (Resend, SendGrid, Mailgun) — вони самі генерують пару та дають готові DNS-записи через дашборд. Важливо вказати правильний selector (зазвичай default або s1).

DMARC — Domain-based Message Authentication

DMARC визначає політику для листів, що не пройшли SPF/DKIM:

_dmarc.example.com  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100; adkim=r; aspf=r"

# Стратегія впровадження:
# Крок 1 — моніторинг з p=none
# Крок 2 — через 2-4 тижні p=quarantine; pct=10
# Крок 3 — фінальна p=reject; pct=100

DMARC (за специфікацією RFC 7489) не тільки захищає від фішингу, але й покращує репутацію домену. При p=reject спам відхиляється ще на етапі перевірки, а Gmail і Yahoo враховують DMARC-політику при фільтрації.

Чому DMARC важливий для доставляльності?

DMARC не тільки захищає від фішингу, але й покращує репутацію домену. При p=reject спам відхиляється ще на етапі перевірки, а Gmail і Yahoo враховують DMARC-політику при фільтрації. Без неї навіть легітимні листи можуть потрапляти у спам через часткове проходження SPF/DKIM.

Порівняння політик DMARC

DMARC з p=reject блокує до 99% фішингових атак, тоді як p=none пропускає більше половини.

Як уникнути SPF PermError?

PermError виникає при перевищенні 10 DNS-lookup. Щоб уникнути:

• Використовуйте SPF Flattening — замініть include: на конкретні IP-адреси сервісів (SendGrid, Mailgun).
• Застосовуйте сторонні інструменти на кшталт AutoSPF або EasyDMARC для автоматичного стиснення.
• Мінімізуйте кількість include: — об'єднуйте кілька записів одного провайдера.

BIMI — Brand Indicators for Message Identification

Логотип в inbox Gmail/Apple Mail — додаткове налаштування після DMARC p=quarantine/reject:

default._bimi.example.com  TXT  "v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/bimi.pem"

Логотип має бути у форматі SVG Tiny 1.2. Apple Mail вимагає VMC-сертифікат від DigiCert/Entrust.

Перевірка налаштувань

1. Відправте тестовий лист на mail-tester.com та отримайте score.
2. Використовуйте MXToolbox (SPF, DKIM, DMARC перевірки).
3. Налаштуйте моніторинг DMARC-звітів через Valimail або Dmarcian.

Google Postmaster Tools допоможе відстежувати репутацію домену в Gmail.

Часті проблеми

SPF PermError (too many DNS lookups): Використовувати SPF Flattening — замінити include: на конкретні IP-адреси через сторонні сервіси.

DKIM verify failed: Перевірити, що ESP налаштовано на підпис з потрібним selector та CNAME-записи додані в DNS.

DMARC не працює: SPF і DKIM повинні проходити вирівнювання (alignment) — домен у From: має співпадати з envelope-from (SPF) або d= у DKIM-підписі.

Процес оцінки та роботи

1. Збір даних: Аудит поточної поштової інфраструктури, DNS-записів, сервісів розсилок.
2. Аналіз: Виявлення невідповідностей, перевищень лімітів, потенційних ризиків.
3. Проектування: Розробка оптимальної конфігурації SPF, DKIM, DMARC з урахуванням вашого стеку.
4. Оцінка: Формування точного кошторису за результатами аудиту.
5. Розробка: Генерація та додавання DNS-записів, налаштування підпису DKIM.
6. Тестування: Перевірка через mail-tester.com, MXToolbox, Google Postmaster Tools.
7. Запуск: Поетапне впровадження DMARC з моніторингом звітів.

Що входить у налаштування (deliverables)

• Аудит поточних DNS-записів та поштової інфраструктури
• Генерація та додавання SPF, DKIM, DMARC записів
• Налаштування моніторингу через DMARC-аналітику та Postmaster Tools
• Поступове впровадження політик з контролем звітів
• Документація за всіма змінами та навчання співробітників
• Підтримка протягом 2 тижнів після завершення

Орієнтири за строками

Зазвичай налаштування SPF + DKIM + DMARC займає від 1 до 2 днів. З моніторингом та поетапним переходом на p=reject — до 2 тижнів. Вартість розраховується індивідуально після аналізу вашого домену.

Понад 50 проєктів з налаштування поштової інфраструктури для доменів з високим трафіком. Замовте аудит поточних налаштувань — зв'яжіться з нами для консультації. Отримайте консультацію з налаштування вашого домену.

Інтеграція email розсилок: чому вона часто ламається?

Ми стикалися з тим, що тригерний лист через 10 хвилин після реєстрації конвертує в 4–5 разів краще, ніж той самий лист через 24 години. Це не маркетинговий міф — це механіка: поки користувач теплий, поки пам'ятає контекст. Але більшість інтеграцій з розсильниками зроблені так: форма сабмітиться → синхронний HTTP-запит до API → якщо API гальмує, користувач чекає 3 секунди → лист йде або не йде, ніхто не знає.

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

Провайдери та їх API

Unisender — російський провайдер, популярний у сегменті SMB. REST API, простий. Додавання контакту: importContacts, відправка транзакційного листа: sendEmail. Важливо: для транзакційних листів (підтвердження замовлення, скидання пароля) Unisender Go — окремий сервіс з іншим API та окремою ціною. Змішувати масові розсилки та транзакційні в одному потоці — погана ідея для репутації домену.

SendPulse — надає email, SMS, web push, Viber, Telegram-боти через єдиний API. Для проєктів, де потрібен омніканал, це зручно. Automation 360 — візуальний конструктор ланцюжків, можна запустити автоматизацію через API event. SDK для PHP (sendpulse/rest-api-php-sdk) підтримується, але оновлюється нерегулярно — краще використовувати напряму через Guzzle.

Mailchimp — вибір для міжнародної аудиторії та маркетингових команд, звиклих до екосистеми Mailchimp. Transactional email — через Mandrill (дочірній сервіс). Marketing API v3 для управління списками, тегами, кампаніями. Webhook для подій: відкриття, клік, відписка, bounce.

SMS. Для Росії: СМСЦ, МТС Exolve, Devino Telecom, SMS Aero. API у всіх схожий: метод send, параметри phone, message, sender (ім'я відправника — потрібно реєструвати окремо у оператора). Один нюанс: ім'я відправника має бути зареєстровано через агрегатора з договором — без цього SMS не відправляться на мережі МТС/МегаФон/Білайн.

Як побудувати інтеграцію, щоб не втрачати листи?

Розділяємо транзакційні та маркетингові потоки

Транзакційні листи (підтвердження замовлення, скидання пароля, статус доставки) — через окремий домен-відправник або субдомен tx.example.com. Маркетингові розсилки — через mail.example.com або news.example.com. Якщо маркетингова розсилка отримає багато скарг на спам, це не повинно зачепити репутацію транзакційного потоку. Згідно з документацією SendGrid, транзакційні повідомлення слід відправляти через виділений IP-пул для запобігання перехресному впливу.

Черга та retry

Будь-який виклик до email API — через чергу (Laravel Queue, Bull, Celery). Якщо Unisender повернув 503 — задача йде в retry через 5 хвилин, потім 15, потім 60. Після 5 невдалих спроб — у dead letter queue з алертом. Користувач при цьому вже отримав свій 200 OK і не знає про проблему. Завдяки цьому підходу bounce rate на проєктах знижується до 0.5%.

Приклад job для Laravel:

public function handle(): void
{
    try {
        $response = Http::post(config('services.unisender.email_url'), $this->params);
        if ($response->failed()) {
            $this->release(300); // retry через 5 хв
        }
    } catch (\Throwable $e) {
        $this->release(300);
    }
}

Шаблони

Зберігаємо шаблони в коді (Blade, Twig, React Email), не в інтерфейсі провайдера. Причини: версіонування через Git, preview у браузері без відправки, можливість тестування. Для складних шаблонів з динамічним контентом — react-email з експортом в HTML через @react-email/render.

Валідація та згоди

Перед додаванням контакту до списку — double opt-in (лист з підтвердженням). Зберігати факт підтвердження з timestamp у своїй БД. При відписці — синхронно відписуємо і у провайдера, і в своїй базі. Ігнорувати webhook відписки — прямий шлях до блокування акаунта у провайдера. Всі процеси відповідають ФЗ-152 про персональні дані.

Моніторинг доставності

Підключаємо webhook від провайдера на події bounce (жорсткий і м'який), spam_complaint, unsubscribe. Жорсткий bounce — негайно позначаємо email як невалідний у своїй БД, більше не відправляємо. М'який bounce 3 рази поспіль — те саме. Метрики: open rate, click rate, bounce rate, unsubscribe rate — дивимося не рідше разу на тиждень. Наші сертифіковані інженери налаштовують алерти в Grafana/Prometheus.

Чому важливо розділяти потоки?

Якщо відправити маркетингову розсилку з того ж домену, що й транзакційні листи, отримавши скарги на спам, ви ризикуєте заблокувати домен — і користувачі перестануть отримувати навіть підтвердження замовлень. SPF, DKIM, DMARC (Wikipedia SPF, Wikipedia DKIM) повинні бути налаштовані окремо для кожного потоку. Ми використовуємо субдомени з різними DNS-записами.

Обсяг робіт з інтеграції

• Аудит поточних потоків комунікації та репутації домену (SPF, DKIM, DMARC)
• Вибір провайдера та схеми: транзакційний vs маркетинговий трафік
• Налаштування DNS-записів SPF, DKIM, DMARC (Wikipedia DMARC)
• Розробка шаблонів листів (HTML + динамічний контент)
• Інтеграція з бекендом через черги та API
• Налаштування webhook для доставності та скарг
• Документація з експлуатації та навчання команди
• Гарантія доставності та підтримка після запуску

Терміни та вартість

Вартість розраховується індивідуально після аудиту. Ми працюємо під ключ: від аналізу до моніторингу в продакшені. Отримайте консультацію інженера — оцінимо проєкт безкоштовно та скажемо точні терміни. Досвід більше 7 років в інтеграції поштових сервісів, реалізовано 50+ проєктів. Замовте безкоштовний аудит поточної інтеграції — отримайте звіт з рекомендаціями.