Defaults.Exposed › Виправлення › SPF (Sender Policy Framework)

Як виправити SPF (Sender Policy Framework)

SPF — це рядок у налаштуваннях вашого домену, що вказує, яким поштовим службам дозволено надсилати листи від імені вашого бізнесу. Без нього будь-хто у світі може надіслати лист, що виглядатиме так, ніби він прийшов від вас, — а ваша власна пошта частіше потраплятиме до спаму клієнтів.

Висновок для вашого бізнесу: Будь-хто може надсилати листи, видаючи себе за ваш бізнес — вашим клієнтам, співробітникам і постачальникам: рахунки, прохання змінити реквізити та інше. При цьому ваші справжні комерційні пропозиції та рахунки частіше потраплятимуть до спаму, і угоди тихо зриватимуться.

Що це може вам коштувати

Шахрай надсилає вашому клієнту рахунок «від вас» зі своїми банківськими реквізитами — і отримує гроші. Ви дізнаєтесь про це через тижні, коли клієнт запитає, де його товар. Тепер під удар потрапила ваша репутація, і, можливо, ваша відповідальність.
Ваші комерційні пропозиції, рахунки та відповіді непомітно осідають у папці спаму клієнтів, бо великі поштові провайдери не можуть підтвердити їхню автентичність. Угоди зависають, і ви так і не розумієте чому.
Шахрай видає себе за вас або вашого фінансиста та надсилає співробітникам лист із проханням терміново провести платіж або переказати кошти. Лист справді виглядає так, ніби надійшов з вашого домену, — і хтось платить.
Служба безпеки або IT-відділ потенційного великого клієнта перевіряє ваш домен і виявляє відсутність захисту відправника. Вас або відхиляють, або вимагають виправити це до підписання контракту — і ви або втрачаєте угоду, або місяцями тягнете затримки.
Ви вважаєте, що захищені, бо SPF-запис існує, — але він налаштований на 'м'який збій' без жодних примусових механізмів або й зовсім незворотно зламаний. Листи зловмисників продовжують проходити.

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

Коротко

Прямо зараз, якщо у вас неправильно налаштований SPF, будь-хто у світі може надіслати лист, що виглядатиме як такий, що надійшов від вашого бізнесу. Шахраї можуть надсилати вашим клієнтам фальшиві рахунки, вашим співробітникам — підроблені запити на оплату, а вашим постачальникам — листи від вашого імені. І ці листи виглядатимуть справжніми, бо ніщо у вашому домені не говорить про інше.

SPF (Sender Policy Framework) — це рішення. Це один рядок тексту в DNS-налаштуваннях вашого домену, що перераховує поштові служби, яким дозволено надсилати листи від вашого імені. Приймальні поштові провайдери — Gmail, Outlook та інші — перевіряють цей список перш ніж вирішити, чи є лист справжнім. Немає списку або він слабкий — і їм нема на що спиратися.

Ця сторінка охоплює два аспекти, які мають бути правильними: чи існує SPF-запис взагалі і чи він достатньо суворий, щоб насправді виконувати своє завдання.

Що це може коштувати вам

Ось реальні способи, якими відсутній або слабкий SPF-запис перетворюється на втрату грошей і довіри. Ми ніколи не вказуємо конкретний бізнес — це закономірності, які ми спостерігаємо у даних.

Перенаправлення рахунку. Шахрай надсилає вашому клієнту лист, що виглядає точнісінько так, ніби він прийшов від вас, з реалістичним рахунком зі своїми банківськими реквізитами. Клієнт платить. Ви дізнаєтесь про це, коли він питає, де замовлення. Тепер маємо розлюченого клієнта, гроші, що пішли шахраю, і неприємну розмову про те, хто відшкодовуватиме збитки.
Шахрайство з керівником/фінансистом. Хтось пише вашому бухгалтеру «від» власника: «Будь ласка, проведи цей платіж до кінця дня». Оскільки лист справді виглядає так, ніби надійшов з вашого домену, він не викликає підозр. Гроші залишають компанію.
Прихований збиток доставлення. Ваші пропозиції та рахунки починають осідати в папці спаму клієнтів, бо Gmail і Yahoo не можуть підтвердити, що вони справді від вас. Ви не отримаєте повідомлення про помилку — угоди просто зависають. Ви втрачаєте бізнес і навіть не можете це помітити.
Втрачений контракт. Служба закупівель або безпеки великого клієнта проводить базову перевірку вашого домену в рамках адаптації. Вони бачать відсутність автентифікації відправника і позначають вас як ризик. У кращому випадку ви поспіхом виправляєте це під тиском дедлайну; у гіршому — вони йдуть до конкурента, який пройшов перевірку.
Хвиля отруєння бренду. Ваш домен використовується у фішинговій кампанії проти широкої аудиторії. Люди, яких обманули, тепер не довіряють жодному листу з вашим ім’ям — тому навіть ваші справжні пропозиції та нагадування ігноруються або позначаються як спам.

