Defaults.Exposed › Доклади

Защо SPF се проваля? Проблемът с 10-те търсения при SaaS за изпращачи в UK и ЕС (2026)

Публикувано 2026-07-09

Данни към 2026-06-29 · методология v7. Обобщени данни от преброяването в 261 милиона оценени домейна. Вижте как оценяваме.

Когато SPF се проваля при бизнес, използващ SaaS инструменти в UK или ЕС, най-вероятната причина е едно RFC правило, за което никога не е трябвало да мислите: след 10 DNS търсения, SPF не връща „провал” — той връща PermError, което означава, че записът се третира като несъществуващ. Поне 797,263 домейна вече са прекрачили тази граница. Още 2,119,539 стоят точно при 9–10 търсения — на едно ново разстояние от същата скала.

Защо SPF се чупи при добавяне на SaaS инструмент?

SPF работи, изброявайки пощенските сървъри, упълномощени да изпращат от ваше имe. Съвременните бизнеси не управляват собствени пощенски сървъри — използват Google Workspace за вътрешна поща, Mailchimp за кампании, HubSpot за продажбени последователности, Pipedrive за CRM комуникации. Всяка платформа ви дава ред include: за поставяне в DNS.

Проблемът: всеки include: е само по себе си DNS търсене. А всеки запис вътре в това включване може да задейства повече търсения рекурсивно. RFC 7208 §4.6.4 задава твърда граница от десет. След десет, получаващият пощенски сървър спира оценяването и връща PermError — а PermError не е меко неуспешно резултат, попадащ в спам. Означава, че вашият SPF запис се третира като отсъстващ. Удостоверяването на имейли се проваля при SPF частта.

Това няма да видите в панела за DNS. Броячът се задейства само при живо оценяване. Можете да имате три реда include: в видимия запис и все пак да сте дванадесет търсения навътре, защото SPF записът на всеки доставчик извлича свои под-включвания.

Колко домейна вече са над ограничението?

Поне 797,263. Това е броят след като разрешихме всяка SPF include: цел, референцирана 100 или повече пъти — 10,842 различни цели, обхващащи 95.2% от всички include референции — и остойностихме пълната верига на всеки домейн. Повърхностният брой (какъвто бихте намерили, броейки само видимите редове в записа) открива приблизително 7,958. Цифрата, остойностена чрез верига, е 100 пъти по-голяма, защото почти всички щети са невидими вътре в include целите.

Ситуацията, най-вероятно засягаща европейски бизнес:

Европейски хостинг доставчици и слаби SPF настройки по подразбиране

Хостинг доставчикът, с който сте започнали, има значение — защото някои задават SPF настройки по подразбиране, вече изразходващи няколко от десетте ви търсения, преди да свържете и един SaaS инструмент.

Сред най-големите хостинг доставчици, използвани от европейски домейни в нашето преброяване:

IONOS се откроява: 1.0% от хостваните при IONOS домейни имат прилагащ DMARC, което означава, че огромното мнозинство изобщо нямат смислено удостоверяване на изпращача. OVH домейните се справят по-добре при строгата SPF настройка (43.7%), но все пак падат до 2.2% при прилагане на DMARC — SPF сам по себе си, без DMARC да го обвърже с From: заглавката, защитава само плика, а не това, което получателят вижда.

Microsoft 365 е изключението в добрия смисъл: 85.0% от хостваните при Microsoft домейни използват строг SPF, до голяма степен защото съветникът за пощенски поток на Microsoft задава -all по подразбиране. Google Workspace задава ~all (softfail) по подразбиране, оставяйки 92% от домейните си без строга защита.

Как да диагностицирате SPF провала ви за по-малко от 60 секунди

Най-бързата проверка е безплатен инструмент, оценяващ пълната верига на търсения — не само видимия запис. Изпълнете nslookup -type=TXT yourdomain.com от командния ред и преброй всеки include:, виждан. После потърсете всеки от тези записи и пребройте техните. Ако свършат пръстите ви преди includes, вие сте в опасната зона.

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

Три диагностични резултата:

• PermError — вече сте над десет. Всеки имейл, който изпращате, не преминава SPF проверката при получателя.
• При 9–10 търсения — на ръба сте. Следващата SaaS интеграция ви прехвърля.
• Softfail (~all) вместо hardfail (-all) — под ограничението сте, но записът е настроен твърде слабо, за да осигури реална защита. Вижте доклада за неправилни конфигурации на SPF за пълната картина на -all срещу ~all.

Как да поправите SPF при използване на множество SaaS инструменти

Три подхода, по ред на трайност:

