SPF-запись для Gmail: пошаговое руководство на 2026 год

Вы запускаете рассылку обновлений для клиентов, письмо о найме или серию торговых предложений из Gmail. Текст отличный. Список контактов чист. Но ответы приходят все реже, или, что еще хуже, кто-то сообщает вам, что ваше сообщение попало в спам.

В небольших командах это обычно заставляет людей в первую очередь проверять темы писем, шаблоны и объем рассылки. Это справедливо. Но одна из самых распространенных причин кроется вне Gmail, в ваших настройках DNS. Ваша SPF-запись решает, будут ли принимающие почтовые серверы рассматривать Gmail как одобренного отправителя для вашего домена.

Это имеет еще большее значение, если вы изучаете инструменты для рассылок на базе Gmail. Будьте осторожны с названиями продуктов, которые звучат обобщенно, особенно Mail Merge for Gmail. Эта фраза описывает как категорию, так и конкретный продукт, поэтому легко прочитать советы по настройке, предназначенные для другого инструмента слияния почты, и применить их к неверной системе.

Почему ваша SPF-запись для Gmail имеет значение

Полезно думать об SPF как о списке гостей для вашего домена. Когда ваше письмо достигает другого почтового сервера, этот сервер проверяет, есть ли отправитель в списке. Если Gmail в нем есть, у вашего сообщения гораздо больше шансов быть воспринятым как легитимное. Если Gmail в нем нет, у получателя есть повод не доверять сообщению еще до того, как он прочитает тему письма.

Эта проблема доверия проявляется в обычных деловых ситуациях. Основатель отправляет приветственные письма. HR-менеджер рассылает приглашения на собеседование. Школа отправляет родителям обновления о мероприятиях. Внутри Gmail все выглядит нормально, но принимающий сервер не видит четкой авторизации для вашего домена и начинает обрабатывать эти сообщения с большей осторожностью.

Что защищает SPF

SPF выполняет две задачи одновременно:

• Защита доставки: помогает принимающим серверам распознать, что Google разрешено отправлять письма от имени вашего домена.
• Защита бренда: затрудняет возможность для кого-то другого подделать ваш домен в исходящей почте.

SPF сообщает внешнему миру, какие системы отправки говорят от имени вашего домена, а какие нет.

Если вы пытаетесь повысить успех email-маркетинга, это одна из первых технических проверок, которую стоит выполнить. Лучший текст не компенсирует домен, который не прошел надлежащую аутентификацию.

Почему маленькие ошибки вызывают большие проблемы

Самое неприятное то, что проблемы с SPF часто не выглядят как проблемы с SPF. Сообщения могут по-прежнему отправляться. Некоторые получатели могут их получать. Другие могут видеть попадание в спам, предупреждения или скрытую фильтрацию. Именно эта непоследовательность сбивает людей с толку.

Если ваши письма уже попадают в папки с нежелательной почтой, стоит дополнить это руководство по настройке практическим описанием того, как предотвратить попадание электронной почты в спам. SPF не является единственным фактором доставляемости, но это одно из немногих исправлений, которое напрямую повышает доверие на уровне домена, вместо того чтобы просто менять контент и надеяться на лучшее.

Создание основной SPF-записи для Gmail

Если ваш домен отправляет электронную почту только через Gmail или Google Workspace, настройка проста. Официальная SPF-запись Google, это точная строка, задокументированная в справке администратора Google Workspace:

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

Это значение должно быть опубликовано как одна TXT-запись в корне вашего домена. В большинстве панелей управления DNS хостом является @. Google также рекомендует значение TTL 3600 секунд (1 час), а изменения DNS могут занять до 48 часов для полного распространения в зависимости от вашего провайдера, согласно той же документации Google Workspace.

Что вводить в DNS

Независимо от того, управляется ли ваш DNS в GoDaddy, Cloudflare, Namecheap или у другого провайдера, поля обычно сопоставляются следующим образом:

1. Тип: TXT
2. Хост или имя: @
3. Значение или содержимое: указанная выше SPF-строка
4. TTL: 3600, если ваш провайдер позволяет установить его вручную

Самая распространенная ошибка здесь, переусложнение типа записи. Многие панели DNS больше не предлагают отдельный тип записи SPF. Это нормально. Вам нужна запись TXT.

Краткий визуальный обзор может помочь, если вы редактируете DNS впервые:

Что работает, а что нет

Вот практическая версия.

