Проверка SPF записи

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

Обновлено: 24 октября 2026 г.

Источники: TXT-записи домена и каждый include через Google Public DNS (за ним Cloudflare 1.1.1.1) · RFC 7208 check_host, выполняется на нашем сервере · ничего не сохраняется

Проверяется ровно то имя, которое вы ввели: у SPF нет наследования, поэтому mail.example.com нужна своя запись.

Попробуйте

Что такое запись SPF?

Запись SPF — это TXT-запись со списком серверов, которым разрешено отправлять почту от имени домена. Она начинается с v=spf1, затем терм за термом называет отправителей и заканчивается указанием, как получателям относиться ко всем остальным (RFC 7208, апрель 2014, до сих пор действующий стандарт).

Получатели сверяют её с адресом подключившегося сервера и доменом в конверте — MAIL FROM, или Return-Path, — а не со строкой From:, которую видит читатель. Связать SPF с From: — задача DMARC.

Запись действует только для того имени, у которого она опубликована: у SPF нет наследования, поэтому mail.example.com нужна своя запись. Домен, который не отправляет почту, должен опубликовать v=spf1 -all.

Запись SPF, терм за термомgoogle.com · TXT · записано 24 октября 2026 г. · TTL 5 минут

v=spf1Версияinclude:_spf.google.comМеханизм · 1 запрос~allКвалификатор ~ · механизм all

Include указывает на _spf.google.com · 8 диапазонов, дальнейших запросов нет

ip4:74.125.0.0/16ip4:209.85.128.0/17ip6:2001:4860:4864::/56ip6:2404:6800:4864::/56ip6:2607:f8b0:4864::/56ip6:2800:3f0:4864::/56ip6:2a00:1450:4864::/56ip6:2c0f:fb50:4864::/56~all

ВерсияРовно v=spf1 и первой: запись, начинающаяся иначе, не является записью SPF.

Механизмыinclude, a, mx, ip4, ip6, exists, ptr и all проверяются слева направо: решает первое совпадение.

Квалификаторы+ pass (по умолчанию), - fail, ~ softfail, ? neutral; пишутся перед механизмом.

Модификаторыredirect= передаёт проверку другой записи; exp= поясняет fail.

Вся запись google.com — три терма: получатель загружает include, сверяет IP отправителя с его диапазонами или доходит до ~all. Записано через Google Public DNS 24 октября 2026 г..

Как выполнить проверку SPF записи

Введите домен выше, и проверка прочитает его TXT-записи, выберет ту, что начинается с v=spf1, затем пройдёт по каждому include и redirect так, как это сделал бы принимающий сервер, считая каждый DNS-запрос.

Вручную можно запросить TXT-записи: dig TXT example.com +short или nslookup -type=TXT example.com. В ответе будут все TXT-записи по этому имени; запись SPF — та, что начинается с v=spf1, а длинная приходит несколькими строками в кавычках, которые SPF соединяет без пробела. Каждый include — это ещё один запрос, и считать их придётся самим.

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

% dig TXT example.com +short

Все TXT-записи по этому имени в том виде, в каком они у вашего резолвера; запись SPF — та, что начинается с v=spf1. Для каждого include запустите снова.

Что показывает dig, а что нетgithub.com · dig TXT · записано 24 октября 2026 г.

терминал1 из 24 TXT-записей

$ dig TXT github.com @dns1.p08.nsone.net +norec +noall +answer
github.com.  3300  IN  TXT  1"v=spf1 ip4:192.30.252.0/22 include:spf.protection.outlook.com include:_netblocks.google.com include:_netblocks2.google.com include:mail.zendesk.com include:_spf.salesforce.com include:servers.mcsv.net include:mktomail.com include:sendgrid.net ip4:62.253.2"2 "27.114 ip4:166.78.69.169 ip4:166.78.69.170 ip4:166.78.71.131 ~all"

# затем каждый include, по одному запросу:
$ dig +short TXT _spf.salesforce.com4
"v=spf1 exists:%{i}._spf.mta.salesforce.com -all"