Спільна нитка: зловмисник нічого не витрачає, а ваш бізнес несе витрати і провину.

Що це насправді є

Коли надходить лист, приймальний поштовий сервер хоче знати одне: чи справді це від того, від кого стверджується? SPF відповідає на частину цього запитання.

Ви публікуєте короткий рядок тексту в DNS-налаштуваннях вашого домену — запис «TXT» — що перераховує поштові служби, яким дозволено надсилати від вашого імені. Наприклад:

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

Простими словами: «Справжні листи від нас надходять із серверів Google і SendGrid — відхиляйте все інше, що видає себе за нас».

Два аспекти, що впливають на вашу оцінку:

Чи існує запис? Це ключове (він має найбільшу вагу серед будь-якої окремої перевірки пошти). Без запису одержувачі не мають списку для перевірки, тому видавання себе за інших нічим не обмежене. Є також прихована помилка: якщо у вашого домену є два або більше SPF-записів, правила кажуть, що усі вони недійсні — тож у вас фактично немає SPF, попри видимість наявності.
Чи достатньо суворою є політика? Запис може існувати, але бути беззубим. Завершення — механізм «all» — є інструкцією для одержувачів:
- -all (жорсткий збій) — відхиляти все, що не в списку. Найсильніше. Повний бал.
- ~all (м’який збій) + DMARC зі значенням reject — сучасне рекомендоване налаштування. Еквівалентний захист до жорсткого збою без ризику відмови переспрямованих листів. Повний бал.
- ~all + DMARC зі значенням quarantine — прийнятно, трохи слабкіше; перейдіть до reject для повного захисту.
- ~all самостійно (без DMARC) — слабко. Це говорить «мабуть, підробка, але доставте». Підроблені листи продовжують проходити. Це пастка, в яку потрапляє багато підприємств, думаючи, що вони захищені.
- ?all (нейтральний) — жодного захисту.
- +all — активно небезпечний: він каже світу, що будь-хто може надсилати від вашого імені. Ніколи не використовуйте його.

Є ще одна прихована помилка: SPF дозволяє не більше 10 DNS-звернень під час оцінки. Занадто багато записів include: — і запис перевищить цей ліміт, після чого одержувачі вважатимуть його зламаним. Це поширена, непомітна проблема для бізнесів, що використовують багато маркетингових і SaaS-інструментів.

Як виглядає «добре»: рівно один SPF-запис, що перераховує кожну службу, яка законно надсилає пошту від вас, закінчується на -all (або ~all у парі з DMARC на p=reject) і залишається значно нижче ліміту в 10 звернень.

Як це виправити (безкоштовно, ~10 хвилин)

Передайте цей розділ тому, хто керує вашим доменом або сайтом, і зверніть увагу, що виправлення безкоштовне. Це зміна в DNS-налаштуванні, а не продукт, який потрібно купувати. Ми беремо плату лише за моніторинг коректності налаштувань з часом, а не за саму зміну.

Крок 1 — Перерахуйте кожну службу, що надсилає пошту від вашого імені. Саме тут люди помиляються. Запишіть усі: ваш поштовий провайдер (Google Workspace, Microsoft 365 тощо), а також будь-який інструмент розсилки, CRM, helpdesk, платформу електронної комерції, застосунок для виставлення рахунків та систему бронювання. Якщо ви забудете якусь службу, ваш SPF заблокує її листи після посилення політики.

Крок 2 — Опублікуйте один TXT-запис для вашого кореневого домену. Об’єднайте рядки «include» для всіх ваших відправників в один запис. За поширеними платформами:

Google Workspace: include:_spf.google.com
Microsoft 365: include:spf.protection.outlook.com
SendGrid: include:sendgrid.net
Mailchimp: include:servers.mcsv.net
Zoho: include:zoho.eu (або відповідний для вашого регіону домен)

Об’єднаний запис виглядає так:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net -all

Де додати, залежно від провайдера:

