Как да защитите своя бизнес от злоупотреба с фишинг, спуфинг и спам имейли с SPF, DKIM и DMARC?

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

За всеки опит за измама е предвидена и реципрочна мярка, която да предпази съответния бизнес от такава заплаха. Тези мерки обаче не се прилагат по подразбиране, а следва да се настроят по инициатива на бизнеса.

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

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

Какво е имейл удостоверяване?

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

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

Информацията е детайлна, но за да се види, е необходимо да се направят допълнителни действия от страна на потребителя, в зависимост от email клиента, който използва. В голяма част от случаите потребителят вижда само част от нея, като From: или Reply-To: адреса и това води до грешки и подвеждане.

From: (от) me@sample.com Моят бизнес
Date: (дата) 26.12.2022
Subject: (тема) 90% отстъпка

Заплахата се състои в това, че в полето From: (от), подателят може да напише, каквото пожелае – в т.ч. Вашето име или името на Вашия бизнес и да изпрати заблуждаващи имейли с цел злоупотреба до Ваши реални или потенциални клиенти, партньори и колеги.

Имейл удостоверяването има за цел да провери дали това лице има право да изпраща имейли от Ваше име и ако няма – Вие ще имате възможност да изберете как да се процедира с тези имейли. За тази цел са разработени набор от методи и протоколи: SPF, DKIM и DMARC.

Какво са SPF, DKIM и DMARC?

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

Какво е SPF за имейл удостоверяване?

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

Еволюция на SPF удостоверяването

SPF методът датира от 2000 г. с наименованието Sender Permitted From. Екип от експерти на IETF работи за комбиниране на SPF и предложението на Microsoft за CallerID. През 2006 г. е постигнат първият експериментален RFC, а през 2014 г. е утвърден актуалният стандарт SPF, познат и като RFC 7208.

Какво съдържа един SPF запис?

SPF удостоверяването се извършва с TXT запис в DNS зоната. Чрез него се указва кои IP адреси и/или имейл сървъри (SMTP) са упълномощени да изпращат имейли от Вашия домейн, както и каква да е политиката при неуспешно удостоверяване.

Ето как изглеждат примерни SPF DNS записи:

  • v=spf1 a mx include:smtp-spf.sample.com -all
  • v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a -all~
  • v=spf1 mx include:aspmx.googlemail.com -all

SPF синтаксисът включва 8 механизма или тага, които имат следното значение:

ALL Винаги се посочва в края на записа и указва как се процедира с неудостоверните имейли. Дефиницията се дава с квалификатораите „+“, „-„ и „~”, както следва: „+all” – допуска всички неудостоверени имейли (не се препоръчва)„-all”- отхвърля всички неудостоверени имейли„~all” – допуска неудостоверените имейли, но ги маркира, като такива.
A Удостоверяването може да се извърши, чрез A запис, ако връзката е през IPv4 или с AAAA запис, ако връзката е през IPv6.
IP4 В записа се посочва диапазон от IPv4 адреси и ако IP адресът на изпращача е в този диапазон – удостоверяването е успешно.
IP6 В записа се посочва диапазон от IPv6 адреси и ако IP адресът на изпращача е в този диапазон – удостоверяването е успешно.
MX Ако за домейна е създаден MX запис, който съответства с адреса на изпращача, то удостоверяването е успешно. В този случай мейлът идва от входящите мейл сървъри на домейна.
PTR Удостоверяването се извършва чрез PTR заявки. Използва се рядко.
EXISTS Удостоверяването се извършва чрез A заявка. Използва се рядко.
INCLUDE Референцията е към друг домейн.

Синтаксисът, както е видно, е сложен и многовариантен, който ние в Делта Клауд изготвяме за наши клиенти. А ето и примерна схема за удостоверяване на имейл с SPF запис в DNS зоната.

Как-работи-SPF-защитата-за-имейл-удостоверяване

Как се съставя SPF DNS запис?

Ето и кратки указания как се съставя SPF DNS запис за защита на бизнеса или домейна от имитиращи имейли от злонамерени трети лица - фишинг, спуфинг и спам атаки.

