DMARC verification failed: как да диагностицирате и оправите грешката преди B2B кампания

Ако получавате bounce или отказ с текст sending domain does not pass dmarc verification and has a dmarc policy of reject, домейнът ви вече не достига до входящата кутия на получателите — независимо колко добре е написано писмото. Това е особено болезнено при таргетиран B2B outreach, където всеки контакт е предварително проучен и загубата му не е просто статистика. Тук обясняваме откъде идва грешката, как да я диагностицирате за 10 минути и как да настроите DMARC правилно, преди да пуснете кампания.

Какво точно казва грешката sending domain does not pass dmarc verification

Когато получаващият сървър (Gmail, Outlook, корпоративен mail gateway) провери входящо писмо, той не гледа само дали SPF и DKIM минават поотделно — проверява дали домейнът в полето From съвпада (alignment) с домейна, удостоверен от SPF или от DKIM подписа. Съобщението sending domain does not pass dmarc verification and has a dmarc policy of reject означава именно това несъответствие: писмото технически идва от оторизиран сървър, но header-домейнът не съвпада с него, а DMARC записът на домейна казва „отхвърляй“.

Разликата между трите нива на DMARC политика е важна. p=none означава само наблюдение — писмата минават, но собственикът на домейна получава отчети. p=quarantine изпраща провалените писма в спам. p=reject ги отхвърля directno, често без bounce обратно към изпращача, което значи, че кампанията просто „изчезва“ без видима следа в статистиката ви.

За cold email в B2B контекст това е критично, защото често не изпращате от основния корпоративен домейн, а от subdomain или алтернативен адрес — и точно там alignment-ът се чупи най-лесно.

Защо грешката е особено честа при Strato и cPanel хостинг

Strato и подобни shared хостинг доставчици публикуват собствен SPF запис по подразбиране, който покрива само техния пощенски сървър. Ако изпращате студени писма през платформа като LDM, през Google Workspace alias или през друг SMTP relay, реалният изпращащ сървър не е включен в този SPF запис — и alignment-ът пада, дори DKIM подписът да е коректен.

В cPanel панелите има настройка, буквално озаглавена нещо от рода на dmarc quarantine reject policy not enabled — тя контролира дали локалният mail сървър филтрира входяща поща по DMARC, но няма нищо общо с това как Gmail или Outlook третират изходящите ви писма. Много администратори включват тази опция, мислейки, че така „решават“ проблема, докато реалната причина остава непокътната в самия DMARC TXT запис на домейна.

• SPF записът покрива само хостинг пощата, не и изпращащия инструмент за outreach
• Header From домейнът е различен от домейна, за който е генериран DKIM подписът (d= таг)
• Subdomain за изпращане (напр. mail.company.bg) няма собствен DMARC/SPF запис и наследява политика без покритие
• Препращане (forwarding) на пощенската кутия чупи SPF автоматично при трети получатели
• Множество SPF записи за един домейн вместо един обединен — DNS позволява само един валиден TXT запис за SPF

Стъпки за диагностика на конкретния домейн

Диагностиката отнема няколко команди и не изисква достъп до сървъра — само DNS. Проверете последователно трите записа, преди да пипате каквото и да е в cPanel.

Проверете дали изпращащият IP или домейн на relay-а (например SMTP сървъра на LDM или на вашия ESP) действително фигурира в SPF include веригата — не е достатъчно SPF записът да „съществува“, трябва да покрива точния източник на писмата.

• dig TXT _dmarc.вашдомейн.bg — проверява самата DMARC политика (p=none/quarantine/reject) и адреса за отчети (rua=)
• dig TXT вашдомейн.bg — проверява SPF записа и дали изпращащият сървър е включен чрез include:
• dig TXT selector._domainkey.вашдомейн.bg — проверява дали DKIM селекторът, използван от изпращащия инструмент, публикува валиден публичен ключ
• Сравнете домейна в полето From на реално изпратено писмо с домейна в SPF/DKIM удостоверенията — именно тук е най-честото несъответствие
• Прегледайте DMARC aggregate отчетите (ако rua= адрес е зададен) — те показват точно кои източници минават и кои не

Как да коригирате SPF, DKIM и DMARC подравняване

Първата стъпка е да добавите реалния изпращащ сървър или инструмент в SPF записа чрез include механизъм — не презаписвайте съществуващия SPF, а го обединете в един запис, тъй като два отделни SPF TXT записа автоматично провалят проверката. Втората стъпка е да включите DKIM подписване в платформата, през която изпращате, и да се уверите, че домейнът в d= тага на подписа е същият (или организационно съвпадащ) с домейна в полето From.

Едва след като SPF и DKIM минават коректно за реалния трафик, публикувайте или актуализирайте DMARC записа. Препоръчителна последователност: започнете с p=none и rua= адрес за отчети две до три седмици, наблюдавайте кои източници минават, след това преминете на p=quarantine, и едва накрая — при чист трафик — към p=reject.

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

Най-скъпата грешка е директното публикуване на p=reject върху домейн, който никога не е бил наблюдаван — резултатът е тих провал на цялата кампания без ясен сигнал защо. Втората честа грешка е игнорирането на subdomain политиката (sp=), когато изпращате от поддомейн — DMARC записът на главния домейн не покрива автоматично поддомейните без изричен sp= таг.

Трета грешка е смесването на изпращащи източници под един и същ header домейн — маркетингов инструмент, транзакционна поща и cold outreach платформа едновременно, без да е ясно кой точно минава SPF/DKIM alignment. Това прави отчетите нечетими и забавя корекцията с седмици.

Как LDM проверява домейна преди старт на кампания

Преди да пуснем таргетирана B2B кампания за клиент, проверяваме SPF, DKIM и DMARC записите на изпращащия домейн като отделна стъпка, не като реакция на bounce-ове. Ако домейнът е нов или досега е ползван само за корпоративна поща, препоръчваме отделен поддомейн за outreach — така основният домейн остава защитен, а новият минава период на затопляне (warm-up) с малки дневни обеми.

Мониторингът продължава и след старта — следим bounce rate и reply rate по домейн, а не само общо за кампанията, защото рязък спад в конкретен изпращащ адрес често е първият сигнал за проблем с alignment, преди дори получателят да е забелязал нещо.

• Проверка на SPF include веригата за реалния изпращащ сървър, не само за хостинг пощата
• Съвпадение на DKIM d= домейна с header From домейна на всеки изпращащ адрес
• DMARC политика в преходен режим (p=none → quarantine → reject) с реален период на наблюдение
• Отделен поддомейн за студен outreach, изолиран от транзакционна и маркетингова поща
• Ежедневно проследяване на bounce rate по домейн през първите седмици от кампанията

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