Одна запись начинается с v=spf1. Соседние записи (23 другие TXT-записи: проверочные токены и подобное) для SPF не важны, кроме размера ответа.
Строки TXT (2 строки) соединяются без пробела. Разрыв после 255 байт приходится внутрь ip4:62.253.227.114: получатели склеивают строки обратно, так что всё в порядке.
TTL 5 минут. Сколько резолверы могут хранить эту копию после изменения. Собственный сервер зоны называет 5 минут; резолвер показывает, сколько осталось от его копии.
Каждый include — отдельный запрос. Чтобы пройти запись github.com, нужно 10 запросов, считая вложенные. dig показывает одно имя за раз: счёт до 10 вам придётся вести самим.

Windows

$ nslookup -type=TXT github.com 8.8.8.8

PowerShell

# все TXT-записи по этому имени из Google Public DNS
PS> Resolve-DnsName -Name github.com -Type TXT -Server 8.8.8.8

Эта страница

/ru/spf-checker?domain=github.com

TXT-ответ github.com с его собственного DNS-сервера: запись SPF приходит двумя строками, соединяемыми без пробела, среди других TXT-записей домена.

Как читать результат: дерево include

Вердикт говорит, что получат получатели для отправителя, которого нет в записи: корректную запись с её окончанием (softfail для ~all, fail для -all), либо permerror с причиной, либо «не удалось проверить», если DNS не ответил.

Тёмно-синий столбец — бюджет запросов: по одной ячейке на каждый DNS-запрос, окрашенной в цвет include, который его тратит, общий счёт против 10 и пустые запросы в виде колец. После 10-го ячейки краснеют, а ветка, на которой получатели останавливаются, помечена.

Вид «Дерево» перечисляет выводы, сначала сбои, у каждого с разделом RFC и способом исправить, а затем каждый запрос в том порядке, в каком его делает получатель.

Проверка SPF записи github.com: 10 из 10 DNS-запросов, один пустой запрос и стоимость каждого include в бюджете запросов — Проверка SPF github.com: вердикт, запись, разбитая на термы, выводы и бюджет запросов со стоимостью каждого include. Выберите номер, чтобы узнать, что показывает каждая часть.

Лимит в 10 запросов и ошибка «слишком много DNS-запросов» (permerror)

Получатели считают каждый терм, которому нужен DNS-запрос, — include, a, mx, ptr, exists и redirect — во всех вложенных include и останавливаются на 10. 11-й даёт permerror (RFC 7208 §4.6.4). ip4, ip6, all и exp ничего не стоят.

Это permerror, а не fail: что с ним делать, решает сам получатель, но при DMARC permerror никогда не засчитывается как Pass. А поскольку проверка останавливается на первом совпадении, запись сверх лимита всё равно проходит для отправителей, указанных раньше, и ломается только для тех, что указаны позже.

Цена скрыта внутри include: include:_netblocks.mimecast.com сам тратит 9, Yandex 360 — 8, Freshdesk — 7, Mailgun — 5. Include Google и Microsoft 365 стоят по 1. Чтобы уложиться в 10, уберите отправителей, которыми больше не пользуетесь, и перенесите массовую рассылку на поддомен с собственной записью.

Кто тратит 10 запросовСтоимость измерена 24 октября 2026 г. · вымышленная запись из настоящих include

v=spf1 include:spf.protection.outlook.com include:_netblocks.mimecast.com include:mailgun.org include:sendgrid.net -all

Нужно 17 запросов

Указан в пределах первых 10 запросов: PassMicrosoft 3651Mimecast2–10

Указан после запроса 10: permerrorMailgun11–15Twilio SendGrid16–17

Все остальные тоже получают permerror, а не fail от -all в записи: получатели останавливаются, не дойдя до него.

Сколько стоит один includeInclude, который указывает каждый провайдер · измерено 24 октября 2026 г.

_netblocks.mimecast.comMimecast9 запросов
_spf.yandex.netYandex 3608 запросов
email.freshdesk.comFreshdesk7 запросов
mailgun.orgMailgun5 запросов
icloud.comiCloud+5 запросов
spf.titan.emailTitan Email4 запроса
secureserver.netGoDaddy3 запроса
_spf.google.comGoogle Workspace1 запрос
spf.protection.outlook.comMicrosoft 3651 запрос

