Руководство по настройке SPF-записи в GoDaddy на 2026 год

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

Самое неприятное в том, что ошибки SPF редко проявляются явно. Добавляется отправитель, один раз редактируется DNS, а через несколько недель команда сталкивается с попаданием в спам, ошибками аутентификации или ситуацией, когда одна платформа работает, а другая выпадает из списка. Если это звучит знакомо, значит, вы столкнулись с вопросами владения DNS, структурой записей и ограничением в 10 запросов, а не просто с “проблемами с почтой”.

Почему ваша SPF-запись в GoDaddy важнее, чем вы думаете

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

Вот почему неисправная SPF-запись в GoDaddy вредит сильнее, чем многие осознают. И Microsoft 365, и Google Workspace полагаются на сигналы аутентификации, которые почтовые провайдеры оценивают в фоновом режиме, поэтому отсутствие или неправильный формат SPF-записи могут повлиять на доставку во «Входящие» задолго до того, как кто-то заметит видимый сбой. Разница между hardfail и softfail здесь имеет значение, поскольку завершающий квалификатор сообщает получателям, следует ли отклонять неавторизованную почту сразу или относиться к ней с подозрением.

То, что упускают большинство команд

SPF не просто говорит: «этот домен ваш». Он говорит: «находится ли этот отправитель в утвержденном списке, опубликованном в DNS». Именно здесь начинает играть роль выравнивание SPF (SPF alignment), поскольку DMARC позже проверяет, совпадает ли видимый домен в поле From с аутентифицированным источником.

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

Собственные рекомендации GoDaddy отражают современный подход, при котором SPF публикуется как TXT-запись, а не как отдельная запись типа SPF, а рабочий процесс сосредоточен на редактировании DNS внутри портфолио доменов. Эта настройка звучит обыденно, но именно поэтому SPF так часто ломается. Запись легко добавить один раз и легко забыть о ней после одобрения следующего инструмента.

Добавление вашей первой SPF-записи в DNS GoDaddy

Начните с Портфолио доменов, откройте DNS и добавьте запись типа TXT. Справка GoDaddy показывает этот путь для настройки SPF: политика SPF вводится в поле Value, а хост устанавливается как корень (root), когда политика применяется ко всему домену, в то время как TTL остается на значении Default в задокументированном примере для связанных почтовых записей Справка GoDaddy по SPF-записям Поля DNS-записей GoDaddy для аутентификации почты.

Поля, которые имеют значение

Type должен быть TXT, а не SPF. Документация GoDaddy использует TXT, потому что это стандартный формат публикации для SPF в современном DNS, и такой выбор позволяет избежать двусмысленности при проверке валидаторами.

Name обычно должен быть @ для политики корневого домена. Это говорит GoDaddy, что запись относится к вершине домена, а не к поддомену. Value, это место, где живет строка SPF, поэтому именно туда вы вставляете саму политику.

TTL можно оставить на значении Default, если вы следуете задокументированной настройке GoDaddy, особенно если вы не находитесь в процессе устранения неполадок. Точные названия полей легко пропустить, но именно они определяют разницу между записью, которая находится в корне домена, и той, что лежит где-то в бесполезном месте.

Простой пример почты, управляемой GoDaddy, выглядит как v=spf1 include:secureserver.net -all, что является формой, которую GoDaddy показывает для хостинга почты. Если вы авторизуете только один источник отправителя, это именно тот вид, который вам нужен: одна запись, одна политика, одно место.

Для варианта, специфичного для Gmail, это руководство по SPF для пользователей Gmail показывает ту же логику «сначала TXT» на практике.

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

Позже в процессе интерфейс GoDaddy становится менее важным, чем авторитетная зона DNS, но первая победа заключается в том, чтобы запись была введена в правильное поле, с правильным типом и на правильном хосте.

Синтаксис SPF для используемых вами отправителей

Многие организации используют не одного отправителя. У них есть основная почта, маркетинговая платформа, CRM и транзакционная система. SPF-запись, это единое утверждение, которое авторизует их всех, поэтому реальная задача состоит в выборе правильных механизмов и сохранении списка достаточно коротким для проверки, прежде чем DNS GoDaddy начнет работать против вас.

Готовые строки SPF для распространенных стеков отправителей

Настройка отправителя	Значение SPF	Использованные запросы
Google Workspace	v=spf1 include:_spf.google.com -all	Один include, затем финальная проверка политики
Microsoft 365	v=spf1 include:spf.protection.outlook.com -all	Один include, затем финальная проверка политики
Google Workspace плюс маркетинговый инструмент	v=spf1 include:_spf.google.com include:servers.mcsv.net -all	Два include, плюс любые вложенные запросы внутри включенных записей
Microsoft 365 плюс транзакционный отправитель	v=spf1 include:spf.protection.outlook.com include:amazonses.com -all	Два include, плюс любые вложенные запросы внутри включенных записей

Эти строки полезны, потому что они показывают шаблон: одна запись, одна политика, одно место для управления ею в GoDaddy. Если ваш стек начинается с Google Workspace или Microsoft 365, а затем вырастает до маркетинговой и транзакционной почты, запись обычно перестает быть вопросом синтаксиса и становится вопросом того, сколько DNS-запросов каждый провайдер тратит в фоновом режиме.

Что делают механизмы

include говорит проверить политику SPF другого домена и унаследовать его авторизацию. Это рабочая лошадка для Google Workspace, Microsoft 365, Mailchimp, SendGrid и подобных платформ.

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

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

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

