Когато фактурите и потвържденията не стигат до клиента

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

Онлайн магазин: потвърждението на поръчката и номерът за проследяване. Без тях клиентът звъни, поръчва втори път или отказва пратката.

Резервации в хотел, ресторант, клиника или салон: потвърждението и напомнянето. Без тях растат неявяванията и двойните резервации.

Фактуриране и абонаменти: фактурата и напомнянето за плащане. Без тях плащанията закъсняват.

Регистрация и вход: потвърждението на имейла и новата парола. Без тях клиентът не може да влезе и се обажда на поддръжката или се отказва.

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

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

Най-скъпо струва третият начин. Сървърът приема съобщението и го поставя в спам. Системата отчита „доставено“, в компанията никой не разбира, а клиентът приема, че не сте му писали.

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

Често липсват или са грешно настроени SPF, DKIM и DMARC, записите в DNS на домейна. SPF и DKIM потвърждават, че писмото е изпратено с разрешение на домейна, а DMARC казва на получателя какво да направи, ако не идва, и изпраща отчети. Понякога пощата излиза директно от сървъра на хостинга, а фактурите и рекламните кампании споделят един домейн. Тогава една кампания с много оплаквания засяга и фактурите.

Днес Gmail и Outlook разчитат силно на репутацията на домейна и на удостоверяването, не само на IP адресите. Gmail и Yahoo от 2024 г., а Microsoft от 2025 г. изискват SPF, DKIM и DMARC от подателите на голям обем поща.

Проблемът се среща и в малки, и в големи компании. Малкият бизнес обикновено ползва безплатен план, настроен веднъж при пускането на сайта. Голямата компания изпраща от десетки системи, настроени от различни хора през годините. И в двата случая никой не отговаря изрично за доставката. Маркетингът разчита на ИТ, ИТ разчита на доставчика, а доставчикът отчита, че е приел съобщението.

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

Повечето такива услуги имат стъпка „удостоверете домейна си“ при настройката. Тя често се пропуска, защото нищо не спира да работи веднага. Писмата просто започват по-често да попадат в спам.

Освен това доставчикът отчита дали сървърът на получателя е приел съобщението. Дали то е във входящата кутия или в спам, в обичайните му отчети не се вижда.

В големите компании това често не се следи, защото отделните системи са въведени от различни екипи. Когато такава компания за пръв път включи отчетите на DMARC, често вижда повече места, които изпращат от нейно име, отколкото някой е предполагал.

Клиенти казват, че не са получили потвърждение или са го намерили в спам.

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

Проблемът изглежда случаен, защото едно съобщение стига, а следващото не.

Никой в компанията не може да каже от кои системи и през кои доставчици се изпраща поща от името на домейна. Ако е така, рискът вече е налице.

Един отговорник. Конкретен човек в компанията или външен партньор отговаря за доставката и има достъп до отчетите на доставчиците.

Отделни потоци. Служебната поща остава на основния домейн, а известията и маркетинговите кампании излизат от отделни поддомейни, всеки със своя репутация. Така проблем с една кампания много по-трудно засяга фактурите.

Подходяща инфраструктура. План с изолиран пул или отделен IP адрес, съобразен с обема. Отделният адрес има смисъл само при достатъчен обем и след постепенно „загряване“.

Удостоверен домейн. SPF, DKIM и DMARC, настроени така, че домейнът в адреса на подателя да съвпада с подписа, а политиката на DMARC да се затяга постепенно.

Ако служителите, кампаниите и известията изпращат от един и същ домейн, проблем с репутацията засяга и писмата на служителите. Оферта или договор до важен клиент може да попадне в спам. Изнасянето на известията и кампаниите на отделни поддомейни намалява този риск.

Удостоверяването защитава и от друго. Без DMARC с политика за отказ всеки може да изпрати писмо, което изглежда като от вашия домейн, например фалшива фактура с друга банкова сметка до ваш клиент. DMARC спира такива писма от точно вашия домейн при сървърите, които го спазват. Срещу подобни на него домейни (например firma-bg.com) не пази, затова промени в банкови сметки винаги се потвърждават по друг канал.

Всеки ден: процентът доставени съобщения, отказите и оплакванията, с известие при спад.

Всеки месец: отчетите на DMARC, репутацията на домейна в Google Postmaster Tools и проверка в черните списъци на домейна, а при отделен IP адрес и на него.

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

При всяка нова система или доставчик: удостоверяване, преди да изпрати първото съобщение.