Defaults.Exposed › Поправки › SPF (Sender Policy Framework)

Как да поправите SPF (Sender Policy Framework)

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

Заключение за вашия бизнес: Всеки може да изпраща имейл, преструвайки се на вашия бизнес — на клиентите, персонала и доставчиците ви — фактури, заявки за промяна на плащане, всичко. В същото време реалните ви оферти и фактури са по-вероятно да попаднат в нежеланата поща, така че сделките тихо губят напредък.

Какво може да ви струва това

Измамник изпраща на ваш клиент фактура 'от вас' с техни банкови данни и получава плащането. Разбирате седмици по-късно, когато клиентът пита где са стоките — и сега е ваша репутацията и вероятно вашата отговорност.
Офертите, фактурите и отговорите ви тихо попадат в папките за нежелана поща на клиентите, защото големите доставчици не могат да верифицират, че наистина са от вас. Сделките изстиват и никога не разбирате защо.
Измамник имперсонира собственика или финансовото лице и изпраща имейл до персонала, молейки за спешно плащане или ваучери — съобщението наистина изглежда като от домейна ви, така че някой плаща.
IT или проверката за сигурност на по-голям потенциален клиент проверява домейна ви, вижда липса на защита на подателя и или ви отписва, или ви кара да го поправите преди да подпише — струвайки ви сделката или седмици закъснение.
Мислите, че сте защитени, защото SPF запис съществува — но е зададен на 'soft fail' без нищо да го налага, или тихо е счупен, така че фалшивата поща все пак минава.

Защо има значение. Фалшифицирането на адреса 'от' на имейл е тривиално лесно и не струва нищо на нападателя. SPF е най-евтиният, най-бързият начин да направите домейна ви по-труден за имперсонация и да пазите легитимния ви имейл извън нежелания. Google и Yahoo сега активно изхвърлят или отхвърлят поща от домейни, неавтентикирани, така че това вече не е незадължително — то е задължителна база за доставката на имейла ви изобщо.

Как да го поправите, стъпка по стъпка

Изброете всяка услуга, изпращаща от ваше наименование. Запишете всяка услуга, изпращаща имейл, използвайки вашия домейн — доставчика на пощенска кутия плюс всякакви инструменти за фактуриране, CRM, бюлетини или помощно бюро.
Изградете един SPF запис. Създайте единствен TXT запис при корена на домейна ви, започващ с v=spf1, с include: за всеки подател, завършващ с ~all. Никога не публикувайте два SPF записа.
Останете под 10 DNS търсения. SPF позволява най-много 10 DNS търсения; отвъд това записът се проваля. Премахнете неизползвани includes или ги изравнете, за да останете под лимита.
Наложете с DMARC, а не с -all. Публикувайте ~all и го наложете с DMARC политика reject, вместо да разчитате само на -all — същата защита без счупване на препратена поща.
Верифицирайте, че е проработило. Проверете отново домейна си, за да потвърдите, че SPF преминава и не е soft-failing или тихо счупен.

Накратко

В момента, освен ако нямате SPF правилно настроен, всеки по света може да изпраща имейл, изглеждащ като от вашия бизнес. Могат да изпращат на клиентите ви фалшиви фактури, на персонала ви фалшиви заявки за плащане, на доставчиците ви като ваши — а съобщенията ще изглеждат истински, защото домейнът ви не казва друго.

SPF (Sender Policy Framework) е поправката. Той е единствен ред текст в настройките на домейна ви, указващ кои пощенски услуги действително имат право да изпращат имейл от ваше наименование. Получаващите доставчици — 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 (hard fail) — отхвърли всичко, което не е в списъка. Най-силен. Пълни точки.
- ~all (soft fail) + DMARC зададен на reject — модерната препоръчана настройка. Еквивалентна защита на hard fail без риска от отскачане на легитимна препратена поща. Пълни точки.
- ~all + DMARC зададен на quarantine — приемливо, малко по-слабо; преминете към reject за пълна защита.
- ~all само по себе си (без DMARC enforcement) — слабо. Казва „вероятно фалшиво, доставете така или иначе.” Фалшивата поща все пак минава. Това е клопката, в която много бизнеси попадат, мислейки, че са защитени.
- ?all (неутрален) — не осигурява защита.
- +all — активно опасен: казва на света, че всеки може да изпраща от ваше наименование. Никога не използвайте.

Има още един невидим провал: SPF е разрешено да задейства най-много 10 DNS търсения при оценяване. Наредете твърде много include: записи и записът надхвърля онзи лимит, при което получателите третират цялото нещо като счупено — и обратно сте без защита. Това е общ, тих проблем за бизнеси, използващи много маркетингови и SaaS инструменти.

Как изглежда „добро”: точно един SPF запис, изброяващ всяка услуга, легитимно изпращаща поща от ваше наименование, завършващ с -all (или ~all сдвоен с DMARC при p=reject) и оставащ удобно под лимита от 10 търсения.

Как да го поправите (безплатно, ~10 минути)

Дайте тази секция на когото управлява домейна или уебсайта ви — и отбележете, че поправката е безплатна. Това е промяна на DNS настройка, а не продукт, който купувате. Ние таксуваме само за мониторинг, че остава правилно с времето, а не за самата промяна.

