Защо бизнес имейлите ви попадат в спам (и как SPF, DKIM и DMARC оправят това)

Натискате изпращане на напомняне за фактура, оферта или месечния си бюлетин – и клиентът ви никога не го вижда. Без отскок, без грешка, само тишина. Отишъл е в спам.

Ако това ви звучи познато, не сте сами. Gmail, Yahoo и Outlook вече отхвърлят или пращат в спам поща от домейни, които не са настроили три DNS записа: SPF, DKIM и DMARC. От февруари 2024 г. масовите изпращачи (грубо 5 000 или повече съобщения на ден до акаунти в Gmail) трябва да удостоверяват с и трите, да предлагат отписване с едно кликване и да поддържат спам жалбите под 0.3%. Прилагането се засили през 2025 г., а през 2026 г. дори изпращачите с нисък обем от бизнеса усещат ефекта: без удостоверяване вашите оферти, фактури и потвърждения за час са много по-вероятно да бъдат маркирани.

Добрата новина: оправянето отнема около час, не струва нищо и трайно подобрява доставяемостта. Ето какво прави всеки запис, как да ги настроите и грешките, които държат малкия бизнес в папката за спам.

Какво всъщност правят SPF, DKIM и DMARC​

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

SPF: кои сървъри могат да изпращат от ваше име​

SPF (Sender Policy Framework) е TXT запис в DNS на вашия домейн, който изброява всеки сървър, получил право да изпраща поща като вас. Когато Gmail получи съобщение, твърдящо, че е от [email protected], той проверява вашия SPF запис и дали IP адресът на изпращащия сървър е в списъка.

Примерен SPF запис за бизнес, използващ Google Workspace плюс инструмент за фактуриране:

v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

• v=spf1 идентифицира записа като SPF.
• Всяко include: упълномощава сървърите на даден доставчик.
• ~all (мек отказ) казва на получателите да третират непосочените сървъри с подозрение; -all (твърд отказ) им казва да ги отхвърлят направо.

SPF сам по себе си не е достатъчен, защото валидира само изпращача на плика (скрития Return-Path), а не адреса, който клиентът вижда в полето From. Препращането също нарушава SPF. Затова ви трябва и DKIM.

DKIM: подпис против подправяне на всяко съобщение​

DKIM (DomainKeys Identified Mail) добавя криптографски подпис към заглавните части на всяко изходящо съобщение. Вашият изпращащ доставчик държи частен ключ; вие публикувате съответстващия публичен ключ като DNS TXT запис. Получаващият сървър проверява подписа, за да потвърди, че съобщението наистина идва от вашия домейн и не е променено по време на предаване.

За разлика от SPF, DKIM оцелява при препращане, което го прави по-трайният от двата сигнала. Google изисква масовите изпращачи да имат и SPF, и DKIM успешни, като поне един от тях да е съгласуван с домейна в полето From.

Настройването на DKIM обикновено означава:

1. Включване на DKIM подписване при вашия доставчик (Google Workspace, Microsoft 365, Mailchimp и подобни инструменти имат стъпка за активиране с едно кликване).
2. Копиране на TXT записа, който ви дават (селектор плюс дълъг публичен ключ), във вашия DNS.
3. Изчакване на разпространението, след това проверка в таблото на доставчика.

DMARC: вашата политика за това какво става, когато проверките пропаднат​

DMARC (Domain-based Message Authentication, Reporting, and Conformance) свързва SPF и DKIM. Това е TXT запис на _dmarc.vashiatdomain.com, който казва на получаващите сървъри какво да правят, когато съобщение, твърдящо, че е от вас, не успее да се удостовери – и къде да ви изпращат отчети за това.

Начален DMARC запис в режим на наблюдение:

v=DMARC1; p=none; rua=mailto:[email protected]; pct=100;

• p=none означава все още да не се предприема действие, просто да се изпращат отчети. Започнете тук.
• rua= е мястото, където отиват обобщените отчети. Използвайте пощенска кутия, която реално проверявате.
• След като легитимната поща преминава последователно, преминете към p=quarantine (изпращане на неуспешните в спам), след това към p=reject (блокиране). Тази прогресия е това, което спира измамниците да се представят за вашия домейн.