Запросы считаются так, как в RFC 7208 §4.6.4: сам include плюс всё, что внутри него. Живые цифры на этой странице всегда берутся из реального прохода, а не из этой таблицы.

Что такое пустые запросы (void lookup)?

Пустой запрос (void lookup) — это запрос, который вернулся без записей: имени не существует (NXDOMAIN) или оно есть, но нужной записи у него нет. Получатели должны допускать два; третий — permerror (RFC 7208 §4.6.4).

Терм, указывающий на исчезнувший хост, a:old.example.com, сам по себе не ошибка: он просто не совпадает и считается одним пустым запросом. То же с exists:%{i}._spf.mta.salesforce.com для каждого отправителя, которого Salesforce не перечисляет, поэтому порядок include имеет значение.

Сбой сервера или тайм-аут — это не пустой запрос, а temperror, и получатели обычно повторяют попытку позже.

Четыре ответа, три исходаRFC 7208 §4.6.4

Собственная запись salesforce.com для 192.0.2.1, записано 24 октября 2026 г.

v=spf1 include:_spf.google.com include:_spf.salesforce.com exists:%{i}._spf.corp.salesforce.com ~all

Пустые запросы2 / 2третий: permerror

exists:%{i}._spf.mta.salesforce.com192.0.2.1._spf.mta.salesforce.com → NXDOMAIN · запрос 3 · в _spf.salesforce.com
exists:%{i}._spf.corp.salesforce.com192.0.2.1._spf.corp.salesforce.com → NXDOMAIN · запрос 4 · в salesforce.com

Результат: softfail, оба допустимых пустых запроса потрачены

Имя есть, записи нетa:mail.example.com для имени, которое всё ещё существует, но адреса у него больше нет: NOERROR без ответа. Совпадения нет, один пустой запрос, проверка продолжается.NODATAпустой запрос

Имени не существуетexists:%{i}._spf.mta.salesforce.com строит имя из каждого IP отправителя; для адреса, которого Salesforce не перечисляет, ответ — NXDOMAIN: каждый раз один пустой запрос.NXDOMAINпустой запрос

Третий пустой запросmx:shop.example.com, имя которого исчезло, когда уже потрачено пустых запросов: 2. Получатели останавливаются здесь.NXDOMAINpermerror

Ответа нет вовсеSERVFAIL или тайм-аут для include:_spf.vendor.example: DNS дал сбой, поэтому ничто не считается пустым запросом.SERVFAILtemperror, не пустой запрос

Include include:spf.bmv.jp у blastmail начинается с двух таких термов exists: для адреса, которого в нём нет, он сам тратит оба допустимых пустых запроса.

Пустым запросом считается только пустой ответ. Сбой — это temperror, и проверку повторяют позже.

Разворачивание SPF (flattening): когда помогает и когда ломает

Разворачивание заменяет include адресами, которые он перечисляет, так что запись стоит меньше запросов. Оно работает для диапазонов, которые редко меняются, и оборачивается против вас, когда поставщик добавляет сервер, которого вы не скопировали: почта с него тогда не проходит SPF.

Microsoft советует не разворачивать include:spf.protection.outlook.com, а include Google и Microsoft и так стоят по одному запросу. Если перенести массовую рассылку на поддомен вроде news.example.com, у неё появится собственная запись и свои 10 запросов.

Один include, развёрнутыйmailgun.org · записано 24 октября 2026 г.

До

include:mailgun.org

Запросы: 5
Получено записей: 5
Байт в вашей записи: 19
Mailgun меняет диапазон: подхватывается сразу

После

ip4:159.135.224.0/20 ip4:69.72.32.0/20 ip4:204.220.90.0/23 ip4:204.220.92.0/22 ещё 18

Запросы: 0
Байт в вашей записи: 450
Нужно строк TXT: 2
Mailgun меняет диапазон: ваша копия устарела

Риск устаревшей копии. Сегодня вы копируете диапазонов: 22 диапазона; когда Mailgun добавит ещё один, почта с него не будет проходить SPF, пока кто-нибудь не заметит и не обновит запись.

Разворачивайте только диапазоны, которые редко меняются, например адреса ваших собственных серверов.