Часть, на которой спотыкаются реальные настройки GoDaddy,, это бюджет запросов. Каждый дополнительный include тратит этот бюджет, и запись может выглядеть чистой, но при этом не работать, потому что цепочка становится слишком глубокой. Стройте синтаксис вокруг стека, который вы используете, а не того, который вы хотели бы использовать.

Объединение нескольких отправителей без превышения лимита запросов

Главная проблема с SPF-записью в GoDaddy, это не синтаксис, а накопление. Домен начинается с одного отправителя, затем маркетинг добавляет другого, затем отдел продаж добавляет CRM, затем операции добавляют транзакционную платформу, и никто не замечает, что SPF теперь пытается валидировать больше систем, чем позволяет стандарт.

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

Как работает процесс объединения

Начните с перечисления всех легитимных отправителей. Затем объедините их в одну TXT-политику, используя операторы include, где провайдер управляет собственной инфраструктурой отправки. Если у вас уже есть запись в GoDaddy, отредактируйте ее вместо создания второй копии.

Вторая ловушка, вложенность. Один include может скрывать еще несколько запросов внутри собственной политики SPF провайдера, и именно поэтому домены могут исчерпать бюджет быстрее, чем ожидает команда. Рекомендации для GoDaddy предупреждают пользователей о необходимости оставаться в пределах 10 DNS-запросов, и этот лимит применяется во время оценки, а не постфактум Лучшие практики настройки SPF-записей для доменов GoDaddy Руководство по SPF для доменов GoDaddy на 2026 год.

Более чистая модель работы

• Сначала проверьте каждого отправителя: удалите старые инструменты, которые больше не отправляют почту, потому что устаревшие include все равно потребляют бюджет.
• Консолидируйте в одну политику: храните всю авторизацию в одной TXT-записи с правильным именем.
• Проверьте количество запросов перед сохранением: запись, которая выглядит аккуратно, все равно может не работать, если вложенные include выводят ее за пределы лимита.

Mail Merge for Gmail отлично вписывается в эту логику. Он отправляет письма через аутентифицированную инфраструктуру Google, поэтому ему не нужен собственный отдельный include, и он не увеличивает бюджет SPF, когда вы уже авторизовали Google Workspace.

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

Проверка того, что ваша запись действительно работает

Сохранение записи в GoDaddy, это не доказательство. Это означает лишь то, что изменение было введено, но не то, что авторитетная зона его отдает, не то, что кэши обновились, и не то, что политика корректно парсится.

Три проверки, три разных ответа

Первая проверка, это DNS-запрос к активной зоне. Запрос dig или nslookup показывает, что возвращают авторитетные серверы имен, что важно, потому что интерфейс GoDaddy может показать значение до завершения распространения, и он не скажет вам, если зона принадлежит другому DNS-хосту.

Вторая проверка, это SPF-парсер, такой как проверка SPF в MXToolbox. Подобный инструмент полезен, потому что он считывает синтаксис и одновременно подсчитывает запросы, что как раз и выявляет вложенные include и цепочки, превышающие лимит.

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

Практическое правило: если DNS выглядит корректно, но заголовки все равно показывают ошибку, проблема обычно находится на уровне валидации, а не в интерфейсе GoDaddy.

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

От прохождения SPF к полной аутентификации почты

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

Где место DKIM и DMARC

DKIM добавляет криптографическую подпись к самому сообщению. В DNS под управлением GoDaddy это обычно означает TXT-запись под хостом селектора, и Google Workspace обычно использует google._domainkey как часть этой настройки.

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

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

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

Для более глубокого изучения всего стека это руководство по аутентификации почты связывает SPF, DKIM и DMARC в один рабочий процесс.

Поддержание чистоты SPF во время реальных кампаний Mail Merge

Кампания Mail Merge быстро подвергает DNS-работу нагрузке. Отделы продаж, рекрутинга или организаторы мероприятий могут отправить чистую последовательность из Gmail в один день, а затем винить контент на следующей неделе, когда количество ответов падает, хотя более глубокой проблемой был дрейф аутентификации.

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

Чек-лист перед кампанией, который действительно помогает

• Подтвердите прохождение SPF для отправляющего аккаунта Google: протестируйте именно тот почтовый ящик, который будет отправлять кампанию, а не случайный алиас.
• Подтвердите, что DKIM включен в админ-панели Google Workspace: SPF сам по себе слишком хрупок для пересланной или повторно упакованной почты.
• Подтвердите, что DMARC настроен как минимум на p=none с включенными отчетами: это даст вам видимость до того, как вы ужесточите политику.

Зеленый результат SPF сам по себе не означает, что кампанию безопасно запускать. Это означает лишь то, что отправитель соответствовал текущей политике DNS в тот момент.

Лучшая привычка, относиться к SPF-записи как к сантехнике. Проверяйте ее перед кампанией, проверяйте ее, когда добавляется новый отправитель, и проверяйте ее снова, когда платформа меняет свой путь отправки. Именно так вы не дадите SPF-записи в GoDaddy превратиться в проблему с доставляемостью.

---

Mail Merge for Gmail помогает командам отправлять персонализированные кампании из Gmail, сохраняя путь отправки привязанным к Google Workspace, что упрощает работу с SPF, когда стек домена становится перегруженным. Если вы приводите в порядок настройки DNS в GoDaddy перед следующим запуском рассылки, посетите Mail Merge for Gmail и ознакомьтесь с тем, как он вписывается в рабочий процесс, который уже зависит от чистоты SPF, DKIM и DMARC.