Като предварителна подготовка следва да се определи кои пощенски сървъри ще се използват за изпращане на имейли от въпросния домейн. Тези пощенски сървъри могат да бъдат и на трети лица.

  1. В самото начало на записа се посочва SPF версията -  v=spf1 (версия 1). Този таг е важен, тъй като дефинира записа като SPF. Имаше и втора версия на SPF (SenderID), но тя вече не се използва.
  2. След като се посочи SPF версията (v=spf1), се добавят всички IP адреси, които са упълномощени да изпращат имейли от Ваше име (въпросния домейн / бизнес). Например: v=spf1 ip4:31.243.61.267 ip6:2a05:d018:e4:8c00:bb71:dea8:86b83:851e.
  3. Ако желаете конкретни трети лица (напр. Ваши подизпълнители - маркетингова агенция и др.) да могат да изпращат имейли от Ваше име с Вашия домейн – следва да се добавят с тага include , напр. include:mypartner.com. С този етикет се упълномощава трета страна да изпраща имейли от името на Вашия домейн.
  4. Както посочихме по-горе – за финал се използва тага all, който указва каква политика да се приложи, ако мейлът идва от сървър, който не е посочен във вашия SPF запис. Възможните решения са три.
    • Допускане на имитиращия имейл - най-непрепоръчителната политика. За да бъде прилагане пред етикета се поставя знак „+“ – до “+all”.
    • Отхвърляне на неудостоверения имейл - най-крайната политика. Тя се указва, като пред all се постави знакът „-„ (“-all”).
    • Допускане на имейла с маркиране - Softfail - по-умерената политика – Softfail. При нея неудостовереният имейл се допуска, но се маркира, като такъв. Прилага се с указанието „~all”

Ако не желаете от Вашия домейн да се изпращат имейли, въвежда запис „v=spf1 –all“.

SPF записите могат да бъдат с дължина до 255 знака и с до 10 тага include, в т.ч. и т.нар. “lookups” ( и A и MX).

Как се въвежда SPF DNS запис?

Въвеждането на записа е по-лесната част. Ето каква е последователността от необходимите действия, за добавяне на SPF DNS записа:

  1. Необходимо е да се влезе в акаунта, в който се менажира домейна или CDN;
  2. Следва да се потърси т.нар. на DNS мениджър (управление на DNS или управление на name servers);
  3. Избира се домейна, за който ще се добавят SPF DNS записи;
  4. Отваря се DNS мениджъра;
  5. Създава се нов TXT запис в секцията TXT;
  6. В полето Host се посочва името на домейна, за който се въвежда запис;
  7. В полето TXT Value се поставя SPF записа (напр.  “v=spf1 a mx include: sample.com ~all”);
  8. Посочва се продължителността на живот (TTL) с въвеждане на 3600 или се оставя по подразбиране;
  9. Записва се (съхранява се) записа с натискане на бутона за „Запис“ или “Save”, за да се публикуват SPF TXT записа в DNS зоната.

Какво не прави SPF удостоверяването (недостатъци)?

При SPF удостоверявнето има недостатъци, които се преодоляват с надграждащи услуги, като DMARC, поради което и в самото начало посочихме, че работят в синергия. Ето и какво липсва при SPF имейл удостоверяването:

  1. SPF удостоверяването не потвърждава елемента „От“ (From) в имейл хедъра.
  2. Ако злонамереното писмо бъде препратено, „препращачът“ става новият „подател“. Така SPF удостоверяването на препратеното писмо може да бъде успешно, тъй като проверката засяга само последния подател.
  3. При SPF удостоверяването няма отчет и обратна връзка към Вас, за да знаете, че има опит за злоупотреба с Ваш домейн. Такава отчетност предоставя DMARC протокола, който е препоръчително да се използва с SPF удостоверяването. По-долу предоставяме информация и за нея.

Какво е DKIM за имейл удостоверяване?

DKIM е малко по-усъвършенстван метод за имейл удостоверяване, който използва цифрови сертификати. DKIM е абревиатура от Domain Keys Identified Mail.

Методът за имейл удостоверяване DKIM е създаден чрез сливането на две съществуващи спецификации - Domain Keys (създадени от Yahoo) и Identified Internet Mail (от Cisco) през 2004 г., като има и регистрация като RFC от IETF.

Във времето DKIM технологията доби широка популярност и се прилага за имейл удостоверяване от всички водещи ISP в т.ч. Google, Microsoft и Yahoo.

Как се прилага DKIM удостоверяването на имейли?

