SPF ~all чи -all: Softfail або Hardfail — що обрали 139 мільйонів записів (2026)

Q: SPF ~all чи -all — що краще?

Ні те, ні інше універсально. ~all із примусовою політикою DMARC — це патерн, який рекомендують настанови Google — рівний захист у отримувачів, що оцінюють DMARC, без ламання пересланої пошти. -all підходить строго контрольованим відправникам. ~all сам по собі — стан усіх softfail-доменів, окрім 1 із 11 — це слабкий варіант.

Q: Що означає SPF softfail?

~all повідомляє отримувачам, що пошта з нелістингованих серверів, імовірно, нелегітимна, але її все одно слід прийняти, зазвичай із підозрою. Він стає реальним захистом лише тоді, коли політика DMARC діє на цей провал; дивіться SPF без DMARC.

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

Показники станом на 2026-06-29 · методологія v7. Агрегатні дані перепису по 261 мільйонах оцінених доменів. Усі показники є агрегатними — ми ніколи не публікуємо запис окремого бізнесу. Дивіться як ми оцінюємо.

Кожен SPF-запис завершується механізмом «all» — вироком для пошти з будь-якого джерела, якого немає у вашому списку — і інтернет переважно обрав м’який варіант: 55.8% із 139 мільйонів доменів, що публікують SPF, завершуються на ~all (softfail), проти 39.3%, які завершуються на -all (hardfail). Один символ відділяє «відхиляти підробки» від «імовірно підробка — все одно доставте». Який із них правильний саме для вас, залежить від другого налаштування, яке більшість власників ніколи не конфігурують.

Що насправді ~all та -all повідомляють отримувачу?

-all (hardfail): «Відхиляти пошту з будь-якого іншого джерела.» Тверде «ні».
~all (softfail): «Пошта з іншого джерела, ймовірно, нелегітимна — прийміть її, можливо, позначте.» Знизування плечима.
?all (neutral): «Немає думки.» Обрано 3.0% публікувачів; захист лише за назвою.
+all: «Будь-хто може надсилати від мого імені.» Опубліковано 36,014 доменами і гірше за відсутність запису — проблема «розстеленого килимка» має власний звіт.

Тож чи є ~all помилкою? Лише якщо він сам по собі — а він майже завжди сам

Softfail має обґрунтований сучасний аргумент: настанови Google для відправників, і разом з ними більшість практик доставлюваності, сходяться на ~all у парі з примусовою політикою DMARC (p=reject). Ця пара захищає так само добре, як -all, у кожного отримувача, що оцінює DMARC — а це тепер усі великі провайдери поштових скриньок — без жорсткого відбою легітимної пересланої пошти, класичної жертви -all. У такій конфігурації знизування плечима має силу: DMARC постачає вирок, який SPF відмовився винести.

Але вся суть саме в парі, і ось що додає перепис, чого не можуть настанови з налаштування: із 77,484,057 softfail-записів в інтернеті лише 7.1 мільйонів — приблизно 1 із 11 — мають за собою примусову політику DMARC. Для інших 70.4 мільйонів доменів ~all є саме тим, чим звучить. Їхній запис розпізнає підробку і пропускає її.

Хіба мандати 2024 року цього не виправили?

Ні — і ця відмінність важливіша, ніж припускає більшість матеріалів. Google та Yahoo почали вимагати автентифікацію від масових відправників у лютому 2024 року, а Microsoft приєдналася у травні 2025 року: успішний, узгоджений SPF або DKIM, плюс DMARC-запис із щонайменше p=none. Мандати не заходять так далеко, щоб вимагати примусу — домен із ~all, записом p=none та узгодженим DKIM повністю відповідає вимогам і залишається повністю вразливим до підробки. Мандати нормалізували паперову роботу, а не захист. Ця непримусова середина — відповідна вимогам, опублікована, така, що піддається підробці — це саме та прогалина, яку вимірює цей перепис, і це найбільша популяція в безпеці електронної пошти.

То чим має завершуватися ваш запис?

Ви надсилаєте пошту, і пересилання має значення (розсилки, списки розсилки, псевдоніми): ~all із DMARC p=reject за ним — рекомендована пара вище.
Ви надсилаєте пошту зі строго контрольованої конфігурації: -all працює і декларує політику в самому записі. Спершу картографуйте своїх відправників — суворе завершення на некартографованому записі ламає реальну пошту, або гірше.
Домен ніколи не надсилає: -all плюс p=reject, вже сьогодні. Немає нічого легітимного, що потрібно захищати, тож немає чого ламати.

Яке б завершення ви не обрали, однорядковий урок перепису тримається: кваліфікатор має значення лише настільки, наскільки те, що його забезпечує. Де ви стоїте на цій драбині — вимірюване.

Поширені запитання

SPF ~all чи -all — що краще? Ні те, ні інше універсально. ~all із примусовою політикою DMARC — це патерн, який рекомендують настанови Google — рівний захист у отримувачів, що оцінюють DMARC, без ламання пересланої пошти. -all підходить строго контрольованим відправникам. ~all сам по собі — стан усіх softfail-доменів, окрім 1 із 11 — це слабкий варіант.

Що означає SPF softfail? ~all повідомляє отримувачам, що пошта з нелістингованих серверів, імовірно, нелегітимна, але її все одно слід прийняти, зазвичай із підозрою. Він стає реальним захистом лише тоді, коли політика DMARC діє на цей провал; дивіться SPF без DMARC.

Чи зламає hardfail -all мою переслану електронну пошту? Може: пересилання повторно надсилає вашу пошту з сервера пересильника, якого ваш SPF не містить у списку, і hardfail запрошує відхилення ще до того, як DKIM чи DMARC долучаться до оцінки. Саме через цей ризик існує пара ~all + p=reject.

Чи вимагають Google та Microsoft -all тепер? Ні. Мандати для масових відправників вимагають узгодженої, успішної автентифікації та DMARC-запису із щонайменше p=none — без примусу, без конкретного кваліфікатора. Відхилення Google невідповідної масової пошти вже діє; Microsoft відправляла провали в спам і рухалася до відвертого відхилення. Відповідність вимогам — це не захист.

Перевірте, чим завершується ваш запис — і що стоїть за ним

Два запити скажуть вам обидва, безкоштовно, за 30 секунд. Якщо ви один із 70.4 мільйонів непримусових знизувань плечима, виправлення — це DNS-запис, а не покупка.

Перевірте свій домен → · Виправити SPF → · Виправити DMARC → · Модель зрілості SPF → · Карта +all → · Лише агрегатні дані. Дані зберігаються та обробляються в ЄС.