Підключення пошти на своєму домені до Gmail чи Google Workspace ламається не тому, що це складно, а тому, що один запис забутий або два записи одного типу конфліктують. Нижче — прості пояснення, реальні DNS-записи нашого власного домену (не вигадані), типовий порядок робіт і чесна статистика доставлюваності з нашого власного прогріву пошти.
Біль
Живий доказ
carelinedesk.com — наш робочий домен для прогріву та розсилок. Записи нижче зняті напряму з DNS командою dig на нашому сервері, без редагування чи прикрас.
| Тип | Що показує | Значення |
|---|---|---|
| MX | Куди приймати пошту | 0 mx1.forwardemail.net. 0 mx2.forwardemail.net. |
| SPF (TXT) | Хто має право слати від імені домену | v=spf1 include:_spf.mailersend.net include:_spf.porkbun.com include:spf.forwardemail.net ~all |
| DKIM (CNAME) | Підпис листа приватним ключем | fe1._domainkey.carelinedesk.com → uixie.porkbun.com. |
| DMARC (TXT) | Що робити з листом, який провалив SPF/DKIM | v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-...@forwardemail.net; |
| NS | Хто відповідає за зону домену | curitiba/salvador/fortaleza/maceio.ns.porkbun.com. |
Знято командою dig з нашого сервера 2026-08-29 17:42 UTC. TTL записів на момент зняття — від 438 до 7039 секунд, тобто частина з них оновлюється швидше за годину, частина живе в кешах днями.
Що тут показово: DKIM тут — не звичайний TXT з ключем, а CNAME на хост провайдера (Porkbun хостить сам ключ і віддає його за цим селектором). Це поширений патерн у провайдерів, які «спрощують» DKIM — і саме тут найчастіше плутаються: селектор (fe1._domainkey) має бути прописаний рівно так, як вимагає постачальник пошти, інакше запис існує, а підпис не збігається.
DMARC тут стоїть у режимі p=reject, pct=100 — найжорсткіший режим: усе, що провалило перевірку, відкидається одразу, без винятків. Для порівняння, другий наш домен guardlabs.online зараз у м'якшому режимі p=quarantine (підозріле йде в спам, а не відкидається) — це типовий перший крок перед переходом на reject, поки ми не переконались, що жодне легітимне джерело не забите у SPF.
Порядок робіт
Домен вказує на NS-сервери, де ми керуємо записами — або напряму в реєстратора, або через окрему DNS-зону.
Прибираємо старі MX від конструктора сайту чи попереднього хостера — саме дублікат MX найчастіше рве доставку навпіл.
Окремий TXT- або CNAME-запис, яким Google підтверджує, що домен належить нам, перш ніж почати приймати пошту.
Один SPF на весь домен (об'єднуємо всі include, не додаємо другий запис), DKIM з селектором постачальника, DMARC — від none до reject поступово, за тиждень-два спостереження за звітами.
Контрольні листи на кілька поштових скриньок (Gmail, Outlook), перевірка — де саме лист опинився: у «Вхідних» чи в «Спамі».
Міграція листів зі старого поштовика на новий без втрати історії — окремий крок, який планується так, щоб користувачі не лишились на кілька годин без пошти.
Часті поломки і як їх видно
Найчастіше — DKIM не підписує (селектор не той) або DMARC у режимі none, тобто нічого не змушує Gmail довіряти джерелу. Перевіряється заголовками листа: рядки dkim=pass і spf=pass в Authentication-Results мають бути там, а не тільки записи в DNS.
Стандарт (RFC 7208) дозволяє рівно один запис SPF на домен. Якщо їх два — поштові сервери або беруть перший-ліпший, або вважають SPF непройденим повністю. Лікується об'єднанням усіх include в один рядок, а не додаванням другого.
TTL — це час життя запису в кеші резолверів. Якщо він стояв на 24 години, стара версія лишається видимою для частини світу цілу добу після зміни. Перед плановою зміною TTL варто заздалегідь занизити до кількох хвилин.
Що перевіряється прямо зараз
carelinedesk.com — не макет: домен реально прогрівається з 6 серпня 2026, з нього щодня йдуть контрольні листи на кілька поштових скриньок, і ми міряємо, куди вони приходять.
Чесно про сумнів: 29.08 о 03:41 UTC один лист на цьому ж домені потрапив у спам (n=1 на той момент, тобто 100% для однієї спроби) — за кілька годин показник вирівнявся до 0%. Це приклад того, чому одну відправку ніколи не видають за доказ «доставлюваність 100%»: на малій вибірці один лист хитає відсоток повністю, і саме тому ми зважаємо на 7-денне вікно, а не на останній лист.
За весь час прогріву — жодної помилки з 8 серпня. Три збої на старті (7 серпня) — це відповідь провайдера «домен ще на модерації для вихідного SMTP», типова затримка для нового домену, а не поломка DNS-записів.
Перевірте самі
# MX — куди приймається пошта dig +short MX carelinedesk.com # SPF — хто має право слати від імені домену dig +short TXT carelinedesk.com # DMARC — політика для листів, що провалили перевірку dig +short TXT _dmarc.carelinedesk.com # DKIM — куди делеговано підпис (тут CNAME, не голий TXT) dig +short CNAME fe1._domainkey.carelinedesk.com
Всі чотири команди публічні — жодних наших внутрішніх даних, лише те, що й так видно будь-кому в інтернеті. Це саме те, що перевіряє поштовий провайдер клієнта, перш ніж вирішити — довіряти листу чи ні.
Підключаємо пошту на власному домені до Gmail/Google Workspace — MX, SPF, DKIM, DMARC, перевірка доставлюваності — залиште заявку, відповімо швидко.