• Работает: добавление одной TXT-записи в корне домена с точным значением SPF для Gmail.
• Не работает: добавление лишних пробелов, разделение значения на отдельные SPF-записи или публикация под неверным хостом, например, поддоменом, когда почта отправляется с основного домена.

Практическое правило: Скопируйте значение SPF точно, опубликуйте его один раз и сопротивляйтесь желанию создать вторую SPF-запись позже, когда добавите другого отправителя.

Если вы находитесь в простой среде, где используется только Gmail, этого обычно достаточно, чтобы правильно выполнить настройку SPF-записи для Gmail. Сохраните запись, дождитесь распространения и проверьте ее, прежде чем менять что-либо еще.

Работа с несколькими отправителями почты и слиянием почты

Типичная настройка малого бизнеса выглядит так. Сотрудники отправляют обычную почту из Google Workspace, маркетинг проводит кампании из инструмента слияния почты, а CRM или служба поддержки отправляют автоматические сообщения с того же домена. SPF должен охватывать их всех, иначе одна из этих систем начнет выдавать сбои аутентификации.

Именно здесь ломаются многие настройки SPF для Gmail. Базовая запись Google проста. Сложность начинается, когда каждый новый инструмент просит вас добавить еще одну запись include:, и никто не проверяет, что эти дополнения делают с полной записью.

Два правила, которые важнее всего

Правило первое: опубликуйте одну SPF TXT-запись для домена.

Правило второе: удерживайте полное количество проверок SPF в пределах 10 DNS-запросов. Этот лимит включает вложенные запросы внутри каждого include:. Запись может выглядеть короткой в вашей панели DNS и все равно не пройти проверку, потому что SPF-запись одного поставщика расширяется в несколько дополнительных проверок. Этот разбор от DMARC Report объясняет, почему количество запросов важно при настройке SPF для Gmail.

Среды с несколькими отправителями достигают этого лимита быстрее, чем ожидают люди. Google Workspace плюс отправитель слияния почты, CRM и платформа поддержки могут создать вам проблемы, даже если инструкции каждого поставщика технически верны сами по себе. Ошибка заключается в том, чтобы рассматривать каждого отправителя как отдельный DNS-проект, а не как одну объединенную политику авторизации.

Как выглядит правильное объединение

Если Gmail и другой одобренный сервис отправляют почту для вашего домена, добавьте обоих отправителей в одну и ту же SPF-запись.

Сценарий	Правильная объединенная SPF-запись
Только Gmail	v=spf1 include:_spf.google.com ~all
Gmail плюс один сторонний отправитель	v=spf1 include:_spf.google.com include:spf.thirdparty.com ~all
Gmail плюс несколько отправителей	v=spf1 include:_spf.google.com include:spf.vendorone.com include:spf.vendortwo.com ~all

Эти примеры показывают структуру. Ваши фактические сторонние значения должны быть взяты из документации каждого провайдера. Практический момент остается неизменным. Один домен получает одну SPF-запись.

Что обычно ломается в реальной жизни

Я обычно вижу три шаблона сбоев.

• Публикуется вторая SPF-запись. Кто-то добавляет новую TXT-запись, начинающуюся с v=spf1, вместо редактирования существующей.
• Старые сервисы остаются авторизованными навсегда. Бизнес перестает использовать инструмент, но его include: остается в DNS и продолжает потреблять запросы.
• Слияние почты рассматривается как “просто Gmail”. Некоторые инструменты отправляют через инфраструктуру Google, в то время как другие отправляют через свои собственные серверы или подключенного провайдера. Эта разница меняет необходимость добавления еще одного include в SPF.

Третий пункт часто упускают из виду. Если ваша команда использует рабочий процесс на основе Google Таблиц, уточните, как этот инструмент отправляет почту, прежде чем трогать DNS. Руководство по слиянию почты из Google Таблиц может помочь вам составить карту рабочего процесса, но SPF все равно зависит от инфраструктуры отправки, стоящей за этим процессом.

Как оставаться в пределах лимита 10 запросов

Начните с инвентаризации отправителей. Перечислите каждую систему, которой разрешено отправлять почту от имени вашего домена. Включите маркетинговые платформы, CRM, инструменты поддержки, приложения для выставления счетов, формы на веб-сайте и любой продукт для слияния почты.

Затем жестко сократите этот список.

Удалите отправителей, которых вы больше не используете. Проверьте, отправляют ли два инструмента почту через одного и того же провайдера, что может сделать один include ненужным. Если поставщик предлагает более одного варианта SPF, выберите тот, который они рекомендуют для вашего случая использования, а не вставляйте каждую запись, которую сможете найти.