Първата стъпка е да бъде генериран сертификат, който ще бъде използван за подписването на email съобщенията. Той има два аспекта - публична и лична (private) част, като втората винаги се съхранява на изпращащия сървър. Именно това гарантира и по-високото ниво на сигурност при DKIM.

Изпращане: Кагото се изпраща email съобщение, части от него (хедър, боди или самото съдържание) се използват за създаването на хеш стойност заедно с частният ключ.

Целта на това действие е да се удостовери пред отсрещната страна (получаващия сървър), че съобщението по никакъв начин не е било променяно.

Получател: Отсрещната страна, на получателя, когато получи подобно съобщение, извършва подобно действие. Той отново криптира съобщението, като тук вече се използва публичният ключ, който е генериран и отново създава хеш.

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

Как-работи-DKIM-методът-за-имейл-удостоверяване

Какво не прави DKIM методът (недостатъци)?

DKIM методът не е надежден метод за удостоверяване на подателя на имейла, ако се използва самостоятелно. Както и при SPF удостоверяването – текстът в полето „От“ може да имитира Вашия домейн и няма отчетност, обратна връзка към Вас за създадените злоупотреби.

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

Какво е DMARC за имейл удостоверяване?

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

DMARC е абревиатура от Domain-based Message Authentication Reporting and Conformance и използва съществуващите методи за удостоверяване на имейли SPF (Sender Policy Framework) DKIM (Domain Keys Identified Mail), които разгледахме по-горе.

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

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

Как, кога и кой създава протокола DMARC?

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

В работата по протокола DMARC се включват лидери в индустрията - PayPal заедно с Google, както и Microsoft, и Yahoo! Съвместно те разработят оперативната спецификация на протокола DMARC, за да получи и статут на официален стандарт през 2012 г.

Към момента протоколът DMARC се поддържа от всички големи интернет доставчици (като Google, Microsoft, Yahoo! и т.н.) и очаква одобрение, за да стане отворен стандарт, одобрен от Работната група за интернет инженерство (IETF).

Защо е важно да се използва протокола DMARC?

Броят на регистрираните имейл акаунти расте с всяка година и към края на 2022 г. е близо 5 милиарда глобално. Поради това и имейл каналът е изключително успешен за маркетингови цели.

Разбира се – тази е и причината имейл каналът да е желана цел за кибер престъпниците. Въпреки мерките, които се взимат за защита и сигурност на този канал, престъпността се увеличава всяка година. 95% от всички хакерски атаки и пробиви на данни включват имейл.

От популярните и утвърдени протоколи за защита на имейл канала, DMARC дава най-висока стойност, тъй като пердоставя най-пълна картина за имейл каналите и прави фишинг атаките видими.

Според проучвания за 2021 г.:

  • Приблизително 15 милиарда спам имейли се изпращат всеки ден, което означава, че спам филтрите „работят извънредно“ и могат да позволят злонамерени имейли с фишинг атаки да се промъкнат през тях .
  • 83% от организациите съобщават, че са пострадали от фишинг атаки. 
  • През 2021 г. година са идентифицирани приблизително 214 345 уникални фишинг уебсайта, а броят на последните фишинг атаки се е удвоил от началото на 2020 г.
  • 30% от фишинг имейлите се отварят. Това увеличава вероятността дадено лице неволно да отвори злонамерен линк или да изтегли убедително изглеждащ документ, който съдържа зловреден софтуер.
  • 42% от служителите споделят, че са предприели опасно действие (кликнали са върху неизвестна връзка, изтеглили са файл или са разкрили лични данни), докато са били онлайн, като не са следвали най-добрите практики за предотвратяване на фишинг.
  • Приблизително 90% от злоупотребата с данните е поради фишинг. Според Федералното бюро за разследване на САЩ, фишинг атаките може да се увеличат с до 400% на годишна база .
  • Приблизително 65% от кибер престъпниците използват фишинг имейли като основен вектор на атака.
  • На въпроса за въздействието на успешните фишинг атаки, 60% от лидерите по сигурността заявяват, че тяхната организация е загубила данни, 52% са претърпели компрометиране на идентификационни данни, а 47% от организациите са се борили с ransomware.
  • 93% от организациите измерват цената на фишинг атаките по някакъв начин, и само 60% от тези предлагат официално обучение по киберсигурност на своите служители.
  • Исторически погледнато - най-засегнати от фишинг атаки са финансови институции, предприятия за социални медии, услуги за SaaS/уеб поща и доставчици на дребно.
  • Според Swiss Cyber Institute фишинг съобщенията в LinkedIn са 47% от всички опити за фишинг в социалните медии.

