Google Workspace: настройка MX-записей, SPF, DKIM и DMARC

Шаги

1. Подтвердите домен. Добавьте домен в консоли администратора Google и опубликуйте TXT-запись для подтверждения, которую она покажет. Значение уникально для вашей учётной записи.
2. Создайте пользователей. Создайте все ящики и псевдонимы до переноса MX, чтобы после переключения ни один адрес не возвращал письма.
3. Опубликуйте MX-запись. Удалите MX-записи старого провайдера и добавьте одну MX-запись с приоритетом 1, указывающую на smtp.google.com.
4. Опубликуйте SPF. Добавьте одну TXT-запись на самом домене: v=spf1 include:_spf.google.com ~all. Если от имени домена отправляют и другие сервисы, добавьте их include: в ту же запись.
5. Включите DKIM. В консоли администратора создайте 2048-битный ключ, опубликуйте показанную TXT-запись по имени google._domainkey, затем вернитесь в те же настройки DKIM и запустите там аутентификацию. Пока вы этого не сделаете, Google подписывает письма собственным доменом и DKIM не выравнивается с вашим.
6. Добавьте DMARC и проверьте. Опубликуйте DMARC-запись с p=none, затем запустите проверки на этой странице.

DMARC

DMARC одинаков для всех провайдеров: одна TXT-запись по имени _dmarc.example.com. Начните с p=none и адреса для отчётов: так вы будете получать отчёты, не влияя на доставку.

Читайте отчёты несколько недель. Когда каждый легитимный отправитель проходит SPF или DKIM с выровненным доменом, переходите на p=quarantine, а затем на p=reject. Переход на reject до того, как DKIM включён у всех отправителей, — обычная причина потери легитимных писем.

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Дополнительно: MTA-STS, TLS-RPT и BIMI

MTA-STS сообщает отправляющим серверам, что при доставке вам нужно требовать TLS. Нужны TXT-запись и файл политики, который отдаётся по HTTPS с mta-sts.example.com; в политике должны быть точно перечислены MX-хосты вашего провайдера.

TLS-RPT просит отправителей сообщать о сбоях TLS при доставке на выбранный вами адрес. Одна TXT-запись, на доставку не влияет.

BIMI позволяет некоторым почтовым сервисам показывать ваш логотип. Для него нужен DMARC с политикой quarantine или reject, а большинство сервисов требует ещё и сертификат подтверждённого знака.

_mta-sts.example.com.  3600  IN  TXT  "v=STSv1; id=20260921T000000"
_smtp._tls.example.com.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"
default._bimi.example.com.  3600  IN  TXT  "v=BIMI1; l=https://example.com/logo.svg"

Советы по TTL

Прежде чем менять MX-записи домена, который уже принимает почту, снизьте их TTL до 300 секунд и дождитесь, пока истечёт старый TTL. После этого резолверы подхватят новые записи за считаные минуты.

Когда новая настройка проработает несколько дней, снова поднимите TTL: часто используют 3600 секунд. Записи SPF, DKIM и DMARC меняются редко, для них 3600 вполне подходит.

Сколько времени занимают изменения?

Ваши авторитетные NS-серверы отвечают новой записью, как только DNS-хостинг её опубликовал. Резолвер, у которого в кеше старый ответ, хранит его до истечения старого TTL; имя, которого раньше не было, может считаться отсутствующим в течение времени негативного кеширования из вашей SOA-записи.

Момента, когда изменение оказывается сразу везде, не существует. Инструмент проверки распространения показывает, что отвечает фиксированный набор публичных резолверов в момент проверки, в виде счёта, например «9 из 12 резолверов», и ничего сверх этого.

Провайдеры перепроверяют ваши записи по собственному расписанию, поэтому кнопка проверки в панели может ещё какое-то время оставаться красной, когда DNS уже настроен верно.

Частые ошибки

• DKIM-запись опубликована, но аутентификация в консоли администратора так и не запущена.
• Оставить ~all навсегда в случае Google допустимо; а вот переход на -all до того, как в записи перечислены все отправители, как раз и ломает сервисы пересылки и инструменты рассылок.
• Две SPF-записи. У домена может быть только одна TXT-запись, начинающаяся с v=spf1; вторая приводит к постоянной ошибке SPF. Объедините механизмы include: в одной записи.
• MX-записи старого провайдера оставлены рядом с новыми. Тогда почта попадает то к одному, то к другому — в зависимости от приоритета и случая.
• Полное имя введено в поле хоста, которое само дописывает домен: получается google._domainkey.example.com.example.com. После сохранения проверьте запись запросом.
• DKIM-ключ, обрезанный посередине. Длинные TXT-значения нужно делить на строки в кавычках длиной не более 255 символов; большинство DNS-хостингов делает это за вас, но не все.
• Больше десяти DNS-запросов в SPF после добавления нескольких механизмов include:. Инструмент «Проверка SPF» их считает.
• MX-запись, указывающая на CNAME или на IP-адрес. Она должна указывать на имя хоста, у которого есть записи A или AAAA.