Если запись все еще слишком велика, ответом является не вторая SPF-запись. Ответом является сокращение количества авторизованных путей отправки или, в некоторых случаях, использование поддомена для отдельного потока почты, чтобы SPF-запись основного домена оставалась управляемой.

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

Как проверить, работает ли ваша SPF-запись

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

Сначала используйте валидатор

Начните с публичного SPF-чекера, такого как MxToolbox или dmarcian SPF Surveyor. Они полезны тем, что не просто подтверждают наличие TXT-записи. Они также проверяют структуру и, в случае более сложных запросов, помогают увидеть, создают ли ваши includes слишком много DNS-запросов.

Введите имя вашего домена и внимательно изучите результат. Вы ищете три вещи:

• Запись найдена: инструмент видит вашу SPF TXT-запись в публичном DNS.
• Синтаксис верный: нет ошибочных механизмов, лишних пробелов или дублирующихся SPF-записей.
• Цепочка управляема: includes не расширяются в нерабочий результат.

Как выглядит хороший результат

Здоровая проверка обычно выглядит скучно, и это именно то, что вам нужно. Инструмент находит одну SPF-запись, чисто ее парсит и не помечает постоянную ошибку.

Неудачный результат обычно попадает в одну из этих категорий:

• SPF-запись не найдена: запись еще не распространилась, была сохранена под неверным хостом или так и не была опубликована.
• Найдено несколько SPF-записей: вы добавили вторую TXT-запись v=spf1 вместо редактирования существующей.
• Слишком много запросов: ваш объединенный список отправителей слишком велик или слишком вложен.

Проверьте также живое письмо

Валидаторы хороши для структуры. Реальное сообщение подтверждает поведение.

Отправьте тестовое письмо на почтовый ящик Gmail, к которому у вас есть доступ. Откройте сообщение, используйте опцию Gmail для просмотра исходного текста сообщения и изучите результаты аутентификации. Если SPF проходит проверку, это верный признак того, что ваш публичный DNS и ваш реальный путь отправки согласованы.

Инструменты проверки говорят вам, является ли DNS-запись публикуемой. Живой тест говорит вам, соответствует ли ваш фактический поток почты политике DNS.

Если валидатор проходит, но живые сообщения все еще ведут себя некорректно, проблема может заключаться в другом месте вашего стека аутентификации, а не только в SPF.

Устранение распространенных ошибок SPF-записи

Проблемы с SPF обычно становятся очевидными сразу после изменений. Малый бизнес начинает отправлять предложения из Google Workspace, добавляет инструмент слияния почты, а затем замечает, что ответы приходят медленнее или сообщения попадают в спам. На практике проблема часто заключается в одной ошибке DNS, а не в сложной почтовой проблеме.

Найдено несколько SPF-записей

Симптом: ваш валидатор сообщает о нескольких SPF-записях, или принимающие серверы возвращают постоянную ошибку SPF.

Причина: в вашем домене более одной TXT-записи, начинающейся с v=spf1. Я вижу это после того, как бизнес добавляет второго отправителя, например, CRM или платформу для рассылок, и руководство по настройке нового поставщика выполняется буквально. SPF не объединяет эти записи. Получатели видят конфликт и считают его недействительным.

Решение: сохраните одну SPF-запись для домена и включите каждого одобренного отправителя в эту единственную TXT-запись. Если у вас уже есть отдельные записи, выберите одну в качестве основной, объедините необходимые механизмы, а затем удалите лишние.

Слишком много DNS-запросов

Симптом: запись выглядит полной, но SPF все равно не проходит проверку с ошибкой лимита запросов или permerror.

Причина: проверки SPF могут следовать только за ограниченным количеством DNS-запросов. Это ошибка, которую часто пропускают базовые руководства по SPF для Gmail. Она проявляется в реальных средах, где Google Workspace, лишь один отправитель среди нескольких, особенно если вы также используете программное обеспечение для слияния почты, службу поддержки, систему выставления счетов и маркетинговую платформу с того же домена. Каждый include: может подтягивать больше includes под собой, поэтому запись, которая выглядит короткой, все равно может превысить лимит.

