На VPS із власним Postfix вся відповідальність за репутацію вихідної пошти лежить на вас: немає готової інфраструктури провайдера, яка вже прогріта і налаштована. DKIM, SPF і DMARC на саморобному поштовому сервері — не опціональне посилення, а мінімум, без якого листи масово летять у спам або відхиляються з першого дня.
Встановлення OpenDKIM
apt install opendkim opendkim-tools -y
# Генерація ключів
mkdir -p /etc/opendkim/keys/yourdomain.com
cd /etc/opendkim/keys/yourdomain.com
opendkim-genkey -t -s mail -d yourdomain.com
chown opendkim:opendkim mail.privateОтримання публічного ключа для DNS
cat /etc/opendkim/keys/yourdomain.com/mail.txt
# Додайте цей запис у DNS як TXT для:
# mail._domainkey.yourdomain.comПовний набір DNS-записів
| Запис | Тип | Ім'я | Значення |
|---|---|---|---|
| MX | MX | @ | mail.yourdomain.com (priority 10) |
| SPF | TXT | @ | v=spf1 mx ~all |
| DKIM | TXT | mail._domainkey | v=DKIM1; k=rsa; p=PUBLICKEY |
| DMARC | TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com |
На відміну від готових поштових сервісів, де MX, SPF і DKIM провайдер видає вже узгодженим набором, на VPS усі чотири записи збираються вручну і повинні посилатися одне на одне без протиріч: домен у MX, домен у SPF і селектор в імені DKIM-запису зобов'язані збігатися з тим, що реально прописано в конфігурації Postfix та OpenDKIM.
Перевірка DKIM-підпису
# Тест підпису
opendkim-testkey -d yourdomain.com -s mail -vvv
# Перевірка після відправлення
# Заголовок листа повинен містити:
# DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=mail...Часті помилки OpenDKIM
| Повідомлення | Причина | Рішення |
|---|---|---|
| opendkim: mail.private: No such file or directory | Шлях KeyFile у /etc/opendkim.conf не збігається з реальним розташуванням ключа | Звірити шлях у конфігу з виводом ls /etc/opendkim/keys/yourdomain.com/ |
| body hash did not verify (DKIM-Signature) | Лист змінився після підпису — наприклад, проміжний сервер додав футер розсилки | Виключити такі маршрути з relay або підписувати лист після всіх модифікацій тіла |
| key not found in DNS (opendkim-testkey) | TXT-запис ще не поширився або селектор у DNS не збігається з іменем у конфігу | Перевірити dig TXT mail._domainkey.yourdomain.com і зачекати TTL |
| Postfix: reject: 550 5.7.1 SPF check failed | IP вихідного сервера не входить до SPF-запису домену відправника (чужий релей) | Додати IP сервера в SPF через механізм ip4: у власника домену-відправника |
Перший крок за будь-якої з цих помилок — подивитися /var/log/mail.log (Debian/Ubuntu) або /var/log/maillog (RHEL-родина): там видно, на якому етапі Postfix і milter OpenDKIM обробили лист і з яким саме кодом відмови, а не гадати за симптомами з боку отримувача.
Від p=none до p=reject: план переходу DMARC
| Етап | Значення p | Тривалість | Що відбувається |
|---|---|---|---|
| Моніторинг | p=none | 1–2 тижні | Збираються звіти rua, жоден лист не блокується |
| Частковий карантин | p=quarantine; pct=25 | 1 тиждень | Чверть непройдених листів потрапляє у спам у отримувачів |
| Повний карантин | p=quarantine; pct=100 | 1–2 тижні | Усі непройдені листи йдуть у спам |
| Відхилення | p=reject | постійно | Листи без коректних DKIM/SPF відхиляються на прийомі |
На власному VPS звіти rua надходять звичайним листом на вказану скриньку у вигляді XML усередині gzip-архіву — готової панелі для їх читання, як у великих провайдерів пошти, немає. На практиці їх або парсять самописним скриптом, або заводять окремий безкоштовний сервіс на кшталт dmarcian, який приймає пересилання цих листів і будує таблицю джерел відправлення за вас.
Перевірка SPF і DMARC записів
# Перевірити опубліковану SPF-запис
dig TXT yourdomain.com +short
# Перевірити DMARC-запис і його поточну політику
dig TXT _dmarc.yourdomain.com +short
# Швидка онлайн-перевірка через надсилання листа
# mail-tester.com — надішле розбір SPF/DKIM/DMARC за кілька секундКоли DKIM/SPF/DMARC на VPS не підходить
- Пошта надсилається через кілька зовнішніх сервісів розсилки одночасно — потрібен єдиний SPF з include на кожен сервіс, а не окремі TXT-записи: у зоні допустимий лише один запис типу SPF
- IP сервера в PBL або динамічному діапазоні провайдера — DKIM не врятує від блокування за репутацією самого IP, потрібна виділена статична адреса
- Потрібна ротація ключів без простою — доведеться тримати два селектори паралельно, наприклад mail і mail2, і перемикати їх по черзі
- Пошта вже розміщена в Google Workspace або іншому SaaS — DKIM налаштовується на боці провайдера, див. Google Workspace: MX і DNS, а не через OpenDKIM на VPS
Часті питання
Чи можна одразу встановити p=reject у DMARC, без періоду моніторингу?
Одразу переходити до p=reject ризиковано: якщо DKIM або SPF налаштовано з помилкою, легітимні листи почнуть відхилятися отримувачами ще до того, як ви про це дізнаєтесь. Період моніторингу з p=none потрібен саме для того, щоб побачити реальні джерела відправлення через звіти rua і переконатися, що власна пошта проходить перевірку, перш ніж посилювати політику.
Що станеться, якщо пошта надсилається через кілька зовнішніх сервісів розсилки одночасно?
В одній DNS-зоні допустимий лише один запис типу SPF, тому для кожного сервісу розсилки не можна заводити окремий запис — усі джерела відправлення потрібно перелічити через механізм include всередині єдиного SPF-запису домену. Якщо завести кілька окремих SPF-записів, перевірка стане непередбачуваною, і частина листів почне відхилятися незалежно від DKIM.
Як читати звіти DMARC (rua), якщо немає готової панелі, як у великих поштових провайдерів?
На власному VPS такі звіти надходять звичайним листом у вигляді архіву з розміткою всередині — читати їх очима незручно. На практиці їх або розбирають невеликим самописним скриптом, або пересилають у безкоштовний сторонній сервіс на кшталт dmarcian, який сам будує таблицю джерел відправлення і підсвічує, що проходить перевірку, а що ні.
Чи потрібно змінювати налаштування DKIM при переїзді пошти на Google Workspace чи інший SaaS?
Так, конфігурація на VPS через OpenDKIM у цьому випадку стає зайвою: ключ і підпис формує вже сам провайдер на своєму боці, залишиться лише додати його записи в DNS домену. Власний OpenDKIM і SaaS-провайдер одночасно підписувати одні й ті самі листи не повинні — це створює плутанину в перевірці.