SPF, DKIM и DMARC: как да защитите домейна си, преди да пуснете студена кампания

Ако домейнът ви няма правилно конфигурирани SPF, DKIM и DMARC записи, Gmail и Outlook третират всеки студен имейл като потенциален спам — независимо колко добре е написан текстът. Това ръководство показва точните стъпки за настройка в DNS зоната, за Google Workspace и за Office 365, плюс най-честите грешки, които развалят репутацията на домейна преди първата кампания. Целта не е да заобиколите филтрите, а да докажете на пощенските сървъри, че писмата ви идват точно от вас.

Защо SPF, DKIM и DMARC са предпоставка за B2B студени имейли

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

Практиката при таргетирани B2B кампании показва ясна разлика: домейн без нито един от трите записа често вижда 30–40% от писмата си директно в папка Spam, докато домейн с пълна автентикация и разгрята репутация стабилно държи 90%+ inbox placement. Разликата не е в текста на писмото — тя е чисто техническа.

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

Как да настроите SPF запис стъпка по стъпка

SPF (Sender Policy Framework) е TXT запис в DNS зоната на домейна, който изброява разрешените изпращащи сървъри. Настройва се веднъж на ниво домейн, не на ниво пощенска кутия.

• Влезте в DNS панела на регистратора си (Cloudflare, DirectAdmin, cPanel и т.н.)
• Проверете дали вече има съществуващ SPF запис (търсете TXT запис, започващ с "v=spf1") — не трябва да има два отделни SPF записа за един домейн
• За Google Workspace добавете: v=spf1 include:_spf.google.com ~all
• За Office 365 добавете: v=spf1 include:spf.protection.outlook.com ~all
• Ако използвате допълнителен инструмент за студени кампании (например поддомейн, изпращащ през трети SMTP), добавете и неговия include ред в същия запис
• Използвайте ~all (soft fail), не -all, докато не сте сигурни, че всички легитимни подателски сървъри са включени
• Проверете разпространението с dig TXT yourdomain.com или онлайн SPF checker след 15–30 минути

DKIM в Google Workspace и Office 365

DKIM изисква генериране на публичен/частен ключ от пощенския провайдър и публикуване на публичния ключ като TXT запис с конкретен селектор.

• Google Workspace: Admin Console → Apps → Google Workspace → Gmail → Authenticate email → Generate new record, копирайте TXT записа и селектора (обикновено google._domainkey)
• Office 365: Microsoft 365 Defender → Email & collaboration → Policies & rules → DKIM, изберете домейна и включете DKIM подписването — Microsoft генерира два CNAME записа
• Добавете генерирания запис точно както е показан — без допълнителни кавички или интервали, това е честа причина за невалиден DKIM
• Изчакайте разпространение на DNS (до 24 часа, обикновено под час) и активирайте DKIM в панела едва след като записът се разпространи
• Проверете с изпращане на тестово писмо до Gmail адрес и преглед на "Show original" — трябва да видите dkim=pass

DMARC — от p=none до p=reject

DMARC записът се публикува на поддомейн _dmarc.yourdomain.com и казва на получаващите сървъри какво да правят с писма, които не преминат SPF или DKIM проверка. Правилният подход е постепенен, не рязък скок на строга политика.

Започнете с p=none, за да получавате само доклади (rua=), без да блокирате нищо. След 1–2 седмици наблюдение на репортите преминете на p=quarantine (писмата отиват в спам при провал), а едва след стабилни резултати — на p=reject.

Чести грешки при настройка

Повечето проблеми с deliverability при cold email идват не от липса на записи, а от грешна или частична конфигурация.

• Два отделни SPF TXT записа на един домейн — DNS позволява само един, останалите правят валидацията невалидна
• SPF запис, надхвърлящ 10 DNS lookup-а (лимит на протокола) — честo при много include директиви от различни инструменти
• DKIM селектор, копиран без последния символ или с добавени кавички от текстов редактор
• Директен скок от липсващ DMARC на p=reject без период на наблюдение — блокира и легитимна поща
• Изпращане на студени кампании от основния корпоративен домейн, вместо от отделен поддомейн, което излага репутацията на цялата организация
• Забравена проверка след промяна на изпращащ инструмент — SPF записът остава стар и вече не покрива новия сървър

Как LDM подхожда към автентикацията

Преди активиране на всяка кампания LDM проверява автоматично SPF, DKIM и DMARC записите на изпращащия домейн или поддомейн и не позволява стартиране, ако липсва някой от трите. Това не е бюрократична пречка — то предпазва клиента от изгаряне на репутацията на домейна още при първата вълна писма.

За нови клиенти препоръчваме изпращане от отделен поддомейн, поетапно увеличаване на дневния обем (warm-up) и DMARC на p=quarantine преди първа реална кампания. Комбинацията от коректна техническа настройка и разумен обем на изпращане е това, което държи cold email легитимен, а не спам.

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