Не разворачивайте Microsoft 365: Microsoft пишет, что её адреса отправки часто меняются, поэтому оставьте include.

Лучше поддомен для каждого массового отправителя: у каждого своя запись и свои 10 запросов.

Разворачивание обменивает запросы на сопровождение: копия верна, только пока поставщик не изменил свои диапазоны.

~all или -all (и DMARC)

Последний терм говорит, что будет с каждым отправителем, которого нет в списке. -all — это fail, самое строгое заявление; ~all — softfail, «скорее всего нет»; ?all — neutral, к которому получатели относятся так же, как к отсутствию SPF; +all пропускает всех и публиковать его нельзя никогда.

Между ~all и -all неправильного ответа нет. Google описывает ~all для Google Workspace, а Microsoft — -all для Microsoft 365. Когда DMARC работает в режиме применения, ~all оставляет решение за DMARC по DKIM: некоторые получатели отклоняют письмо по -all раньше, чем DMARC увидит действующую подпись DKIM, поэтому пересланные письма могут возвращаться (RFC 9989 §7.1).

Четыре окончанияRFC 7208 §2.6 · RFC 9989 §7.1

~all

softfail«Вероятно, не разрешено»: получателям не следует отклонять письмо только из-за этого.

ОписываютGoogle WorkspaceMailguniCloud+

-all

failСамое строгое заявление: получатель может отклонить сообщение прямо в SMTP.

ОписываютMicrosoft 365ZendeskGoDaddy

?all

neutralНикакого заявления: получатели относятся к нему точно так же, как к отсутствию SPF.

ОписываютFastmailInclude у IONOS и OVHcloud тоже заканчиваются на ?all: там это безвредно, ведь совпадает только pass внутри include.

+all

pass для всехЛюбой сервер в Интернете проходит как этот домен.

Никогда не публикуйте

-all и DMARC с p=reject

SPF даёт fail
отклонено в SMTP
DKIM не проверяется

Некоторые получатели сначала смотрят на SPF, поэтому пересланное письмо с действующей подписью DKIM могут отказаться принять до запуска DMARC, и потеря не видна в отчётах DMARC.

~all и DMARC с p=reject

SPF даёт softfail
DMARC проверяет DKIM
DKIM совпадает: pass

Решает DMARC. Но без подписи DKIM, по словам Microsoft, DMARC для отказов по ~all фактически игнорируется, и по этой причине она рекомендует -all.

И ~all, и -all — допустимый выбор; ?all ничего не заявляет, а +all пропускает любого.

Частые ошибки SPF и как их исправить

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

Некоторые из них печатают сами поставщики: Mimecast пишет –all с en dash, Postmark — include: spf.mtasv.net с пробелом, Twilio SendGrid указывает механизм aaaa, которого не существует. Любая синтаксическая ошибка делает permerror всю запись. А вот точка после домена в конце допустима.

Восемь записей, восемь результатовВымышленные примеры настоящих ошибок

Две записи SPFpermerror

v=spf1 include:_spf.google.com ~allv=spf1 include:sendgrid.net ~all

Исправление: объедините в одну: один v=spf1, каждый include по разу, одно окончание.

Больше 10 запросовpermerror

v=spf1 include:_netblocks.mimecast.com include:mailgun.org -all

14 запросов

Исправление: уберите отправителей, которыми больше не пользуетесь, или отдайте массовому отправителю собственный поддомен.

Третий пустой запросpermerror

v=spf1 a:old.example.com mx:gone.example.net exists:%{i}.spf.example.org -all

3 пустых запроса

Исправление: удалите термы, имена которых исчезли, и ставьте include с exists последними.

Include, за которым нет записи SPFpermerror

v=spf1 include:spf.retired-vendor.example -all

Исправление: исправьте имя или уберите поставщика, от которого вы ушли.

En dash в –allpermerror

v=spf1 include:_netblocks.mimecast.com –all

Так напечатано в собственной документации Mimecast

Исправление: обычный дефис: -all.

Пробел после include:permerror

v=spf1 a mx include: spf.mtasv.net ~all

Так напечатано в собственной документации Postmark

Исправление: include:spf.mtasv.net

