Defaults.Exposed › Поправки › Guides

SPF не успява за SaaS инструментите ви? Защо се случва и редът на поправяне — европейско издание (2026)

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

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

Когато SaaS инструмент „не успява при SPF”, записът ви обикновено не е проблемът: пощата не успява при DMARC alignment или веригата ви с includes е надхвърлила ограничението на SPF от 10-DNS-търсения. 2,119,539 от 138,927,207 домейна, публикуващи SPF, стоят на 9–10 търсения — на един SaaS include от ръба — според census на Defaults.Exposed за 261,086,232 домейна.

По-долу: как да разпознаете кой от двата проблема имате, след това редът на поправяне — сканирайте първо, намерете домейна, от който реално изпраща инструментът, превключете доставчика към DKIM с персонализиран домейн, и добавяйте SPF include само там, където действително помага — плюс специфики за HubSpot, Salesforce, Mailchimp и SendGrid.

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

Три модела покриват почти всеки случай:

Данни към 2026-06-29.

Удебеленият ред е там, където стоят повечето хора. Добавянето на редове include: за всеки инструмент не го докосва — и всеки ред ви доближава до втория ред: поне 797,263 домейна вече са надхвърлили лимита от 10 търсения и SPF им сега връща PermError, предпазващ от нищо. Пълните числа в доклада за SPF PermError.

Кой домейн всъщност проверява SPF?

Не този в заглавието ви From. Получателите оценяват SPF спрямо домейна на Return-Path (RFC5321.MailFrom, известен още като bounce или envelope-from адрес) — заглавието From, видяно от получателя ви, не играе никаква роля в самата SPF проверка.

Този единствен факт обяснява повечето „SPF неуспехи при SaaS”. Маркетинговата ви платформа изпраща с Return-Path като [email protected]; SPF се проверява спрямо vendor.com и преминава изчистено. После DMARC пита дали SPF-проверения домейн съвпада с вашия From домейн. Не съвпада, затова SPF компонентът на DMARC не успява и таблото ви казва „SPF не успява”. Редактирането на собствения ви SPF запис не може да поправи това — вашият запис никога не е бил проверяван.

Какъв е редът на поправяне?

1. Първо стартирайте безплатното сканиране. Казва ви наведнъж дали SPF ви липсва, дублиран е, надвишил е лимита на търсения или е наред, и как стои DMARC — преди да докоснете DNS.
2. Намерете Return-Path, реално използван от инструмента. Изпратете си тестово съобщение от инструмента и прочетете заглавието Return-Path (и Authentication-Results) в суровото съобщение. Това казва в кой ред на таблицата по-горе се намирате.
3. Активирайте DKIM с персонализиран домейн на доставчика. Всеки сериозен SaaS инструмент предлага „автентикация на домейна”: няколко CNAME записа, позволяващи му да подписва DKIM с вашия домейн. Този подпис съответства с вашия From домейн, така че DMARC преминава чрез DKIM — трайно и дори когато пощата е препратена. Това е поправката, която издържа.
4. Добавяйте SPF include на доставчика само ако използва вашия return-path — активирали сте неговия персонализиран домейн за отвърнати писма, или наистина изпраща с вашия домейн в плика. Include за доставчик, отвръщащ чрез собствения си домейн, не купува нищо и изразходва бюджета ви за търсения.
5. Преброите DNS търсенията преди запазване. Ограничението е 10 разрешени търсения, includes се броят рекурсивно и 2,119,539 домейна вече стоят на 9–10 — p99 на census е 9. Близо до ръба? Премахнете includes за неизползвани вече инструменти. Току-що сменили пощенски доставчик? Проверете за остатъчен втори запис — два SPF записа равняват PermError.
6. Сканирайте отново и потвърдете. SPF преминаване за правилния домейн, DKIM в съответствие, DMARC преминаващ. Пълната справка е на как да поправите SPF; наръчниците за доставчиците като SPF за GoDaddy и DMARC за IONOS покриват кликовете в DNS панела.

Какво трябва да направите за HubSpot, Salesforce, Mailchimp и SendGrid?

HubSpot. Свържете домейна за изпращане в настройките на HubSpot и публикувайте двата DKIM CNAME (hs1-… / hs2-…), издадени от него. Така DKIM се привежда в съответствие с вашия From домейн. Не ви е нужен SPF include за HubSpot, освен ако не сте конфигурирали HubSpot да използва вашия домейн за отвърнати писма.