Стъпка 1 — Изброете всяка услуга, изпращаща имейл от ваше наименование. Това е частта, в която хората грешат. Запишете всичките: доставчика на пощенска кутия (Google Workspace, Microsoft 365 и т.н.), плюс всякакъв инструмент за бюлетини, CRM, помощно бюро, е-търговия платформа, приложение за фактуриране/счетоводство и система за резервации. Ако дадена услуга изпраща поща с вашето наименование и я забравите, 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 → Type TXT, Name @, Content = горестоящата стойност.
Microsoft 365 / Google admin: те публикуват точния include низ за използване в инструкциите за настройка; копирайте го в TXT записа на DNS хоста ви.
GoDaddy / Blacknight / повечето хостове: DNS управление → Add → TXT, Host/Name @, Value = записа.

Стъпка 3 — Започнете безопасно, след това наложете. Докато потвърждавате, че списъкът на подателите ви е пълен, публикувайте с ~all (soft fail), за да не се блокира случайно нещо легитимно. След като потвърдите, че цялата истинска поща все още тече, затегнете до -all (hard fail) — или, по-добре, запазете ~all и добавете DMARC политика p=reject, което е препоръчаното съвременно сдвояване.

Стъпка 4 — Уверете се, че имате точно ЕДИН запис. Ако вече съществува стар SPF запис, редактирайте онзи, вместо да добавяте втори. Два v=spf1 записа се отменят взаимно и ви оставят незащитени.

Стъпка 5 — Следете броя на търсенията. Ако имате много податели, може да надхвърлите лимита от 10 търсения. Ако се случи, консолидирайте — някои доставчици предлагат „SPF flattening” или отпаднете подателите, които вече не използвате.

Стъпка 6 — Проверете домейна отново, за да потвърдите, че вече преминава, с намерения запис и строгата политика.

Чести грешки

Два SPF записа. Най-честият тих провал. Добавянето на нов запис вместо редактирането на съществуващия обезсилва и двата. Трябва да има точно един.
Спиране при ~all и предположение, че сте готови. Soft fail без DMARC зад него е слабото средно поле — изглежда конфигурирано, но едва ви защитава. Или преминете към -all, или сдвойте ~all с DMARC p=reject.
Забравяне на подател. Затягането до -all преди изброяването на приложението за фактуриране, CRM или инструмента за бюлетини ще започне да блокира собствената ви легитимна поща. Изброете всичко първо.
Надхвърляне на лимита от 10 търсения. Всеки include: може да верижи повече търсения. Твърде много и записът се третира като счупен. Пазете го стегнато.
Използване на +all. Това изрично упълномощава целия интернет да изпраща от ваше наименование. По-лошо е от никакъв запис. Никога не го публикувайте.

Где се вписва

SPF е основата, но е един от три слоя. DKIM добавя криптографски подпис, доказващ, че дадено съобщение не е манипулирано, а DMARC е инструкцията, свързваща SPF и DKIM и казваща на получателите какво действително да правят с поща, която се проваля — включително блокиране на имперсонацията на видимото „от” наименование, виждано от клиентите ви. Вземете SPF правилно първо (най-бързата победа и носи най-голямо тегло), след това добавете DKIM и DMARC, за да затворите напълно вратата. Всичките три поправки са безплатни.

Настройте го при вашия хост

Стъпка по стъпка за популярни доставчици:

Чести ситуации

ЧЗВ

Не съм технически — мога ли да се справя с това сам?

Нямате нужда да разбирате детайлите. Промяната е един или два реда, добавени в настройките на домейна ви, направени от когото управлява уебсайта или IT доставчика ви. Дайте им раздела 'Как да го поправите' по-долу — обикновено отнема няколко минути и е безплатно. Ние таксуваме само за мониторинг, че остава правилно с времето.

Вече имаме SPF запис — не означава ли, че сме покрити?

Не непременно. Наличието на запис е първата половина; строгостта на записа е втората. Запис, завършващ с '~all' (soft fail) без DMARC зад него, казва на получаващите сървъри 'може да е фалшиво, но го доставете така или иначе' — което осигурява минимална защита. Два SPF записа, или такъв с твърде много търсения, се третира като счупен и ви дава никаква защита въпреки привидното наличие. И двете половини трябва да са верни.

Поправянето ще счупи ли случайно собствения ми имейл?

Може, ако в записа липсва легитимен подател — например приложението ви за фактуриране или инструментът за бюлетини, изпращащи поща от ваше наименование. Именно затова безопасният подход е първо да изброите всяка услуга, изпращаща поща от ваше наименование, да публикувате с мек '~all', докато потвърдите, че нищо не е пропуснато, след това да затегнете до hard fail. Направено в онзи ред не счупва нищо.

Каква е разликата между '~all' и '-all' и кое трябва да използваме?

'-all' (hard fail) казва на получателите да отхвърлят всичко, което не е в списъка ви — най-силната настройка. '~all' (soft fail) казва 'вероятно не легитимно, но го приемете така или иначе.' Съвременната препоръка е '~all' комбинирана с DMARC политика 'reject' — двойката ви дава същата защита като '-all' без риска от отскачане на препратена поща. '~all' само по себе си, без DMARC да я налага, е слабата конфигурация за избягване.

SPF ще спре ли всякакъв имейл спуфинг сам по себе си?

Не — той е основният първи слой, не целият отговор. SPF указва кои сървъри могат да изпращат за вас, но не казва на получателите какво да правят когато съобщение се провали и не покрива видимото 'от' наименование, което потребителят вижда. За пълното заключване на имперсонацията искате и DKIM и DMARC. SPF е най-бързата, с най-висок ефект първа стъпка, така че започнете тук, след това добавете другите два.

Кога влиза в сила и може ли да струва нещо?

DNS промените обикновено влизат в сила в рамките на минути до няколко часа. Самата поправка е винаги безплатна — просто редактиране на настройка при DNS доставчика ви. Всеки, казващ ви, че изисква платен продукт за добавяне на SPF запис, греши.