Механизм aaaapermerror

v=spf1 aaaa:example.com ~all

Так напечатано в собственной документации Twilio SendGrid

Исправление: a:example.com; a уже совпадает с записями AAAA отправителей по IPv6.

Точка в концекорректно

v=spf1 include:spf.protection.outlook.com. -all

Корректно: RFC 7208 §7.3 советует её не публиковать, но получатели обязаны её принимать.

В справке Zendesk сказано также «redirect: syntax is supported»: модификатор пишется redirect= (RFC 7208 §6.1).

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

Что требуют Gmail, Yahoo и Microsoft

С февраля 2024 года Gmail и Yahoo требуют от каждого отправителя настроить SPF или DKIM. Массовым отправителям нужны оба, запись DMARC минимум с p=none и домен From:, совпадающий с одним из них. Outlook.com требует от отправителей с большим объёмом и SPF, и DKIM и с 5 мая 2025 года отклоняет письма тех, у кого их нет.

Порог Gmail — больше 5000 писем в день на личные адреса; Yahoo его не публикует. Один только SPF никогда не даёт «совпадения по домену»: домен MAIL FROM должен быть вашим, а не доменом возвратов поставщика.

Правила трёх почтовых провайдеровПрочитано на собственных страницах каждого провайдера, 24 октября 2026 г.

	Gmail	Yahoo	Outlook.com
Порог для массовых	Gmailбольше 5 000 писем в день на личные адреса Gmail, по основному домену	Yahooне опубликован: «Мы не будем указывать порог по объёму»	Outlook.comбольше 5 000 в день (блог Microsoft); 5 000 и больше с одного домена From: (статья поддержки)
Все отправители	GmailSPF или DKIM, плюс прямой и обратный DNS, TLS и доля спама ниже 0,3 %	YahooSPF или DKIM, плюс прямой и обратный DNS и доля спама ниже 0,3 %	Outlook.comжёсткого правила нет
Массовые отправители	GmailSPF и DKIM, DMARC (достаточно p=none), From: совпадает с SPF или DKIM, отписка в один клик для рекламных писем	YahooSPF и DKIM, DMARC минимум p=none и проходящий, From: совпадает с SPF или DKIM, отписка в один клик	Outlook.comSPF должен пройти и DKIM должен пройти, DMARC минимум p=none, совпадение с SPF или DKIM
Действует с	Gmail1 февраля 2024 г.; отклонение писем усилено с ноябрь 2025 г.	Yahooфевраль 2024 г.	Outlook.com5 мая 2025 г. (отклонение)
Отказ по SPF выглядит так	Gmail`4.7.275.7.27`	Yahooдля SPF не описан	Outlook.com`550 5.7.515`

Япония: самая строгая настройка NTT docomo, 「全て拒否する」, отказывает в приёме почте, IP отправителя которой не разрешён записью SPF домена, и почте от доменов, у которых записи SPF нет вовсе. docomo.ne.jp

Источникиsupport.google.com senders.yahooinc.com techcommunity.microsoft.com

Правила каждого провайдера в том виде, в каком его страницы излагают их 24 октября 2026 г..

Проверка SPF и dig с nslookup

dig и nslookup показывают TXT-записи в том виде, в каком они у вашего резолвера: запись SPF и всё остальное, что лежит по этому имени. Они не проходят по include, не считают запросы и пустые запросы и не говорят, что решил бы получатель.

Проверка SPF, как эта, проходит всю запись, поэтому цифры совпадают с тем, что считает принимающий сервер. Используйте dig для одного имени, а эту проверку — для вердикта.

Три способа взглянуть на SPFЧто показывает каждый

	Эта проверка	`dig TXT`	`nslookup -type=TXT`