Salesforce. Създайте DKIM ключ в Salesforce Setup и публикувайте двойката CNAME, генерирана от него. Ако Salesforce изпраща с return-path на вашата организация, добавете include:_spf.salesforce.com и конфигурирайте домейна за отвърнати писма — това е единственият голям CRM, при който SPF include е наистина необходим.

Mailchimp. Автентикирайте домейна си и публикувайте DKIM CNAME k2 / k3. Alignment за Mailchimp е само чрез DKIM — повече няма SPF include за добавяне, а добавянето на такъв от стар урок само хаби търсения.

SendGrid. Завършете автентикацията на домейна („автоматизирана сигурност”): три CNAME, обработващи и DKIM и return-path на ваш поддомейн. Не е нужен SPF include. От 740,321 домейна, чийто SPF упълномощава sendgrid.net, само 18.0% имат прилагащ DMARC (данни към 2026-06-29) — повечето изпращачи на SendGrid спират с една стъпка.

Zendesk и всичко останало: същият модел. Намерете страницата „автентикация на домейна” на инструмента, публикувайте DKIM CNAME записите му и докосвайте SPF само ако инструментът документира, че използва вашия return-path.

Различен ли е SPF за европейски бизнеси?

Не — SPF, DKIM и DMARC работят еднакво навсякъде. Разликата в Европа е контекстът: кой пита и какво вече са направили съседите ви.

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

Данни към 2026-06-29. Франция: 13.65% прилагащ DMARC; Италия: 5.24%.

Значи стандартните настройки на вашия европейски хост. 4,346,526 домейна упълномощават европейските пощенски сървъри на IONOS (_spf-eu.ionos.com) в SPF — и само 0.3% завършват с строго -all, с 1.0% DMARC прилагащи. Домейните на OVH 2,132,049 се справят по-добре по строгост (43.7%), но само 2.2% прилагат DMARC (данни към 2026-06-29). Ако никога не сте докосвали записа си, стоите на тези стандарти.

Регулаторите вече го назовават. NIS2 Член 21(2)(j) изисква от обхванатите субекти да защитят комуникациите си, а Регламентът за изпълнение на Комисията (ЕС) 2024/2690 изрично посочва мерките за имейл и DNS сигурност. Имейл автентикацията е конкретната, проверима част — и за рядкост при съответствие, безплатна за поправяне.

По отношение на пребиваването на данните: скенерът и census на Defaults.Exposed работят в AWS eu-west-1, публикуваме само обобщени данни и сканирането проверява само домейна, за който питате.

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

Проверяващият SPF казва „pass”, но таблото на инструмента казва, че SPF не успява — защо? Проверяващият е тествал записа ви; получателят е тествал домейна на Return-Path, реално използван от инструмента, след което DMARC е сравнил с вашия From домейн. Това е неуспех на alignment, а не на запис — поправя се с DKIM с персонализиран домейн на доставчика, а не с редактиране на SPF.

Трябва ли просто да добавя SPF include за всеки инструмент, използван от нас? Не. Всеки include изразходва бюджет от 10-търсения на SPF, рекурсивно: 2,119,539 от 138,927,207 домейни, публикуващи SPF, стоят на 9–10 търсения, а поне 797,263 са надхвърлили — SPF им връща PermError и не предпазва от нищо (данни към 2026-06-29).

Поправя ли include и DMARC? Само ако инструментът изпраща с вашия return-path, така че SPF преминава и е в съответствие. За повечето SaaS инструменти не е — затова съответстващият DKIM, а не SPF, е компонентът, каращ DMARC да преминава за SaaS поща.

Законово изискване ли е в ЕС? За субекти в обхвата на NIS2, Член 21(2)(j) и Регламентът за изпълнение (ЕС) 2024/2690 правят имейл сигурността задължение. Дори извън обхвата, застрахователите и въпросниците на клиенти все повече питат — и към 2026-06-29, нито един ЕС ccTLD не е довел дори третина от домейните си до прилагаща DMARC политика (29.43% в .nl при най-добро; 5.24% в .it).

Изпратете на собственика доклада

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

Проверете вашия домейн безплатно

Вижте точно кой компонент на SPF, DKIM и DMARC не успява — поверително и само за собственика.

Проверете вашия домейн → · Поправяне на SPF → · SPF PermError: „твърде много DNS търсения” → · Как оценяваме → · Само обобщени данни. Данните се съхраняват и обработват в ЕС.