Решение: сократите список отправителей, прежде чем пробовать что-то хитрое. Удалите сервисы, которые больше не отправляют почту для вашего домена. Спросите каждого поставщика, нужны ли все их опубликованные includes для вашего случая использования. Если ваш стек все еще слишком велик, разделите потоки почты по поддоменам. Например, оставьте обычную почту сотрудников на основном домене, а рассылки или массовую почту перенесите на поддомен с собственной политикой SPF. Такой подход часто является самым чистым решением в настройке с несколькими отправителями, потому что он снижает нагрузку на запросы и не дает одной раздутой записи сломать все остальное.

Проблемы с синтаксисом и отсутствующие записи

Симптом: запись существует в DNS, но валидатор помечает ошибки форматирования, или SPF-запись вообще не найдена.

Причина: это обычно происходит из-за плохой вставки, неверного значения хоста или публикации SPF-строки не в том поле. В cPanel, GoDaddy, Cloudflare и заменах Google Domains метки различаются достаточно сильно, чтобы запутать начинающих администраторов. Запись, предназначенная для корневого домена, может быть введена под www, или TXT-значение может быть разделено неверно.

Решение: сравните опубликованное TXT-значение с предполагаемой записью символ за символом. Подтвердите, что хост верен для домена, который вы аутентифицируете, и убедитесь, что вы создали TXT-запись, а не запись другого типа. Если синтаксис в порядке, но почта все равно не проходит, пересмотрите более широкую настройку аутентификации электронной почты для пользовательских доменов, потому что SPF-запись может быть действительной, в то время как другой элемент управления аутентификацией вызывает проблему.

Практический порядок устранения неполадок

Используйте этот порядок, когда SPF ломается:

1. Проверьте наличие дубликатов SPF-записей. Это самая быстрая проблема для подтверждения и исправления.
2. Внимательно изучите текст записи. Ищите опечатки, пропущенные пробелы, лишние кавычки или неверный хост.
3. Составьте карту каждого сервиса отправки. Включите Google Workspace, инструменты слияния почты, CRM, платформы поддержки и все остальное, что отправляет почту от имени вашего домена.
4. Подсчитайте количество запросов в includes. Если список переполнен, упростите его или перенесите некоторых отправителей на поддомен.

Этот порядок экономит время, потому что он соответствует тому, как SPF обычно ломается на практике. Небольшие команды часто предполагают, что проблему вызвал новейший инструмент, но старый DNS-мусор встречается так же часто. Если вам нужен более широкий операционный чек-лист, пока вы наводите порядок, руководство Simply Tech Today по безопасности электронной почты является полезным справочником.

За пределами SPF: ваши следующие шаги в аутентификации электронной почты

Малый бизнес может опубликовать правильную SPF-запись и все равно наблюдать, как сообщения попадают в спам, когда счета, рассылки и последующие письма начинают уходить из разных систем. Обычно это происходит в смешанных настройках, особенно когда Google Workspace обрабатывает повседневную почту, а другой инструмент отправляет кампании или слияния почты с того же домена.

SPF покрывает только часть решения, которое принимает принимающий почтовый сервер. Он проверяет, разрешено ли отправляющему серверу использовать ваш домен. Это важно, но не доказывает, что сообщение было подписано правильно, и не говорит принимающему серверу, что делать, когда аутентификация не удается.

Именно здесь на помощь приходят DKIM и DMARC, и они имеют еще большее значение в средах с несколькими отправителями.

DKIM добавляет криптографическую подпись к сообщению, чтобы принимающие серверы могли подтвердить, что сообщение легитимно и не было изменено после того, как покинуло вашу систему. DMARC находится поверх SPF и DKIM и сообщает почтовым провайдерам, как оценивать эти проверки для вашего домена. Он также предоставляет вам отчетность, которая часто является первым четким представлением об отправителе, о котором вы забыли, что он использует ваш домен.

Это тот момент, который упускают многие базовые руководства по SPF. Если вы используете Google Workspace, инструмент слияния почты, CRM и платформу поддержки, SPF может стать трудным в обслуживании из-за лимита в 10 запросов. DKIM помогает уменьшить зависимость только от SPF, а DMARC дает вам уровень политики, чтобы ваш домен не оценивался только по одной переполненной TXT-записи.

Для следующего технического шага после SPF ознакомьтесь с этим руководством по аутентификации электронной почты для пользовательских доменов. Оно дает практический путь настройки для DKIM и DMARC после того, как ваша SPF-запись уже установлена.

Если вам нужен более широкий операционный чек-лист, руководство Simply Tech Today по безопасности электронной почты станет полезным дополнением.

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