Показывает TXT-записи	Эта проверкаДаразбитые на термы	dig TXTДа	nslookup -type=TXTДа
Соединяет строки длинной записи	Эта проверкаДакак получатели	dig TXTНетпоказывает каждую строку отдельно	nslookup -type=TXTНетпоказывает каждую строку отдельно
Проходит по каждому include	Эта проверкаДавсё дерево	dig TXTНетодно имя на запрос	nslookup -type=TXTНетодно имя на запрос
Считает запросы до 10	Эта проверкаДаобщий счёт по каждому include	dig TXTНетвручную	nslookup -type=TXTНетвручную
Считает пустые запросы	Эта проверкаДас именами	dig TXTНет	nslookup -type=TXTНет
Говорит, что две записи = permerror	Эта проверкаДа	dig TXTНетвыводит обе	nslookup -type=TXTНетвыводит обе
Проверяет IP отправителя	Эта проверкаДаcheck_host и сработавший терм	dig TXTНет	nslookup -type=TXTНет
Спрашивает ваш резолвер	Эта проверкаНетGoogle Public DNS, с нашего сервера	dig TXTДа	nslookup -type=TXTДа

Один и тот же вопрос тремя способами: dig и nslookup показывают то, что есть у вашего резолвера, а проверка — то, что считает получатель.

Проверка SPF: частые вопросы

Что такое проверка SPF записи?

Проверка SPF записи читает запись SPF домена, то есть TXT-запись, начинающуюся с v=spf1, и проходит её так, как это делает принимающий почтовый сервер: каждый include и redirect, каждый DNS-запрос считается против предела в 10, а каждый пустой ответ — против предела в 2. Итог — что получат получатели для отправителя вне списка или permerror с причиной.

Как проверить, разрешено ли IP-адресу отправлять почту от имени моего домена?

Выберите «Проверка IP», введите домен и адрес отправляющего сервера, IPv4 или IPv6, а при желании ещё адрес MAIL FROM и имя HELO. Проверка выполнит check_host для этого адреса и покажет pass, fail, softfail, neutral или permerror, точный терм, который сработал, его квалификатор и цепочку include, которая к нему привела.

Что значит «SPF: слишком много DNS-запросов»?

Это значит, что для проверки записи нужно больше 10 DNS-запросов — таков предел в RFC 7208. Каждый include, a, mx, ptr, exists и redirect стоит один, включая вложенные внутрь include. На 11-м получатели останавливаются с permerror, и отправители, указанные после этого места, перестают проходить SPF. Уберите ненужные include или перенесите отправителя на поддомен с собственной записью.

Что такое permerror в SPF?

Permerror — это результат SPF «эту запись нельзя вычислить». Он возникает при больше чем 10 DNS-запросах, больше чем 2 пустых запросах, двух записях SPF по одному имени, include имени без записи SPF или синтаксической ошибке. Это не fail: что с ним делать, решают получатели, но при DMARC он никогда не засчитывается как Pass.

Что такое пустой запрос (void lookup) в SPF?

Пустой запрос — это DNS-запрос для терма SPF, который вернулся пустым: имени не существует (NXDOMAIN) или у него нет записи нужного типа. RFC 7208 говорит, что получатели должны допускать два; третий — permerror. Сбой сервера или тайм-аут — это не пустой запрос, а temperror, который получатели обычно повторяют позже.

Чем должна заканчиваться запись SPF: ~all или -all?

Подходят оба. -all (fail) — самое строгое заявление, и Microsoft описывает его для Microsoft 365; ~all (softfail) описывает Google для Google Workspace. Если есть подпись DKIM и DMARC с quarantine или reject, ~all часто безопаснее, потому что некоторые получатели отклоняют письмо по -all раньше, чем DMARC успеет принять действующую подпись DKIM.

Может ли у домена быть две записи SPF?

Нет. Если по имени есть две TXT-записи, начинающиеся с v=spf1, получатели не могут выбрать одну, и проверка заканчивается permerror до первого запроса, для любого отправителя (RFC 7208 §4.5). Обычно так бывает, когда запись нового поставщика добавляют рядом со старой. Объедините их в одну запись с одним v=spf1, каждым include по разу и единственным окончанием.

Что такое разворачивание SPF (flattening) и нужно ли оно?

Разворачивание заменяет include диапазонами IP, которые они перечисляют, и записи нужно меньше DNS-запросов. Оно помогает для диапазонов, которые редко меняются, но развёрнутая копия устаревает, как только поставщик добавляет серверы, и почта с них перестаёт проходить SPF. Лучше убрать ненужные include или отдать массовому отправителю собственный поддомен; include Microsoft 365 не разворачивайте никогда.

