Пошта на кшталт info@yourcompany.com замість yourcompany@gmail.com — базова ознака серйозного бізнесу. Для її налаштування потрібно правильно вказати DNS-записи домену.
Мінімальний набір DNS-записів для пошти
| Запис | Призначення | Приклад |
|---|---|---|
| MX | Адреса поштового сервера | mail.example.com (пріоритет 10) |
| A | IP поштового сервера | mail IN A 192.168.1.1 |
| TXT (SPF) | Авторизовані відправники | v=spf1 mx ~all |
| TXT (DKIM) | Цифровий підпис листів | Генерує поштовий сервер |
| TXT (DMARC) | Політика обробки | v=DMARC1; p=quarantine |
Налаштування для Google Workspace
# MX-записи Google Workspace
@ IN MX 1 aspmx.l.google.com.
@ IN MX 5 alt1.aspmx.l.google.com.
@ IN MX 5 alt2.aspmx.l.google.com.
@ IN MX 10 alt3.aspmx.l.google.com.
@ IN MX 10 alt4.aspmx.l.google.com.
# SPF для Google Workspace
@ IN TXT "v=spf1 include:_spf.google.com ~all"Налаштування для Zoho Mail (безкоштовний план)
# MX-записи Zoho Mail
@ IN MX 10 mx.zoho.eu.
@ IN MX 20 mx2.zoho.eu.
@ IN MX 50 mx3.zoho.eu.
# SPF для Zoho Mail
@ IN TXT "v=spf1 include:zoho.eu ~all"Налаштування для власного сервера (cPanel/Exim)
# MX-запис
@ IN MX 10 mail.example.com.
# A-запис поштового сервера
mail IN A YOUR.SERVER.IP
# SPF (дозволити власний IP та MX)
@ IN TXT "v=spf1 ip4:YOUR.SERVER.IP mx ~all"nslookup -type=MX example.comЧасті помилки доставки пошти
| Повідомлення або симптом | Причина | Рішення |
|---|---|---|
| 550 5.7.1 SPF check failed | IP сервера, що надсилає лист, не вказано в SPF-записі домену, або SPF містить помилку в include-механізмі | Додати IP або include потрібного сервісу в SPF, перевірити синтаксис через онлайн-валідатор SPF |
| 550 5.7.26 The message could not be authenticated over IPv6 without DKIM | Google вимагає DKIM для надсилання по IPv6, наявності лише SPF недостатньо | Увімкнути і опублікувати DKIM-запис на сервері, що надсилає пошту |
| Лист доставлено, але позначено як Spam із позначкою dmarc=fail | DMARC-політику налаштовано на p=reject або p=quarantine, а SPF/DKIM не проходять alignment (домен From не збігається з доменом підпису) | Перевірити, що домен у заголовку From збігається з доменом DKIM d= і доменом SPF-перевірки |
| Temporary failure in name resolution під час надсилання | MX-запис вказує на ім'я, яке саме не резолвиться (немає A-запису) або резолвиться із затримкою | Переконатися, що ім'я з MX має чинний A-запис і не є CNAME (RFC забороняє CNAME для цілей MX) |
| SPF Permerror: too many DNS lookups | Перевищено ліміт у 10 DNS-запитів на резолвінг SPF (RFC 7208) — зазвичай через ланцюг вкладених include | Скоротити кількість include, замінити частину механізмів на прямі ip4/ip6 |
DKIM: як перевірити підпис
DKIM додає криптографічний підпис у заголовок листа. Публічний ключ публікується в TXT-записі вигляду selector._domainkey.example.com, де selector — довільне ім'я, яке задає поштовий сервер (наприклад, google або default).
# Перевірити публічний ключ DKIM для селектора google
dig TXT google._domainkey.example.com +short
# Перевірити заголовок Authentication-Results в отриманому листі
# (показує результат SPF, DKIM і DMARC на боці отримувача)Якщо селектор невідомий — його можна дізнатися в заголовках будь-якого листа, надісланого з домену: рядок DKIM-Signature: ... s=selector1 містить потрібне значення.
DMARC: розбір політики
| Значення p= | Дія отримувача | Коли використовувати |
|---|---|---|
| none | Лише звіти, листи доставляються як зазвичай | Перший етап впровадження — збір даних без ризику втратити листи |
| quarantine | Листи, що не пройшли перевірку, потрапляють у спам | Після тижня-двох чистих звітів none без хибних спрацювань |
| reject | Листи, що не пройшли перевірку, відхиляються повністю | Фінальний етап, коли всі легітимні джерела надсилання враховано в SPF/DKIM |
Перехід одразу на p=reject без проміжного none — часта причина втрати легітимної пошти: будь-який забутий сервіс розсилок або CRM, що надсилає листи від імені домену, почне отримувати відмови без попередження.
Коли потрібен окремий піддомен для розсилок
- Транзакційні та маркетингові листи йдуть через зовнішній сервіс (SendGrid, Mailgun) — репутація розсилок не повинна впливати на репутацію основного домену
- Обсяг розсилок перевищує кілька тисяч листів на день — різке зростання обсягу з основного домену може сприйматися спам-фільтрами як аномалія
- Різні відправники (підтримка, білінг, маркетинг) використовують різні DKIM-селектори і політики DMARC для незалежного моніторингу репутації
- Потрібно протестувати нового провайдера розсилок без ризику для доставлюваності листів з основного домену
Якщо листи все одно потрапляють у спам після налаштування SPF і DKIM, перевірте зворотний DNS сервера — див. налаштування PTR-запису.
Часті питання
Що станеться з наявною поштою, якщо змінити MX-записи без попередньої підготовки?
Зміна MX-записів перемикає приймання нової вхідної пошти на інший сервер, але листи, що вже лежать у скриньках старого сервісу, нікуди не переносяться автоматично. Перед перемиканням варто вивантажити наявне листування або налаштувати паралельне приймання на обох серверах на перехідний період, інакше частина листів, надісланих під час зміни записів, може загубитися.
Чи потрібно видаляти старий запис SPF під час переходу з одного поштового провайдера на інший?
Так, старий запис SPF варто замінити новим або об'єднати обидва include-механізми в одному записі, а не залишати два окремих TXT-записи SPF одночасно — поштові сервери, отримавши кілька SPF-записів для одного домену, вважають таку конфігурацію помилковою і можуть відхиляти листи. Правильний спосіб — один TXT-запис із переліком усіх дозволених відправників через include.
Скільки часу застосовуються зміни DNS-записів для пошти після їх збереження?
Час застосування залежить від значення TTL конкретного запису і від кешування на боці провайдерів доступу та поштових серверів — зазвичай зміни видно протягом кількох годин, але повне поширення по всіх вузлах інтернету може зайняти довше. Перед важливим перемиканням варто заздалегідь знизити TTL запису, щоб скоротити час очікування під час наступної зміни.
Чи можна використовувати кілька сервісів розсилки одночасно з одним SPF без перевищення ліміту запитів?
Використовувати кілька сервісів розсилки одночасно можна, але кожен доданий include у записі SPF збільшує кількість DNS-запитів під час перевірки, і перевищення ліміту призводить до помилки Permerror, після якої пошта з домену може не проходити перевірку взагалі. Щоб залишатися в межах ліміту, частину сервісів варто підключати через прямі IP-адреси замість вкладених include-механізмів.