DMARC също изисква съгласуване: домейнът в заглавната част From трябва да съвпада с домейна, който е преминал SPF или DKIM. Това е стъпката, която много бизнеси пропускат – SPF и DKIM могат и двата да показват „успех", докато DMARC все още пропада, защото домейните не съвпадат.

Правилата на Gmail и Yahoo, които трябва да спазвате​

Дори да не изпращате никога 5 000 съобщения на ден, третирайте тези като вашата базова линия. Gmail брои цялата поща от същия основен домейн (включително поддомейни) към прага за масови изпращания, статутът на масов изпращач никога не изтича, след като е присвоен, и всеки изпращач – масов или не – се очаква да се удостоверява.

Ето практичният контролен списък за 2026 г.:

• Удостоверете се с SPF или DKIM като минимум; и с двете, ако изпращате масово. Масовите изпращачи се нуждаят от SPF и DKIM плюс публикуван DMARC запис (поне p=none) със съгласуване с домейна в From.
• Поддържайте спам жалбите под 0.3%. Google Postmaster Tools показва вашия процент; устойчиви проценти над 0.3% задействат филтриране. Стремете се да останете значително под 0.1%.
• Направете отписването лесно за маркетинговата поща. Включете видим List-Unsubscribe заглавен ред, поддържащ отписване с едно кликване, и изпълнявайте заявките в рамките на два дни.
• Използвайте валиден прав и обратен DNS и последователен домейн в From. Не изпращайте бизнес поща от адреси на безплатни пощенски кутии или постоянно променящи се имена в From.
• Не се представяйте за заглавни части на Gmail и не купувайте списъци. Нежеланата поща генерира жалбите, които най-бързо съсипват репутацията ви.

Yahoo и Outlook прилагат основно същия набор от правила, така че една правилна настройка покрива и трите.

Настройване на всичко за около час​

Не е нужно да сте технически грамотни, за да направите това – просто ви трябва достъп до вашия DNS хост (където сте купили домейна си или където сочат вашите имена на сървъри) и администраторски достъп до вашия имейл доставчик.

Стъпка 1: Опис на това кой изпраща поща от ваше име​

Избройте всяка услуга, която изпраща имейли, използвайки вашия домейн: вашият доставчик на пощенски кутии, контактната форма на уебсайта ви, системата ви за фактуриране или резервации, инструментът ви за бюлетини, вашата CRM. Всяка от тях трябва да бъде в SPF или покрита от собствен DKIM подпис. Пропуснете една и нейната поща започва да пропада.

Стъпка 2: Публикуване на SPF, без да нарушавате лимита от 10 проверки​

SPF има твърд лимит от 10 DNS проверки. Всяко include: може да задейства няколко, а трупането на доставчици (пощенска кутия + маркетинг + помощен център + фактуриране) може тихо да ви изкара над лимита – в който момент SPF връща грешка и получателите го третират като провал.

• Започнете с препоръчания запис на вашия доставчик; не смесвайте произволни откъси от блог публикации.
• Дръжте всички източници на изпращане в един SPF TXT запис на основния домейн. Няколко SPF записа обезсилват всички тях.
• Ако сте близо до лимита, поискайте изравнени includes от доставчиците или премахнете услуги, които вече не използвате.
• Валидирайте с безплатен SPF проверяващ инструмент, преди да продължите.

Често срещана SPF настройка:

Стъпка 3: Активирайте DKIM навсякъде, откъдето изпращате​

Включете DKIM подписването във всяка платформа за изпращане и публикувайте всеки селекторен запис, който ви дава. Един домейн често завършва с няколко DKIM селектора (по един за доставчик) – това е нормално. Проверете дали всеки показва като активен в конзолата на доставчика и изпратете тест до адрес в Gmail, за да потвърдите, че заглавната част Authentication-Results показва dkim=pass.

Сменяйте ключовете, когато вашият доставчик ви подкани; счупените ротации се проявяват като постепенно влошаване на доставяемостта, затова потвърдете, че новият ключ валидира, преди да премахнете стария.

Стъпка 4: Публикувайте DMARC в режим на наблюдение, след това приложете​