Cloudflare: DNS → Records → Add record → Тип TXT, Ім’я @, Content = вказане вище значення.
Microsoft 365 / Google admin: вони публікують точний рядок include у своєму майстрі налаштувань; скопіюйте його у TXT-запис вашого DNS-хоста.
GoDaddy / більшість хостів: DNS management → Add → TXT, Host/Name @, Value = запис.

Крок 3 — Починайте безпечно, потім вводьте примус. Поки ви підтверджуєте повноту вашого списку відправників, публікуйте з ~all (м’який збій), щоб нічого легітимного не заблокувалося випадково. Після підтвердження що вся ваша справжня пошта доходить, посильте до -all (жорсткий збій) — або краще залиште ~all і додайте DMARC-політику p=reject, що є рекомендованим сучасним поєднанням.

Крок 4 — Переконайтеся, що у вас рівно ОДИН запис. Якщо старий SPF-запис вже існує, відредагуйте його, а не додавайте другий. Два записи v=spf1 скасовують один одного і залишають вас незахищеними.

Крок 5 — Стежте за кількістю звернень. Якщо у вас багато відправників, можна перевищити ліміт у 10 звернень. У такому разі консолідуйте — деякі провайдери пропонують «вирівнювання SPF», або відмовтеся від відправників, яких більше не використовуєте.

Крок 6 — Повторно перевірте ваш домен, щоб переконатися, що він тепер проходить перевірку з наявним записом і суворою політикою.

Поширені помилки

Два SPF-записи. Найпоширеніша прихована помилка. Додавання нового запису замість редагування існуючого анулює обидва. Має бути рівно один.
Зупинитися на ~all і вважати, що все готово. М’який збій без DMARC — це слабка середина: виглядає налаштованим, але майже не захищає. Або переходьте до -all, або поєднуйте ~all з DMARC p=reject.
Забути відправника. Посилення до -all без внесення вашого застосунку для виставлення рахунків, CRM або інструменту розсилки почне блокувати вашу власну легітимну пошту. Спочатку перерахуйте все.
Перевищення ліміту в 10 звернень. Кожен include: може ланцюжком приводити до додаткових звернень. Занадто багато — і запис вважається зламаним. Тримайте його компактним.
Використання +all. Це явно дозволяє всьому інтернету надсилати від вашого імені. Це гірше, ніж відсутність запису. Ніколи не публікуйте його.

Де це вписується

SPF — основа, але це лише один із трьох рівнів. DKIM додає криптографічний підпис, що підтверджує незмінність листа в дорозі, а DMARC — це інструкція, що пов’язує SPF і DKIM і каже одержувачам, що насправді робити з листами, які не пройшли перевірку, включно з блокуванням видавання себе за ваш видимий адрес, який бачать клієнти. Спочатку правильно налаштуйте SPF (це найшвидший крок із найбільшою вагою), потім додайте DKIM і DMARC для повного закриття дверей. Усі три виправлення безкоштовні.

Налаштуйте на своєму хості

Покроково для популярних провайдерів:

FAQ

Я не технічний фахівець — чи можу я впоратися з цим самостійно?

Вам не потрібно розбиратися в деталях. Зміна — це один-два рядки в налаштуваннях вашого домену, і її може зробити той, хто керує вашим сайтом або IT-інфраструктурою. Передайте йому розділ «Як це виправити» нижче — зазвичай це займає кілька хвилин і нічого не коштує. Ми беремо плату лише за моніторинг коректності налаштувань з часом, а не за саму зміну.

У нас вже є SPF-запис — хіба ми не захищені?

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

Чи не зламає виправлення мою власну пошту?

Може, якщо в записі пропущений легітимний відправник — наприклад, ваш застосунок для виставлення рахунків або інструмент розсилки. Саме тому безпечний підхід — спочатку перерахувати всі сервіси, що надсилають пошту від вашого імені, опублікувати запис із м'яким '~all', поки ви переконаєтесь, що нічого не пропущено, а потім жорсткіше налаштувати. У такому порядку нічого не зламається.

У чому різниця між '~all' і '-all' і що нам використовувати?

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

Чи зупинить SPF усю підробку пошти самостійно?

Ні — це важливий перший рівень, але не повний захист. SPF вказує, яким серверам дозволено надсилати листи від вас, але не каже одержувачам, що робити з листами, що не пройшли перевірку, і не захищає видиме поле 'from', яке бачить користувач. Для повного закриття видавання себе за інших потрібні також DKIM і DMARC. SPF — найшвидший крок із найбільшим ефектом, тому починайте з нього, а потім додавайте решту.

Коли це набере чинності й чи може коштувати щось?

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