Как да настроите правилно SPF запис за домейна си, без да навредите на доставяемостта

SPF записът е първата линия на защита за домейна ви при студени B2B имейли, но именно тук се допускат най-много технически грешки. Разглеждаме синтаксиса механизъм по механизъм, честите провали и как SPF се съчетава с DKIM и DMARC в реална кампания. Целта е да можете сами да прочетете и коригирате собствения си запис, без да разчитате единствено на автоматичен spf dkim dmarc checker.

Защо SPF записът решава дали писмото ви стига до Inbox

SPF (Sender Policy Framework) е DNS TXT запис, който казва на получаващите пощенски сървъри кои IP адреси и услуги имат право да изпращат имейли от името на вашия домейн. При таргетиран B2B outreach - когато изпращате малки, персонализирани партиди до конкретни представители на конкретни компании - всяка грешка в записа директно се отразява на репутацията на домейна и увеличава риска писмата да паднат в папка „Спам“ или изобщо да не стигнат.

За разлика от bulk разпращанията, при cold email обемът на ден е малък, но всяко писмо минава проверка при първи контакт - получателят рядко е „белял“ подателя предварително. Затова техническата хигиена тежи повече, отколкото при вече „затоплени“ масови нюзлетъри. Тази статия е практическото продължение на всяко общо обяснение от типа email security spf dkim and dmarc explained - тук влизаме конкретно в синтаксиса и грешките, които реално чупят доставяемостта.

Синтаксис на SPF: механизми, квалификатори и ред на записване

SPF записът винаги започва с версията v=spf1, следвана от поредица механизми, разделени с интервал, и завършва с механизъм за поведението по подразбиране (all). Проверяващият сървър чете записа отляво надясно и спира на първия механизъм, който съвпада с изпращащия IP адрес - редът има значение само в рамките на съвпадението, не и на общия резултат.

Всеки механизъм може да носи квалификатор пред себе си: + (Pass, подразбиращ се, ако липсва), - (Fail, отхвърляне), ~ (SoftFail, приема се но се маркира) и ? (Neutral, все едно липсва запис). За B2B студени кампании препоръчителната практика е -all в края - твърд отказ за всичко извън изрично изброените източници.

• a - разрешава A записа на самия домейн
• mx - разрешава MX записите на домейна
• ip4 / ip6 - разрешава конкретен IP адрес или диапазон
• include - „наследява“ SPF записа на трета страна (ESP, Google Workspace, Microsoft 365)
• redirect - препраща изцяло към SPF записа на друг домейн
• exists - рядко използван, проверява DNS резолюция на конструиран адрес
• all - механизмът в края, определящ поведението по подразбиране

Лимит от 10 DNS lookups: къде реално се чупи SPF в практиката

RFC 7208 фиксира твърд лимит от 10 DNS lookups на едно SPF изчисление - всеки include, a, mx, exists и redirect се брои. Ако компанията добавя постепенно ESP за студени имейли, CRM с вграден mail relay и inbox-check инструмент за проверка на доставяемостта, лимитът се достига по-бързо, отколкото изглежда на пръв поглед.

На практика най-често се подценява колко lookups „тежи“ един-единствен include: записът на самия Google Workspace или Microsoft 365 обикновено разгръща собствени вложени include-и, които се броят отделно. Затова е добра практика периодично да проверявате действителния брой lookups през spf dkim dmarc checker, вместо да броите ръчно механизмите в текста.

Най-честите грешки, които чупят SPF записа

Повечето провали на SPF идват не от сложен синтаксис, а от натрупване на дребни пропуски при промяна на инструментите за изпращане. Домейн, който преди две години е ползвал само Google Workspace, а днес добавя ESP, CRM интеграция и инструмент за проследяване на отвори, лесно натрупва проблеми, ако никой не преглежда записа системно.

• Два отделни TXT записа с v=spf1 в един и същ домейн - невалидно за проверяващите сървъри, дори ако всеки поотделно е синтактично коректен
• +all в края - на практика разрешава изпращане от произволен сървър от името на домейна
• Забравен include след смяна на доставчик за студени имейли - старите писма минават, новите отпадат
• Използване на остарелия ptr механизъм - бавен, ненадежден и премахнат от съвременните препоръки
• Липса на redirect или актуализация след миграция на домейн между регистратори
• Надвишен лимит от 10 lookups, който води до permerror и de facto fail за цялата проверка

SPF, DKIM и DMARC заедно: как изглежда здравословна настройка

SPF сам по себе си проверява само envelope-from адреса - технически изпращащия сървър, невидим за получателя. DKIM подписва съдържанието на писмото с частен ключ и позволява да се провери, че то не е модифицирано по пътя. DMARC свързва двете: изисква „подравняване“ (alignment) между домейна в SPF/DKIM и домейна, който получателят вижда в From полето, и казва на пощенските сървъри какво да правят при несъответствие.

За домейн, изпращащ студени B2B имейли, здравословната последователност обикновено е: първо стабилен SPF с -all, после DKIM подпис за всеки изпращащ инструмент, накрая DMARC запис с p=none за наблюдение и постепенно преминаване към p=quarantine. Пример за DMARC запис в тази фаза: v=DMARC1; p=none; rua=mailto:dmarc-reports@vashiyat-domein.bg - той не блокира нищо, но показва реалните данни за подравняване, преди да въведете по-строга политика.

Чеклист: как LDM проверява SPF преди старт на B2B кампания

Преди да пуснем таргетирана студена кампания от името на клиент, SPF записът минава през кратка, но задължителна проверка - не защото синтаксисът е сложен, а защото всяка пропусната стъпка се отразява директно на репутацията на домейна и на процента писма, стигащи до Inbox.

• Извличане на текущия TXT запис през dig или онлайн spf dkim dmarc tester и проверка, че съществува само един запис с v=spf1
• Ръчно преброяване на include/a/mx/exists/redirect механизмите спрямо лимита от 10 lookups
• Проверка, че записът завършва на -all, а не на +all или ~all по подразбиране
• Сравнение на действително използваните изпращащи инструменти (ESP, CRM, помощни платформи) с включените в записа include-и
• Проверка на DKIM селектора за всеки инструмент и наличието на DMARC запис поне в режим p=none
• Тестово изпращане до собствена пощенска кутия и преглед на пълните хедъри за резултат pass по SPF, DKIM и DMARC

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