Google Workspace: настройка MX и DNS для почты

Подключение Google Workspace к собственному домену состоит из трёх независимых наборов DNS-записей: MX отвечает за маршрутизацию входящей почты, SPF и DKIM — за то, что письма от домена не отклонят как подделку, а DMARC — за политику для писем, не прошедших первые две проверки. Ошибка в любом из трёх блоков ломает только свою часть: неверный MX останавливает приём почты, а неверный SPF/DKIM обычно не мешает получать письма, но отправленные с домена письма начинают падать в спам или отклоняться получателями.

MX-записи для Google Workspace

Все пять записей нужно добавить одновременно, без дублей и без старых 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

Для быстрой диагностики полезен независимый инструмент mail-tester.com: он присылает адрес, на который нужно отправить тестовое письмо, и через несколько секунд выдаёт разбор SPF, DKIM и DMARC с указанием точной причины, если что-то из них не прошло проверку — это быстрее, чем вручную парсить заголовки письма.

TTL для записей Google Workspace

При миграции с другого почтового провайдера снижать 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, убедиться, что почта стабильно приходит именно туда, и только после этого убрать записи прежнего провайдера.