Налаштування SPF, DKIM і DMARC у Google Workspace

Якщо ваша пошта живе в Google Workspace, більшість потрібного для автентифікації домену у вас уже є. Проблема саме в слові «більшість». SPF Workspace проходить одразу, але підписувати вашу пошту ключем DKIM він не почне, доки ви явно це не увімкнете, а запис DMARC не опублікує за вас ніколи. Через цей розрив домен може роками «нормально працювати» — і залишатися придатним для підробки.

Нижче — три записи в тому порядку, у якому вони справді починають працювати, і помилки, що коштують командам тижня.

Що Google Workspace автентифікує від початку

Коли ви підтверджували домен, Google попросив додати MX-запис і, найімовірніше, запис SPF. Це закриває конверт — шлях, яким іде лист. Але двох речей, якими користуються зловмисники, це не закриває:

• Підпис DKIM від вашого домену. Workspace може підписувати пошту загальним ключем Google, однак той ключ узгоджується з доменом Google, а не з вашим. Щоб DMARC проходив саме на вашому домені, потрібен ключ DKIM, опублікований під вашим доменом. Типово він вимкнений.
• Політика DMARC. Без неї отримувач не має жодної інструкції на випадок, коли автентифікація провалилася, — тож він пропускає лист. Підроблене повідомлення спокійно долітає до скриньки.

Лікується це трьома DNS-записами. Закладіть на роботу півдня плюс 24–48 годин, поки почнуть надходити звіти.

Крок 1 — SPF для Google Workspace

SPF повідомляє отримувачам, які сервери мають право надсилати пошту від вашого домену. Для Workspace основний запис такий:

v=spf1 include:_spf.google.com ~all

Опублікуйте його як TXT-запис на кореневому домені (@). Два правила, на яких спотикаються найчастіше:

• Один запис SPF на домен. Якщо запис SPF уже є — скажімо, для платформи розсилок, — об'єднайте всі include в один. Два окремі записи v=spf1 — це гарантований провал.
• Стежте за лімітом у 10 DNS-запитів. Кожен include рахується. Складіть Workspace, CRM, службу підтримки й сервіс розсилок — і легко перевалите за десять запитів, а це знецінює SPF повністю. Якщо ви близько до межі, безкоштовний генератор SPF розгорне записи й порахує запити за вас.

Поки триває впровадження, залишайте ~all (м'який провал). Перейти на -all (жорсткий провал) можна тоді, коли DMARC уже працює в режимі примусового застосування.

Крок 2 — увімкніть DKIM у консолі адміністратора

Ось той крок, який найлегше зробити наполовину. У консолі адміністратора Google:

1. Відкрийте Apps → Google Workspace → Gmail → Authenticate email.
2. Виберіть домен, вкажіть довжину ключа 2048 біт і натисніть Generate new record.
3. Google покаже TXT-запис із хостом google._domainkey. Опублікуйте його в DNS рівно в тому вигляді, як показано.
4. Поверніться в консоль і натисніть Start authentication.

Останній клік — це і є пастка. Сам собою опублікований TXT-запис не робить нічого: Workspace не починає підписувати пошту, доки ви не натиснете Start authentication. Чимало доменів місяцями стоять із бездоганним записом DKIM, який ніколи не використовувався. Якщо ваша DNS-панель не приймає довге значення 2048-бітного ключа, розбийте його на рядки в лапках (більшість провайдерів розуміють такий формат) або тимчасово згенеруйте 1024-бітний ключ і замініть його пізніше.

Дайте DNS до 48 годин на поширення, перш ніж чекати, що DKIM почне проходити.

Крок 3 — опублікуйте DMARC із p=none

Тепер сама політика. Опублікуйте TXT-запис на хості _dmarc вашого кореневого домену:

v=DMARC1; p=none; rua=mailto:reports@yourdomain.com

p=none означає «спостерігати, не блокувати». На доставку це не впливає жодним чином — запис лише просить отримувачів надсилати вам зведені звіти про те, хто шле пошту від вашого імені. Заради цієї видимості з p=none і починають. Повний запис — разом із політикою для піддоменів і параметрами звітності — зручно зібрати в генераторі DMARC.

В rua= вкажіть адресу або сервіс, який хтось справді читає. Звіти, що падають у скриньку, куди ніхто не заглядає, марні, а розбирати сирий XML руками — окремий різновид страждань.

Перевірте узгодження, перш ніж посилювати політику

Ось частина, яку старі інструкції зазвичай пропускають. Пройдений SPF або DKIM — це ще не пройдений DMARC: автентифікований домен має узгоджуватися з доменом у видимому полі From:. Пошта Workspace узгодиться, щойно DKIM почне підписувати від вашого домену. А от сторонні відправники — CRM, білінг, розсилки — часто не узгоджуються, доки ви не налаштуєте кожен з них окремо.

Тому перш ніж закручувати гайки, прочитайте зведені звіти і переконайтеся, що кожне легітимне джерело автентифікується й узгоджується. Коли звіти чисті, рухайтеся поетапно:

• p=none — спостерігаєте, доки джерела не узгодяться;
• p=quarantine — підозріла пошта йде в спам;
• p=reject — підроблена пошта відхиляється одразу.

День переходу на reject має бути буденним, бо звіти вже показали: нічого легітимного не зламається.

Типові граблі Google Workspace

• DKIM опубліковано, але не «запущено». Проблема номер один. Перевірте, що ви натиснули Start authentication.
• Два записи SPF. Об'єднайте в один; ніколи не публікуйте другий v=spf1.
• SPF за межею 10 запитів. Кожен новий відправник тихо ламає SPF — перевіряйте кількість запитів.
• Поспішний перехід на p=reject. Ви відправите в спам власні рахунки й відповіді. Право на примусове застосування треба заробити доказами.
• Відкриті піддомени. p=reject на кореневому домені не поширюється на піддомени, доки ви не задасте sp=. Невикористовувані піддомени — улюблений вектор підробки.

Часті питання

Чи налаштовує Google Workspace DMARC автоматично? Ні. Workspace бере на себе SPF на етапі підтвердження домену і вміє згенерувати ключ DKIM, але увімкнути підписування DKIM та опублікувати запис DMARC маєте ви. Жоден із трьох механізмів нічого не захищає, доки ви його не налаштуєте.

Чому DKIM не працює, хоча запис я вже додав? Майже завжди тому, що автентифікацію так і не запустили. Опублікувати TXT-запис google._domainkey — це лише половина кроку: поверніться до Apps → Gmail → Authenticate email і натисніть Start authentication. Далі дайте до 48 годин.

Чи можна одразу поставити p=reject? Технічно можна, але не варто. Доки звіти не підтвердять, що всі легітимні джерела узгоджені, p=reject ризикує заблокувати вашу власну пошту. Почніть з p=none, перевірте, потім посилюйте.

---

Коли три записи працюють, а звіти чисті, робота переходить із налаштування в моніторинг: треба помітити новий сервіс, який хтось під'єднає наступного кварталу, перш ніж він тихо провалить автентифікацію. Саме для цього й зроблено DDMARC — зрозумілі звіти замість сирого XML і сповіщення, коли щось поїхало.