Який поштовий провайдер надає своїм клієнтам найнадійніші налаштування SPF за замовчуванням? (2026)

Опубліковано 2026-07-03

Показники станом на 2026-06-29 · методологія v7. Зведений перепис по 261 мільйонах оцінених доменів. Ми підраховуємо точні цілі include:/redirect= в опублікованих записах SPF — публічний DNS, агрегований за провайдерами; ніколи запис окремого бізнесу. Див. як ми оцінюємо.

Кожен запис SPF називає сервіси, яким дозволено надсилати пошту від імені домену — тож 139 мільйонів записів SPF є водночас переписом налаштувань за замовчуванням провайдерів, і ці налаштування різняться радикально: 85.0% доменів, що включають Microsoft 365, завершують свій SPF суворим -all, проти 8.0% доменів, що включають Google Workspace. Другий висновок важливіший: за показником, який реально зупиняє підробку — примусова політика DMARC за записом — база клієнтів жодного великого поштового провайдера не перевищує 30% завершеного захисту.

Ліга: суворі завершення та завершений захист, за провайдерами

Домени, чий SPF включає кожного провайдера; частка з суворим завершенням (-all); і частка з примусовим DMARC — комбінація, що зупиняє підробки:

Провайдер (ціль include)	Доменів авторизують	% суворих `-all`	% з примусовим DMARC
Google Workspace (`_spf.google.com`)	12,145,313	8.0%	18.5%
Microsoft 365 (`spf.protection.outlook.com`)	10,205,070	85.0%	21.7%
Namecheap forwarding (`spf.efwd.registrar-servers.com`)	7,355,985	<0.1%	0.2%
GoDaddy (`secureserver.net`)	7,061,426	86.0%	29.3%
Hostinger (`_spf.mail.hostinger.com`)	4,476,640	0.2%	1.0%
IONOS EU (`_spf-eu.ionos.com`)	4,346,526	0.3%	1.0%
HostGator (`websitewelcome.com`)	3,102,616	0.6%	1.6%
OVH (`mx.ovh.com`)	2,132,049	43.7%	2.2%
Cloudflare Email Routing (`_spf.mx.cloudflare.net`)	2,007,483	2.9%	10.0%
MailChannels (`relay.mailchannels.net`)	1,870,177	28.4%	10.0%
Mailgun (`mailgun.org`)	1,306,692	7.2%	35.9%
SendGrid (`sendgrid.net`)	740,321	19.0%	18.0%
Zoho Mail (`zohomail.com`)	662,546	7.3%	9.9%
Amazon SES (`amazonses.com`)	551,446	28.3%	41.9%
Stackmail / 20i (`spf.stackmail.com`)	519,246	98.2%	3.3%

Як читати цю таблицю — чесно

Чотири речі, якими ці дані є і якими не є:

Рядки — це популяції за include, а не клієнти. Домен, що включає і Google, і Mailgun, з’являється в обох рядках.
Стовпець суворості фотографує шаблон налаштування кожного провайдера плюс склад його клієнтів. Онбординг Microsoft видає -all; документація Google рекомендує ~all; хостингові панелі автоматично створюють записи на доменах, що можуть взагалі не надсилати пошту — і це може роздути частку суворих без будь-якого людського рішення.
Низька частка суворих не є автоматично помилкою. Рядок Namecheap — це продукт пересилання пошти, а пересилання — саме той випадок, коли -all дає збій, тож м’який шаблон там є, ймовірно, правильною конфігурацією. Вразливість у цьому рядку — це інший стовпець: 0.2% примусово.
Стовпець примусу — це справжній рейтинг. Суворий-проти-м’якого — це стилістичний вибір, коли DMARC примушує; без примусу жодне завершення не зупиняє підробку у більшості одержувачів.

Три історії у стовпцях

Налаштування за замовчуванням — це доля. Клієнти переважно залишають те, що дав майстер налаштування — 92% доменів, що включають Google, зберігають несуворе завершення, переважно ~all, який рекомендує посібник Google; 98.2% доменів Stackmail зберігають -all, який пише його панель. Майже ніхто не переглядає кваліфікатор пізніше. Це основоположне спостереження всього цього перепису, записане 139 мільйонів разів.
Фінішну лінію перетинають користувачі, а не шаблони. Лідери примусу — це відправники, орієнтовані на розробників — Amazon SES (41.9%) і Mailgun (35.9%) — чиї клієнти схиляються до команд, які доводять справу до кінця. Бази великих поштових провайдерів перебувають між 18.5% і 29.3% примусово, незалежно від того, наскільки суворим був їхній шаблон SPF.
Вразлива маса — це рівень хостингу-і-пересилання. Пересилання Namecheap, Hostinger, IONOS і HostGator разом охоплюють понад 19 мільйонів доменів із 2% примусу або менше — назви малого бізнесу, що працюють на тому, що встановила панель, м’яко обгороджені й без примусу.

Що робити з власним доменом

Подивіться, яких провайдерів насправді включає ваш SPF — dig TXT yourdomain.com, або перевірте безкоштовно.
Не копіюйте бездумно суворе завершення: складіть карту своїх відправників, а тоді або посильте до -all, або залиште ~all і поставте за ним DMARC p=reject.
Хоч би що вам передав ваш провайдер — це успадкований вами шаблон, який можна змінити безкоштовним редагуванням DNS.

Часті запитання

Який поштовий провайдер має найбезпечніші налаштування SPF за замовчуванням? За суворим шаблоном: Stackmail / 20i (98.2% доменів завершують -all), GoDaddy (86.0%) і Microsoft 365 (85.0%). За завершеним захистом — примусовий DMARC за SPF — лідирують клієнти Amazon SES із 41.9%. Ці два показники винагороджують суворий шаблон і клієнтську базу, що доводить справу до кінця, відповідно.

Чи означає використання Google Workspace, що мій SPF слабкий? Не за своєю суттю. Рекомендований Google ~all — це надійна практика у поєднанні з примусовою політикою DMARC — але лише 18.5% доменів, що включають Google, мають таке поєднання станом на 2026-06-29. Слабкість не в softfail; вона в тому, щоб зупинитися на цьому.

Чи оцінюють ці цифри власну безпеку провайдерів? Ні. Вони вимірюють опубліковану позицію SPF клієнтських доменів, що включають кожного провайдера — агрегований публічний DNS, сформований шаблонами налаштувань, документацією та складом клієнтів. Жоден окремий домен не ідентифікується та не оцінюється публічно.

Чому шаблон мого провайдера вирішує мою безпеку? Тому що він копіюється один раз, у перший день, і наш перепис показує, що його майже ніколи не переглядають. Налаштування за замовчуванням зберігаються — саме тому перевірка ваших вартує 30 секунд.

Перевірте, що успадкував ваш домен

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

Перевірте свій домен → · Виправити SPF → · ~all проти -all → · SPF без DMARC → · Частка ринку поштового хостингу → · Лише агреговані дані. Дані зберігаються та обробляються в ЄС.