1. Публикувайте _dmarc с p=none и адрес за rua=.
2. Наблюдавайте обобщените отчети за две до четири седмици. Безплатните четци на DMARC отчети превръщат XML-а в четими таблици, показващи кои сървъри преминават и кои пропадат.
3. Поправете всеки легитимен източник, който пропада (обикновено липсващ DKIM подпис или несъответствие в съгласуването).
4. Преминете към p=quarantine, изчакайте още един цикъл, след това преминете към p=reject.

Прескачането направо на p=reject от първия ден е най-честата самонанесена повреда в целия този процес – легитимни фактури и разписки се блокират, защото един пренебрегнат изпращач никога не е бил удостоверен.

7 грешки, които държат малкия бизнес в спам​

1. Изобщо няма SPF, DKIM или DMARC. Все още най-честата констатация при домейните на малкия бизнес. Проверете вашия с всеки безплатен тестер за удостоверяване, преди да предположите, че доставчикът ви „се е погрижил".
2. Два SPF записа. DNS позволява само един. Обединете всичко в един TXT запис, започващ с v=spf1.
3. SPF над лимита от проверки. Твърде много includes означава, че SPF връща грешки. Одитирайте ежегодно и премахвайте мъртви доставчици.
4. DKIM активиран в приложението, но никога публикуван в DNS. Ключето за подписване без TXT записа не прави нищо.
5. DMARC пропада при съгласуването. SPF или DKIM преминава, но под различен домейн от вашия адрес в From – често срещано, когато бюлетините се изпращат от домейна на доставчика вместо от вашия. Конфигурирайте персонализиран изпращащ домейн, за да мине съгласуването.
6. Никой не чете DMARC отчетите. Пощенската кутия за rua= се пълни, предупрежденията за нов инструмент, който пропада, остават незабелязани и проблемът изплува едва когато клиентите се оплачат.
7. Хигиената на списъка и съдържанието унищожават доброто удостоверяване. Купени списъци, без връзка за отписване, подвеждащи теми и имейли само със снимки генерират жалбите, които съсипват репутацията дори с перфектен DNS.

Как да разберете, че работи​

• Изпратете тестова поща до адреси в Gmail, Yahoo и Outlook (включително нов акаунт, който никога не е имал взаимодействие с вас) и потвърдете поставяне в „Входящи", а не в спам.
• Инспектирайте заглавните части. В Gmail отворете съобщението, изберете „Покажи оригинала" и потвърдете spf=pass, dkim=pass и dmarc=pass с вашия домейн съгласуван.
• Запишете се в Google Postmaster Tools. Добавете домейна си, потвърдете собствеността и наблюдавайте процента на спам, процентите на успешно удостоверяване и репутацията през следващите седмици.
• Проследявайте реални показатели. Сравнете процентите на отваряне, отговори и – най-важното – оплакванията от клиенти „никога не съм получил фактурата" преди и след промяната.

Какво общо има това с книгите ви​

Доставяемостта на имейли е проблем с паричния поток, маскиран като ИТ задача. Когато фактурите попаднат в спам, клиентите плащат със закъснение без тяхна вина, вашите дни на неплатени вземания пълзят нагоре и губите часове в преследване на плащания, които никога не са били видени. Същото важи за оферти, които никога не получават отговор, и последователности от напомняния за плащане, които изстрелват в празното.

Третирайте удостоверените изпращащи домейни така, както третирате банковото съгласуване: скучен контрол, който поддържа парите в движение. Записвайте кой доставчик изпраща какво (фактури, разписки, маркетинг), така че всеки поток да остане удостоверен, и проследявайте закъснелите плащания спрямо датата, на която клиентът реално е видял фактурата – не само датата, на която системата ви я е изпратила. Чистите записи за доставка правят както проследяването ви, така и книгите ви по-честни.

За повече относно поддържането на вземанията в ред вижте ръководствата в /docs/ за работни процеси по фактуриране и изгледите в таблото /fava/, които извеждат просрочените салда с един поглед.

Опростете финансовото си управление​

След като фактурите ви надеждно достигат входящата кутия, уверете се, че следващото е също толкова чисто: ясни записи за това, което е фактурирано, платено и неплатено. Beancount.io предоставя счетоводство в обикновен текст, което ви дава пълна прозрачност и контрол върху финансовите ви данни – без черни кутии, без зависимост от доставчик. Започнете безплатно и дръжте всяка стотинка проследима от фактура до сметкоплан.