SPF-запись для почты: настройка корпоративного домена

Ваше письмо вернулось с ошибкой. Оно не попало в спам, а было отклонено. Сервер ответил 550 5.7.26 или 550 5.7.515, и сообщение не дошло. Одна из возможных причин: у домена нет корректной SPF-записи для почты или существующая запись содержит структурную ошибку. Но сами по себе эти коды не доказывают, что проблема только в SPF.

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

Google: 550 5.7.26 - Письмо без аутентификации не принимается

Microsoft: 550 5.7.515 - Подлинность отправителя не подтверждена

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

Что такое SPF-запись для почты?

SPF-запись представляет собой TXT-запись в DNS домена и описывает, какие почтовые серверы вправе отправлять почту для этого домена. При получении письма сервер Gmail, Outlook или другого сервиса обращается к DNS и сопоставляет IP отправителя с правилами. Совпадение может дать Pass; результат при отсутствии совпадения зависит от завершающего правила. Принимать ли письмо, получатель решает с учетом собственной политики и других проверок.

SPF проверяет SMTP-конверт, то есть домен в MAIL FROM, а не видимый адрес «От» в почтовом ящике получателя. TXT-запись размещают на проверяемом домене. Если это основной домен, запись находится в его корне (@); если используется отдельный домен конверта, запись нужна там. Полный порядок настройки DNS описан в статье как настроить почту на своем домене.

Правило одной записи

Спецификация SPF, RFC 7208, допускает для проверяемого домена только одну TXT-запись, начинающуюся с v=spf1. Если принимающий сервер находит две SPF-записи, проверка возвращает PermError. Это ошибка аутентификации, а не просто дополнительный штраф в спам-оценке. Отклонение сообщения при этом зависит от политики получателя.

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

Прежде чем что-либо менять, проверьте записи домена:

dig +short txt yourdomain.com

Посчитайте строки, начинающиеся с v=spf1. Если их две, проверка SPF даст PermError. Сначала устраните эту структурную ошибку.

Неправильно: две записи приводят к PermError при проверке этого домена:

v=spf1 include:_spf.google.com -all
v=spf1 include:spf.trekmail.net -all

Правильно: оба провайдера объединены в одной SPF-записи:

v=spf1 include:_spf.google.com include:spf.trekmail.net -all

SPF-запись: минимальная рабочая настройка

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

Сценарий A: управляемый SMTP TrekMail (тарифы Starter и Agency)

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

v=spf1 include:spf.trekmail.net -all

Сценарий B: бесплатный тариф TrekMail (свой SMTP)

Если по условиям Nano доступен собственный SMTP, можно подключить Amazon SES, SendGrid или Mailgun. Разрешайте серверы выбранного провайдера, а не TrekMail:

v=spf1 include:amazonses.com -all

Замените include:amazonses.com значением, указанным вашим провайдером для используемого домена конверта. Не разрешайте диапазоны IP, которые не участвуют в отправке.

Сценарий C: смешанная схема - TrekMail + Google Workspace

Переходите с Google или временно используете оба сервиса? Объедините их в одну запись:

v=spf1 include:spf.trekmail.net include:_spf.google.com -all

Составные части записи

~all (Soft Fail) сообщает, что неучтенный отправитель, вероятно, не разрешен. Это не гарантирует ни доставку, ни отказ. -all задает Fail и подходит после проверки всех законных путей отправки. ~all может быть полезен на этапе внедрения и диагностики; выбор должен соответствовать вашей подтвержденной схеме отправки.

Лимит в 10 элементов, вызывающих поиск в DNS

Спецификация SPF (RFC 7208) ограничивает число обрабатываемых механизмов и модификаторов, вызывающих поиск в DNS, до 10 за одну проверку. Это не лимит всех отдельных DNS-запросов. Учитываются include:, a, mx и redirect, в том числе внутри подключенных записей. ip4: и ip6: не учитываются. Если при обработке превышено 10, результатом будет PermError.

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

Что учитывается в лимите:

• include: (включая вложенные include)
• a, mx, redirect

Что не учитывается:

• ip4: и ip6: - прямые указания IP не требуют этой цепочки поиска
• all

До публикации проверьте запись и правила, на которые она ссылается:

dig +short txt yourdomain.com

При длинной цепочке вложенных include можно заменить include: прямыми элементами ip4:, то есть выполнить flattening. Тогда придется своевременно обновлять запись при изменении диапазонов IP провайдера. Другой вариант: разделить потоки отправки между подходящими поддоменами конверта с отдельными SPF-записями и лимитами.

Как проверить SPF-запись

Не полагайтесь только на зеленые галочки в панели DNS. Проверка синтаксиса не подтверждает доставку. Отправьте настоящее письмо по SMTP и посмотрите, как Gmail оценивает конкретный путь отправки.

1. Отправьте письмо со своего домена на Gmail-аккаунт, которым вы управляете.
2. Откройте письмо в Gmail.
3. Нажмите меню с тремя точками → Показать оригинал.
4. Найдите Authentication-Results.

Успешная проверка выглядит так:

spf=pass (google.com: domain of team@yourdomain.com designates 192.0.2.1 as permitted sender)

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

Распространенные ошибки SPF

Многие проблемы SPF связаны с пятью ошибками. Часто их удается обнаружить и исправить менее чем за 10 минут, но обновление DNS и повторные проверки могут занять больше времени.

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

Управление SPF-записями нескольких доменов

Простая настройка SPF для одного домена может занять 10 минут. Для 50 клиентских доменов это уже постоянная обязанность. Подключение нового маркетингового сервиса может незаметно нарушить аутентификацию. Иногда вы узнаете об этом лишь из обращения клиента: почему письма возвращаются с ошибкой?

Агентствам и MSP помогает стандартизация. Если эти функции доступны в выбранном тарифе, панель нескольких доменов и мастер SPF/DKIM/DMARC TrekMail позволяют придерживаться единой схемы. Платные тарифы предлагаются от $3.50/мес.; актуальная цена и наличие управляемого SMTP зависят от условий тарифа. В Nano, если это предусмотрено, вы подключаете свой SMTP. Возможность управлять репутацией IP зависит также от провайдера и выделенного либо общего пула адресов; существующие аккаунты SES или Mailgun могут быть полезны.

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

SPF-запись: проверка перед публикацией

Перед публикацией пройдите этот список по порядку:

1. Проверьте существующие записи: dig +short txt yourdomain.com - только одна строка v=spf1.
2. Определите все сервисы, отправляющие почту для домена: транзакционные, маркетинговые и инструменты поддержки.
3. Создайте одну запись, охватывающую нужные источники. Объединяйте, а не добавляйте отдельные записи.
4. После полной инвентаризации используйте -all; оценивайте ~all осознанно и избегайте +all.
5. Посчитайте элементы, вызывающие поиск в DNS, включая вложенные; для запаса оставайтесь ниже 10.
6. Опубликуйте TXT-запись на проверяемом домене конверта; для основного домена это @.
7. Отправьте тестовое письмо в Gmail и через Показать оригинал проверьте spf=pass.

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

Продуманная настройка SPF снижает объем будущей диагностики. Проверяйте запись снова при смене провайдера или его диапазонов IP. Ошибки могут нарушить работу корпоративной почты. Попробуйте TrekMail бесплатно: доступность Nano без карты, платных тарифов от $3.50/мес. и 14-дневного пробного периода определяется текущими условиями.