Какво получавате, ако използвате DMARC протокол?

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

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

С добавянето на DMARC запис във вашата DNS зона, Вие ще имате цялостен поглед над своя имейл канал. Интернет доставчиците ще Ви предоставят Aggregate DMARC отчети (RUA) и Forensic DMARC reports (RUF) на ежедневна база. Тези отчети могат да бъдат изпращани на имейл адреса, който е публикуван във вашия DMARC запис.

1. Aggregate DMARC отчети (RUA)

  • Изпращат се ежедневно
  • Предоставят общ преглед на имейл трафика
  • Включват всички IP адреси, които са се опитали да изпратят имейл от Ваше име

2. Forensic DMARC reports (RUF)

  • Изпращат се в реално време
  • Изпраща се само за повреди
  • Включват хедърите на съобщенията
  • Могат да включват и самото съобщение

С DMARC протокола имате контрол как да се процедира, ако се изпращат злонамерени имейли от Ваше име.

Намаляване на спуфинг измамите с DMARC протокол

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

Проверява се дали писмото има валидни SPF и DKIM записи и дали те съответстват на домейна, от който се изпраща. Ако тези проверки са успешни, то писмото е DMARC съвместимо, ако не са, то имейлът не преминава успешно през DMARC защитата.

След DMARC валидацията, с имейлите се процедира според това каква е възприетата от Вас DMARC политика. Опциите или правилата са 3: none (само за наблюдение), quarantine (карантина)  и reject (отхвърляне).

Как-работи-DMARC-протоколът
Правила за наблюдение: p=none

Първата политика е none (наблюдение): p=none . Тя изисква от получателите на имейли да Ви изпращат DMARC отчети, за да имате идея за своя имейл канал. Препоръчва се, като встъпителна, за да се информирате за трафика през своя имейл канала.

Тази политика има за цел основно мониторинг и опознаване на имейл канала и не дава разпореждане как да се процедира, ако има имейли, които не преминават през DMARC протокола за валидиране.

При първоначално прилагане на DMARC протокола, тази предпазливост и консерватизъм са препоръчителни, тъй като по грешка могат да бъдат отхвърлени и коректни имейли.

Политика за карантина: p=quarantine

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

За разлика от тях, имейлите, които преминават успешно през DMARC протокола, ще се доставят в основната входяща имейл кутия на получателя. Тази политика в известна степен защитава бизнеса Ви от измама, но фалшивите имейли ще се доставят до получателя в спам папката.

Политика за отхвърляне: p=reject

Третата политика е за отхвърляне: p=reject. Ако изберете тази най-крайна политика, Вие ще получавате DMARC доклади, а имейлите, които не преминават през DMARC валидация, ще бъдат отхвърляни и няма да бъдат доставяни до получателите.

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

DMARC-политики

Как се създава DMARC запис?

DMARC записът дефинира DMARC правилата, които да се прилагат. Той дава информация на доставчиците на интернет услуги (като Gmail, Microsoft, Yahoo! и др.), че даден домейн е настроен да използва DMARC.

DMARC записът е TXT запис, който се добавя към DNS зоната на Вашия домейн. Името на TXT записа трябва да бъде „_dmarc.sample.com“. където „sample.com“ следва да се замени с името на Вашия домейн (или поддомейн).

Ето и някои от по-популярните тагове, които се използват за DMARC TXT записи, а пълният списък, можете да разгледате тук:

Tag Name Required Purpose Sample
v required Protocol version v=DMARC1
p required Policy for domain p=quarantine
pct optional % of messages subjected to filtering pct=20
rua optional Reporting URI of aggregate reports rua=mailto:CUSTOMERID@for.dmarcanalyzer.com
ruf optional Addresses to which message-specific forensic information is to be reported (comma-separated plain-text list of URIs). ruf=mailto:CUSTOMERID@for.dmarcanalyzer.com
rf optional Format to be used for message-specific forensic information reports (comma-separated plain-text list of values). rf=afrf
aspf optional Alignment mode for SPF aspf=r
adkim optional Alignment mode for DKIM adkim=r

Как се създава и публикува DMARC запис