1. Одитирайте и прочистете. Започнете, изброявайки всеки include: в текущия ви запис. Премахнете всяка платформа, която вече не използвате — стари ESP-та, CRM инструменти от предишни договори, платформи, тествани, но изоставени. Това е безплатно и често освобождава няколко търсения. Всеки премахнат include: може да елиминира 1–3 под-търсения.

2. Изравнете SPF записа си. SPF изравняването разрешава всички include: цели в основните им IP диапазони и ги записва директно в записа ви като ip4: и ip6: механизми. IP механизмите не задействат търсения, така че изравненият запис може да изброява десетки изпращащи източници и все пак да стои на нула търсения. Недостатъкът: трябва да преизравните при всяко актуализиране на IP адресите за изпращане от доставчик, което се случва без предизвестие. Повечето организации използват платена услуга за SPF изравняване (PowerDMARC, EasyDMARC, Dmarcian и други предлагат такава) или изграждат работен процес за мониторинг.

3. Използвайте SPF макроси. RFC 7208 макросите позволяват изграждане на записи, извършващи едно DNS търсене на проверка и отговарящи динамично, вместо верига от включвания. Макросите изискват поддръжка от DNS хостинга и малко усилия при реализацията, но са архитектурно чисто решение за организации с много SaaS изпращачи.

След поправяне на SPF, сдвоете го с прилагане на DMARC — SPF без DMARC удостоверява само плика на изпращача, а не адреса From: в заглавката, виждан от получателите.

Често задавани въпроси

Защо SPF записът ми минава инструмента за DNS, но все пак се проваля в имейл заглавките? Повечето инструменти за DNS търсения броят само механизмите, видими в собствения ви запис, а не под-търсенията, задействани от тях. Можете да имате два реда include: и все пак да сте над ограничението, ако записът на всеки доставчик съдържа няколко повече. Само инструмент за остойностяване на верига (или получаващ пощенски сървър) брои пълната дълбочина. Проверете домейна си за истинския брой на веригата.

Означава ли провалът на SPF, че имейлите ми отиват в спам? PermError (твърде много търсения) означава, че SPF частта на удостоверяването връща несъществуващ резултат — ефективно отсъстваща. DMARC оценява и SPF, и DKIM; ако DKIM мине, DMARC все пак може да мине въпреки SPF PermError. Ако нито едното не мине, DMARC се проваля, а резултатът зависи от вашата DMARC политика. При p=none, имейлът все още се доставя, но провалът се регистрира. При p=quarantine или p=reject, имейлът се филтрира или отхвърля. Поправете SPF, за да не разчитате само на DKIM.

Колко търсения използва типичен SaaS стек? p99 SPF записът в нашето преброяване вече стои при 9 търсения — точно при границата — преди да добавите каквото и да е. Записът на Google Workspace добавя 3–4 търсения; Mailchimp добавя 1–2; HubSpot добавя 1–3 в зависимост от текущата им конфигурация. Три основни инструмента плюс стандартните настройки на вашия хостинг доставчик често са достатъчни, за да надхвърлите десет.

Безопасно ли е изравняването на SPF? Да, при условие че го поддържате актуален. Изравняването преобразува include: вериги в статични IP диапазони — ако доставчик промени IP адресите си за изпращане и не преизравните, ще започнете да отхвърляте неговата поща. Повечето организации използват управлявана услуга за изравняване, следяща за промени в IP адресите, вместо да го поддържат ръчно.

SPF ми е такъв от години — защо изведнъж се проваля? Защото доставчиците са актуализирали своите SPF записи, а не вашия. Всеки път, когато SaaS платформа добави нов диапазон от IP адреси за изпращане или вложи ново включване, цената на вашата верига нараства без никаква промяна от ваша страна. Ограничението от 10 търсения се оценява на живо при получаване на съобщение, така че промяна при доставчик в сутринта на вторник може да счупи вашия SPF в следобеда на вторник.

Подобрява ли поправката на SPF доставяемостта на имейлите? Тя премахва източник на неуспех при удостоверяването, което е предпоставка за последователна доставка — особено след като Google и Yahoo вече прилагат съгласуваността с DMARC за масовите изпращачи. SPF сам по себе си не е пълната картина: сдвоете го с DKIM и DMARC за пълно удостоверяване на имейли.

Проверете SPF безплатно

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

Проверете вашия домейн → · Поправете SPF → · Докладът за SPF PermError → · Доклад за неправилни конфигурации на SPF → · Моделът за зрялост при приемане на SPF → · Поправете DMARC → · Само обобщени данни. Данните се съхраняват и обработват в ЕС.