Підключення Google Workspace до власного домену складається з трьох незалежних наборів DNS-записів: MX відповідає за маршрутизацію вхідної пошти, SPF і DKIM — за те, що листи від домену не відхилять як підробку, а DMARC — за політику для листів, які не пройшли перші дві перевірки. Помилка в будь-якому з трьох блоків ламає тільки свою частину: невірний MX зупиняє прийом пошти, а невірний SPF/DKIM зазвичай не заважає отримувати листи, але надіслані з домену листи починають потрапляти у спам або відхилятися отримувачами.
MX-записи для Google Workspace
| Пріоритет | Сервер |
|---|---|
| 1 | ASPMX.L.GOOGLE.COM |
| 5 | ALT1.ASPMX.L.GOOGLE.COM |
| 5 | ALT2.ASPMX.L.GOOGLE.COM |
| 10 | ALT3.ASPMX.L.GOOGLE.COM |
| 10 | ALT4.ASPMX.L.GOOGLE.COM |
Усі п'ять записів потрібно додати одночасно, без дублів і без старих MX від попереднього поштового сервісу — Google приймає пошту через будь-яку з п'яти за порядком пріоритету, прибирати «зайві» записи з однаковим пріоритетом 5 або 10 не потрібно, це штатна схема балансування навантаження.
SPF для Google Workspace
# TXT запис для @
v=spf1 include:_spf.google.com ~allАктивація DKIM у Google Admin
Google Admin Console → Apps → Google Workspace → Gmail → Authenticate email → Generate new record
Скопіюйте DKIM-запис і додайте як TXT у DNS:
# Ім'я запису:
google._domainkey.yourdomain.com
# Значення:
v=DKIM1; k=rsa; p=YOUR_PUBLIC_KEYПеревірка
# Перевірити MX
dig yourdomain.com MX
# Через Google Admin Toolbox
# toolbox.googleapps.com/apps/checkmx/Часті помилки при підключенні Google Workspace
| Повідомлення | Причина | Рішення |
|---|---|---|
| 550-5.7.1 The IP you're using to send mail is not authorized to send email directly to our servers | SPF-запис відправника не включає потрібний сервіс або IP | Перевірити dig TXT yourdomain.com і додати відсутній include-механізм |
| DKIM record not found. Public key not available for this selector | TXT-запис google._domainkey ще не поширився або створений з одруківкою в імені | Перевірити dig TXT google._domainkey.yourdomain.com, зачекати TTL запису |
| Mail loops back to sender / too many hops | На домені залишилися старі MX від попереднього поштового провайдера впереміш із записами Google | Видалити всі MX, крім п'яти офіційних записів Google |
| SPF Permanent Error: too many DNS lookups | SPF містить більше 10 механізмів include — обмеження RFC 7208 | Скоротити ланцюжок include, об'єднати сервіси через один плаский список |
Для швидкої діагностики корисний незалежний інструмент mail-tester.com: він надсилає адресу, на яку потрібно відправити тестовий лист, і за кілька секунд видає розбір SPF, DKIM і DMARC із зазначенням точної причини, якщо щось із них не пройшло перевірку — це швидше, ніж вручну парсити заголовки листа.
TTL для записів Google Workspace
| Запис | TTL | Коментар |
|---|---|---|
| MX | 3600 секунд | Google не змінює адреси серверів, стандартного TTL достатньо |
| TXT SPF | 3600 секунд | знижувати не потрібно, запис змінюється рідко |
| TXT DKIM | 3600 секунд | на час первинної активації можна тимчасово знизити до 300 |
При міграції з іншого поштового провайдера знижувати TTL потрібно заздалегідь, за 24–48 годин до перемикання MX, а не в момент самого перемикання — інакше частина вхідних листів ще добу йтиме на старий сервер, який уже не прийме їх на момент надходження.
DMARC поверх SPF і DKIM
SPF і DKIM самі по собі не кажуть отримувачу, що робити з листом, який їх не пройшов — за це відповідає DMARC. Запис створюється на піддомені _dmarc:
# TXT-запис для _dmarc.yourdomain.com
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=100Детальний план переходу від моніторингу до жорсткої політики розібрано у статті DKIM + SPF + DMARC на VPS — принцип поступового посилення однаковий незалежно від того, де розміщена пошта.
Звіти rua надходять раз на добу у вигляді XML-архівів від великих поштових систем — Gmail, Outlook, Yahoo. Дивитися їх вручну незручно, тому на практиці використовують безкоштовні парсери на кшталт dmarcian або Postmark DMARC Digests, які перетворюють архіви на читабельну таблицю джерел відправлення.
Коли стандартне налаштування не підходить
- Домен уже використовує стороннього провайдера розсилок для іншого сервісу — у зоні допустимий лише один TXT-запис типу SPF, потрібно об'єднати обидва джерела через один include, а не створювати другий запис
- Потрібен alias-домен усередині тієї самої організації Workspace — MX і SPF налаштовуються один раз на основному домені, alias-домен не повинен мати власних MX
- Використовується сторонній релей для масових розсилок — тоді додається окремий include до загального SPF, а не другий SPF-запис, який DNS формально дозволяє створити, але який SPF-валідатори обробляють непередбачувано
- Міграція з іншого провайдера пошти без простою вимагає зниження TTL MX і TXT за 24–48 годин заздалегідь, див. перевірку DNS propagation
Часті питання
З чого починати політику DMARC — одразу з жорсткого відхилення листів чи поступово?
Політику DMARC зазвичай вводять поетапно: спочатку режим спостереження, який не впливає на доставку і просто збирає звіти, потім м'яка обробка підозрілих листів, і лише після впевненості у стабільності — суворе відхилення. Різкий перехід одразу до відхилення ризикує заблокувати власні легітимні розсилки, якщо якийсь сервіс ще не покритий SPF чи DKIM.
Що відбувається з листами, які вже лежали у старій поштовій скриньці, після переходу на Google Workspace?
Старі листи залишаються там, де зберігалися до перемикання — сама зміна MX впливає лише на маршрут нових вхідних повідомлень, а не на архів уже отриманої пошти. Щоб нічого не втратити, попередню поштову скриньку варто не видаляти одразу після переходу, а вивантажити архів або залишити доступ до неї на час, поки не переконаєтесь, що вся важлива переписка перенесена.
Скільки зазвичай триває поширення нових DNS-записів інтернетом?
Швидкість поширення запису різними серверами залежить від TTL, який був встановлений для нього до зміни: поки не мине старий час життя запису, частина резолверів у світі видаватиме попереднє значення. Тому великі зміни планують заздалегідь, знижуючи TTL за деякий час до перемикання, а після перемикання перевіряють результат через зовнішні сервіси, а не покладаються лише на свій комп'ютер.
Чи потрібно одразу видаляти старі MX-записи попереднього поштового сервісу?
Видаляти старі MX одразу не обов'язково технічно, проте тримати їх разом із записами Google небажано: пошта може маршрутизуватися непередбачувано між двома сервісами, а частина листів — губитися між ними. Правильний порядок — додати п'ять записів Google, переконатися, що пошта стабільно надходить саме туди, і лише після цього прибрати записи попереднього провайдера.