Създаването и публикуването на DMARC минава през следните 5 стъпки:

  • Избита се на политиката на DMARC - избира се една от трите DMARC политики, за да се определи как имейл получателите да обработват имейли, които не са преминали DMARC проверките от DMARC записа.
  • Избира се alignment mode - alignment mode ( aspf / adkim ) се отнася до прецизността, с която записите на изпращача да се сравняват със SPF и DKIM методите. Двете възможни стойности са „по-свободно“ или „по-строго“ търсене на съответствие, обозначени съответно с „r“ и „s“. При по-свободния режим се допускат частични съвпадения, като поддомейни на даден домейн, докато по-строгият изисква точно съвпадение.
  • Добавяне се имейл адрес, на който да се изпращат отчетите - за получаване на ежедневни отчети следва да се включи имейл адрес с незадължителния маркер rua.
  • Създава се TXT записа - комбинират се всички данни от предишните стъпки и се създава стойността на TXT записа.
  • DMARC TXT записът се добавя към DNS зоната на домейна.

Какво още е добре да знаете за DMARC протокола?

Има някои ползи, а и заблуди, свързани с DMARC протокола, които не сме споменали до момента, а е хубаво да бъдат обмислени.

DMARC протоколът не е задължителен

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

По-високо доверие

Ако прилагате DMARC протокол, пощенските сървъри ще имат по-високо доверие към Вашия домейн и е по-вероятно да доставят писмата, които изпращате.

Не започвайте с политика на отхвърляне

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

Логично е всеки бизнес да търси максимална защита, но при некоректно въведени данни, могат да бъдат отхвърлени и коректни имейли, поради което е препоръчително да се започне с политика none за наблюдение.

Резултатите следва да се наблюдават и анализират, за да се постигне коректно SPF и DKIM удостоверяване. Едва след като се потвърди, че всички протоколи и записи са коректни, е уместно да се приложи политиката на отхвърляне.

Силно препоръчваме бавно да се увеличи използването на DMARC, като се използват тези правила в този ред.

Трафикът следва да се наблюдава и да се търсят аномалии в отчетите. Например съобщения, които все още не са подписани или може би са подправени. След като продължително време не се откриват аномалии, плитиката е уместно да се промени от „none“ на „quarantine“.

Преглеждането на резултатите следва да продължи, този път както в спам папките, така и в ежедневните отчети на DMARC. Едва след като е абсолютно потвърдено, че всичките съобщения са подписани, политиката може да се промени на „reject“, за пълноценно използване на DMARC.

За подкрепа на консервативния подход, можете да се използва незадължителния pct таг. Стойността по подразбиране е 100%, но избраната политика да се прилага само за част от имелите, като се въведе стойност по избор.

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

Ето и пример за по-консервативен цикъл, с който е уместно да се започне въвеждане на DMARC политика:

  1. Monitor all.
  2. Quarantine 1%.
  3. Quarantine 5%.
  4. Quarantine 10%.
  5. Quarantine 25%.
  6. Quarantine 50%.
  7. Quarantine all.
  8. Reject 1%.
  9. Reject 5%.
  10. Reject 10%.
  11. Reject 25%.
  12. Reject 50%.
  13. Reject all.
DMARC не се прилага за входящата поща

DMARC протоколът се прилагат само за изходящата поща и няма приложение за входящата имейл кореспонденция. Изключение правят мейлите в организацията – тези, които изпращате до колеги. При въведен DMARC протокол, те няма да получават фалшиви имейли от името на организацията.

Заключение

Безспорно е, че имейл каналите за комуникация с клиенти, партньори и колеги са сред най-използваните и апетитни за атака от злонамерени лица. Затова и подсигуряването на тяхната защита е критично за запазване на изграденото доверие и репутация на бизнеса.

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

Боряна Попова

Боряна Попова

Боряна обича технологиите и има афинитет към това - сложните неща да бъдат обяснявани разбираемо, за да бъдат достъпни за повече хора. Има интереси и в областите AI, ML, SEO, копирайтинг, дизайн и др. С внимание към детайла и силата на думите, Боряна харесва нетипичните и нестандартни решения и обича да излиза out of the box.

Абонирайте се за Delta Cloud бюлетин

Абонирайте се за бюлетина на Delta Cloud, за да получавате ексклузивни оферти, актуални новини, статистики и ценна информация за облачните технологии, информационната сигурност и услугите, които предлагаме.