Нужна ли поддомену своя запись SPF?

Да. У SPF нет наследования: запись действует только для точного имени, у которого опубликована, поэтому mail.example.com или news.example.com нужна своя запись, если они встречаются в MAIL FROM или HELO. Это отличается от DMARC, который возвращается к домену организации. Поддомен, не отправляющий почту, может опубликовать v=spf1 -all.

Почему SPF проходит здесь, но не проходит в Gmail?

Обычно потому, что Gmail проверил другой домен или адрес. SPF проверяется для домена MAIL FROM (Return-Path) и IP подключившегося сервера, а это может быть домен возвратов вашего поставщика, не ваш. Пересылка тоже ломает SPF, поскольку IP пересылающего сервера нет в вашей записи. Посмотрите заголовок Authentication-Results настоящего письма и проверьте здесь этот IP и домен.

Чем отличаются SPF, DKIM и DMARC?

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

Сколько времени изменение записи SPF вступает в силу?

Столько, сколько резолверы хранят старую запись: до её TTL, который задаёт домен (300 секунд у google.com и github.com, час у microsoft.com на момент проверки). Получатели спрашивают свой резолвер, поэтому изменение становится видно, когда истекает каждая кэшированная копия. Эта проверка показывает TTL так, как его отдаёт собственный DNS-сервер домена; проверьте снова по истечении этого времени.

Проверка SPF записи

Что такое запись SPF?

Как выполнить проверку SPF записи

Как читать результат: дерево include

Лимит в 10 запросов и ошибка «слишком много DNS-запросов» (permerror)

Что такое пустые запросы (void lookup)?

Разворачивание SPF (flattening): когда помогает и когда ломает

~all или -all (и DMARC)

Частые ошибки SPF и как их исправить

Что требуют Gmail, Yahoo и Microsoft

Проверка SPF и dig с nslookup

Проверка SPF: частые вопросы

Что такое проверка SPF записи?

Как проверить, разрешено ли IP-адресу отправлять почту от имени моего домена?

Что значит «SPF: слишком много DNS-запросов»?

Что такое permerror в SPF?

Что такое пустой запрос (void lookup) в SPF?

Чем должна заканчиваться запись SPF: ~all или -all?

Может ли у домена быть две записи SPF?

Что такое разворачивание SPF (flattening) и нужно ли оно?

Нужна ли поддомену своя запись SPF?

Почему SPF проходит здесь, но не проходит в Gmail?

Чем отличаются SPF, DKIM и DMARC?

Сколько времени изменение записи SPF вступает в силу?

MX Поиск

Проверка DMARC

Проверка DKIM

Анализ заголовков Email

Проверка IP в чёрных списках

Обратный DNS

Проверка DNS

Генератор SPF-записи

Что такое запись SPF?

Как выполнить проверку SPF записи

Как читать результат: дерево include

Лимит в 10 запросов и ошибка «слишком много DNS-запросов» (permerror)

Что такое пустые запросы (void lookup)?

Разворачивание SPF (flattening): когда помогает и когда ломает

~all или -all (и DMARC)

Частые ошибки SPF и как их исправить

Что требуют Gmail, Yahoo и Microsoft

Проверка SPF и dig с nslookup

Проверка SPF: частые вопросы

Что такое проверка SPF записи?

Как проверить, разрешено ли IP-адресу отправлять почту от имени моего домена?

Что значит «SPF: слишком много DNS-запросов»?

Что такое permerror в SPF?

Что такое пустой запрос (void lookup) в SPF?

Чем должна заканчиваться запись SPF: ~all или -all?

Может ли у домена быть две записи SPF?

Что такое разворачивание SPF (flattening) и нужно ли оно?

Нужна ли поддомену своя запись SPF?

Почему SPF проходит здесь, но не проходит в Gmail?

Чем отличаются SPF, DKIM и DMARC?

Сколько времени изменение записи SPF вступает в силу?

Другие инструменты для почты и DNS

MX Поиск

Проверка DMARC

Проверка DKIM

Анализ заголовков Email

Проверка IP в чёрных списках

Обратный DNS

Проверка DNS

Генератор SPF-записи