Как да изберете правилната DMARC политика за B2B cold email кампании

Ако изпращате cold email кампании до конкретни контакти в компании, DMARC политиката на вашия домейн решава дали писмата ви ще стигнат до входящата кутия или направо ще изчезнат. Много B2B изпращачи публикуват DMARC запис с p=none и после се чудят защо reply rate-ът им внезапно пада, след като преминат към quarantine или reject без подготовка. Тази статия обяснява разликата между трите политики и как да изберете правилната, без да рискувате легитимни писма до реални бизнес контакти.

Какво означава DMARC политика за вашия домейн

DMARC (Domain-based Message Authentication, Reporting and Conformance) е DNS запис от тип TXT, поставен на _dmarc поддомейна на вашия изпращащ домейн. Той свързва резултатите от SPF и DKIM с домейна, посочен в полето From, и казва на получаващия mail сървър — Gmail, Outlook, Yahoo — какво да прави, ако тази връзка не се потвърди. DMARC policy meaning накратко: тагът p= в записа определя действието — none, quarantine или reject.

За B2B изпращач, който праща персонализирани писма до конкретни служители в конкретни компании, тази политика е двуостър меч. От една страна, коректно конфигуриран DMARC с reject практически елиминира фишинг под вашето име и вдига доверието на домейна пред пощенските доставчици. От друга страна, ако политиката е избрана прибързано, без да сте проверили кои канали изпращат от ваше име (CRM, ESP, фактуриращ софтуер), реални писма до реални лийдове могат да бъдат отхвърлени още преди получателят да ги види.

Трите DMARC политики: none, quarantine, reject

Записът в DNS изглежда приблизително така: _dmarc.technoplast.bg TXT v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@technoplast.bg; pct=100. Стойността след p= е политиката, а разбирането на dmarc quarantine reject policy отличията е ключово, преди да пипате продукционен домейн.

• p=none — писмо, което не преминава SPF/DKIM alignment, се доставя нормално, но получавате RUA отчети за всеки изпращащ източник. Използва се само за наблюдение.
• p=quarantine — непреминалите писма се маркират като подозрителни и обикновено попадат в папка Спам вместо в инбокс.
• p=reject — получаващият сървър отхвърля писмото на SMTP ниво, подателят получава bounce, а получателят изобщо не го вижда.
• pct= — процент от непреминалите писма, към които се прилага политиката; полезен за постепенна ескалация от 10% до 100%.

Как да преминете от none към reject без да загубите доставимост

Прибързаният скок директно на p=reject е най-честата причина легитимни B2B писма да изчезват безследно. Правилният подход е поетапен: започвате с p=none, четете RUA отчетите (обикновено XML файлове, изпращани дневно от Google, Microsoft и др.), идентифицирате всеки легитимен източник — собствен SMTP, ESP за кампании, фактуриращата система — и ги подравнявате със SPF и DKIM, преди да затегнете политиката.

На практика spf pass dkim pass dmarc none е нормалното състояние в началото на мониторинга — SPF и DKIM минават индивидуално, а DMARC остава на none, докато трае наблюдението. Едва когато делът на подравнения трафик е стабилно висок, преминавате първо на quarantine с pct=25 или pct=50, после на reject.

Защо SPF pass, DKIM pass, но DMARC fail

Един от най-объркващите резултати за начинаещите е spf dkim pass dmarc fail — SPF и DKIM минават индивидуално, но DMARC все пак се проваля. Причината е domain alignment: DMARC изисква домейнът в SPF (Return-Path) или в DKIM подписа да съвпада (или да е поддомейн) с домейна в полето From, което вижда получателят.

Класически сценарий за B2B изпращачи: ESP платформата изпраща писмото през собствения си SMTP с валиден SPF на техния домейн, а DKIM подписва с ваш ключ, но полето From показва вашия корпоративен адрес. Ако SPF домейнът не съвпада с From домейна, alignment се проваля и DMARC маркира писмото като неуспешно, дори SPF технически да е минал. Решението е relaxed alignment (по подразбиране в повечето DMARC записи) плюс коректна конфигурация на DKIM подписването през вашия собствен домейн, а не през общ домейн на доставчика.

Чести грешки при DMARC политика за cold outreach

Повечето проблеми с доставимостта при таргетирани B2B кампании идват не от самия DMARC, а от липсата на подготовка преди затягането му.

• Липсва DMARC запис изобщо — статус dmarc policy not enabled — тогава получаващите сървъри прилагат собствена евристика, а вие нямате видимост през отчетите.
• Директен скок на p=reject без предварителен мониторинг на none/quarantine — блокира собствени легитимни изпращащи системи.
• Изпращане на cold outreach директно от основния корпоративен домейн вместо от изолиран поддомейн — грешка в един канал засяга и фактури, и HR писма.
• Forwarding правила при получателя чупят SPF alignment и водят до фалшиви DMARC failures, които объркват анализа.
• Игнориране на RUA отчетите след първоначалната настройка — политиката остава на none с години, без реална защита.

Как LDM подхожда към DMARC при клиентски B2B кампании

При таргетиран cold outreach — малки дневни обеми, персонализирани писма до конкретни служители — препоръчваме изпращащ поддомейн, отделен от основния корпоративен домейн, с постепенна DMARC ескалация: старт на none за 2-4 седмици наблюдение, после quarantine с нарастващ pct, и reject едва след стабилни отчети.

Проверката преди всяка кампания включва: валиден SPF запис за поддомейна, DKIM селектор специфично за изпращащата платформа, DMARC alignment между From и удостоверяващите домейни, и активни RUA отчети към адрес, който реално се следи. Така основният корпоративен домейн остава защитен с по-строга политика, а изпращащият поддомейн за outreach се управлява отделно, без риск легитимни отговори от реални лийдове да бъдат изгубени заради прекалено агресивна DMARC настройка.

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