Настройка SPF, DKIM и DMARC в Google Workspace

Что 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. Откройте Приложения → Google Workspace → Gmail → Аутентификация электронной почты.
2. Выберите домен, задайте ключ 2048 бит и нажмите Создать новую запись.
3. Google покажет TXT-запись с хостом google._domainkey. Опубликуйте её в DNS ровно в том виде, в каком она выдана.
4. Вернитесь и нажмите Начать аутентификацию.

Последний клик — та самая ловушка. Одна только опубликованная TXT-запись не делает ничего: Workspace не начнёт подписывать письма, пока вы не нажмёте Начать аутентификацию. Домены месяцами живут с безупречной записью DKIM, которая ни разу не использовалась. Если ваша панель DNS не принимает длинное значение 2048-битного ключа, разбейте его на строки в кавычках (большинство провайдеров понимают такой формат) или временно сгенерируйте ключ на 1024 бита и обновите позже.

Дайте DNS до 48 часов на распространение, прежде чем ждать успешной проверки DKIM.

Шаг 3 — опубликуйте DMARC с p=none

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

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

p=none означает «наблюдаем, не блокируем». На доставку это никак не влияет — запись лишь просит получателей присылать сводные отчёты о том, кто отправляет почту от имени вашего домена. Ради этой видимости всё и начинается. Собрать полную запись — вместе с политикой для поддоменов и параметрами отчётности — можно в бесплатном генераторе DMARC.

Указывайте в rua= адрес или сервис мониторинга, который кто-то действительно читает. Отчёты в заброшенном ящике бесполезны, а разбирать сводный XML руками — занятие на любителя.

Проверьте согласование, прежде чем ужесточать

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

Поэтому перед ужесточением политики прочитайте сводные отчёты и убедитесь, что все легитимные источники проходят проверку и согласованы. Когда отчёты чистые, двигайтесь поэтапно:

• p=none — наблюдаем, пока источники не согласуются
• p=quarantine — подозрительные письма уходят в спам
• p=reject — поддельные письма отклоняются сразу

День перехода на reject должен пройти незаметно — потому что отчёты уже показали, что ничего легитимного не сломается. Как читать эти отчёты, разбираем в статье «Как читать сводные отчёты DMARC».

Типичные ошибки в Workspace

• DKIM опубликован, но не «запущен». Проблема номер один. Проверьте, что вы нажали Начать аутентификацию.
• Две записи SPF. Объединяйте в одну; никогда не публикуйте вторую v=spf1.
• Больше 10 DNS-запросов в SPF. Каждый новый отправитель тихо ломает SPF — следите за счётчиком.
• Ранний переход на p=reject. Отправите в спам собственные счета и ответы клиентам. Право на применение политики зарабатывается доказательствами из отчётов.
• Открытые поддомены. p=reject на корневом домене не покрывает поддомены, если не задан sp=. Неиспользуемые поддомены — любимый вектор подделки.

Проверить, что получилось, можно бесплатной проверкой домена — она покажет текущее состояние SPF, DKIM и DMARC.