Defaults.Exposed › Поправки › DMARC (Email Spoofing Protection)

Как да поправите DMARC (Email Spoofing Protection)

DMARC е единствената настройка, действително казваща на пощенските доставчици в света да БЛОКИРАТ имейли, фалшифициращи наименованието на вашия бизнес. SPF и DKIM проверяват заключалките; DMARC решава какво се случва, когато фалшификацията не минава проверката — в боклука, маркирана или пусната. Неправилно зададен, домейнът ви е изцяло имитируем; зададен правилно — имперсонацията спира при входящата кутия.

Заключение за вашия бизнес: Без DMARC enforcement, престъпник може да изпраща имейл, изглеждащ точно като от вашия бизнес — на клиентите, персонала и доставчиците ви — и той попада в пощенската им кутия, а не в нежеланата. Хора биват измамвани от ваше наименование и вас ви обвиняват.

Какво може да ви струва това

• Измамник изпраща на клиента ви изглеждаща реална фактура 'от счетоводния ви отдел' с техни банкови данни. Клиентът плаща. Разбирате седмици по-късно, когато гонят стоките, вече платени — и те ви държат отговорни.
• Фалшив имейл за 'спешно плащане' отива до финансовото ви лице, изглеждащ като от вас, собственика. Превеждат парите преди някой да помисли да провери двойно — и след като попаднат в акаунта на престъпника, почти никога не се възстановяват.
• IT екипът на голям потенциален клиент прави проверка за сигурност на домейна ви преди подписване. Връща се 'имейлът не е защитен — може да се фалшифицира.' Губите сделката в полза на конкурент, чийто домейн я е преминал.
• Домейнът ви се използва в фишинг вълна. Измамените клиенти оставят ядосани отзиви и предупреждават другите. Репутационната щета надживява атаката с месеци.
• Дори истинският ви имейл започва да попада в нежеланата, защото Google и Yahoo все по-силно не вярват — и сега понякога отхвърлят — домейни без наложен DMARC.

Защо има значение. Имейлът никога не е бил изграден да доказва кой наистина го е изпратил, така че фалшифицирането на адреса 'от' е тривиално. DMARC е единственият контрол, превръщащ 'можем да засечем фалшификати' в 'фалшификатите се блокират' — и ви дава и ежедневните доклади, разкриващи кой изпраща поща от наименованието на марката ви. Големите доставчици на пощенски кутии сега третират липсваща или неналожена DMARC политика като сигнал за недоверие срещу вас, така че това влияе и на доставянето на собствения ви имейл.

Как да го поправите, стъпка по стъпка

1. Настройте SPF или DKIM първо. DMARC се гради на тях; уверете се, че поне едно е настроено и наредено преди да започнете.
2. Публикувайте мониторингов запис. Добавете TXT запис при _dmarc.yourdomain с v=DMARC1; p=none; rua=mailto:you@yourdomain за събиране на доклади без влияние върху доставката.
3. Четете докладите. В продължение на седмица или две използвайте агрегатните доклади, за да потвърдите, че цялата легитимна поща минава.
4. Преминете към quarantine. След като легитимната поща минава чисто, повишете политиката до p=quarantine, за да попада фалшивата поща в нежеланата.
5. Наложете с reject. Накрая задайте p=reject, за да се отказва фалшивата поща изцяло — настройката, действително спираща имперсонацията.

Какво е DMARC с прости думи

Имейлът има мръсна тайна: редът „от” е просто въведен текст. Всеки, навсякъде, може да напише вашето бизнес наименование и адрес в полето „от” на имейл и да го изпрати. Интернет никога не е бил проектиран да ги спира.

Има три настройки, заедно поправящи това. Мислете за тях като сигурността на сграда:

• SPF е списък на тези, разрешени да влизат през главния вход (кои пощенски услуги могат да изпращат от ваше наименование).
• DKIM е неманипулируем печат, доказващ, че съобщението не е изменено при пренос.
• DMARC е охраната, проверяваща списъка и печата — и, критично, решаваща какво да прави когато не съвпадат: да ги пусне, да ги прати в нежелана или да ги върне при входа.

Можете да имате списъка (SPF) и печата (DKIM) и все пак да нямате охрана. Това е единствената най-честа и най-опасна ситуация: заключалките съществуват, но нищо не ги налага. DMARC е enforcement. Той е разликата между „можем да кажем, че имейлът е фалшив” и „онзи фалшив имейл никога не достига клиента ви.”

Какво може да ви струва това

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

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

2. Прехвърлянето по CEO измамата. Имейл изглежда, че идва от вас, собственика, до финансовия ви служител: „Можеш ли да прокараш това плащане спешно, в среща съм.” Изглежда напълно реално, защото е вашият адрес — просто фалшифициран. Плащането излиза. Onзи модел — Business Email Compromise — е един от най-скъпите измами, засягащи малкия бизнес, именно защото имейлът наистина идва от собствения ви домейн, така че преминава направо покрай подозрението.

3. Изгубеният договор. Сериозен потенциален клиент прави проверка за сигурност или обществени поръчки преди подписване. Инструментът им докладва домейна ви като „имитируем — без enforcement на имейл автентикацията.” Онзи единствен червен флаг може да е достатъчен да даде договора на конкурент, чийто домейн е преминал. Никога дори не чувате истинската причина.

4. Репутационният удар, който не можете да отмените. Домейнът ви е засметен в фишинг кампания. Десетки хора, измамени от ваше наименование, публикуват предупреждения и отзиви. Атаката трае седмица; въпросът „тази компания безопасна ли е?” отеква с месеци.

5. Собственият ви имейл попада в нежеланата. Google и Yahoo сега активно не вярват на домейни без наложен DMARC. Оферти, фактури и отговори, изпратени наистина от вас, тихо започват да попадат в папките за нежелана. Сделките спират и никога не разбирате защо.

Какво всъщност е (и как изглежда „добро”)

DMARC живее като единствен ред текст в настройките на домейна ви — DNS „TXT” запис, публикуван при специалното наименование _dmarc.yourdomain. В него има няколко кратки инструкции. Две от тях имат най-голямо значение — именно тях проверява тази оценка.

1. Политиката (p=) — заповедите на охраната. Това е тежко оценяваната част от проверката. Може да е едно от три неща:

• p=none — само наблюдение. Охраната отбелязва кой е минал, но не спира никого. Не ви защитава от нищо; това е фаза на мониторинг, а не завършена настройка. (Двигателят ни го оценява като неуспех — по-добре от без DMARC, но не е защита.)
• p=quarantine — праща фалшификатите в нежеланата. Реална защита, но решителен нападател залага хората да проверяват нежеланата. Добра стъпка в прехода — носи приблизително половин точки.
• p=reject — отказва фалшификатите при входа. Фалшивият имейл никога не се доставя. Това е единствената настройка, напълно ви защитаваща и носеща пълни точки.

Как изглежда „добро”: p=reject. Всичко по-малко оставя пропаст.

Две технически подробности, проверявани и от нашата система, струва да знаете, за да не ви изненадат:

• Политиката за поддомейни (sp=). Може да зададете силна политика за основния домейн, но случайно да оставите поддомейните (като mail.yourdomain или news.yourdomain) широко отворени. Двигателят ни санкционира това сериозно — домейн с p=reject, но sp=none се оценява близо до без никакъв enforcement, защото нападателите просто ще фалшифицират поддомейн вместо. Добрата практика е sp да наследи силната ви основна политика или да бъде зададен изрично на reject.
• Процентът (pct=). При внимателно въвеждане можете да прилагате enforcement само към дял от пощата (например pct=25). Това е легитимен инструмент за преход, но частичното въвеждане дава само частична защита и оценката ни отразява това — нараства стабилно при движение от 25% към 100%, но пълните точки изискват пълно покритие.

2. Адресът за докладване (rua=) — вашата видимост. Това е втората проверка на тази страница. Тагът rua= моли всеки пощенски доставчик в света да ви изпраща ежедневно резюме на кой е опитвал да изпраща имейл от домейна ви — собствените ви системи и всякакви имитатори. Без него летите сляпо: нямате представа кой злоупотребява с вашето наименование. С него, бизнесите редовно разкриват между 5 и 50 неупълномощени подателя в самия първи ден.

Как изглежда „добро” за докладването: валиден адрес rua=mailto: (или URL на услуга за докладване https:), реално получаващ докладите. Проверката ни валидира формата — сгрешен или неправилно оформен адрес означава докладите тихо не отиват никъде, което се оценява като частичен или провален резултат, дори когато тагът технически е „наличен.”

Как да го поправите (безплатно, ~30 минути разпределени в две седмици)

Дайте тази секция на когото управлява домейна, уебсайта или IT — поправката е изцяло безплатна. Ние таксуваме само за мониторинг, че остава правилно с времето, за управление на портфолио от домейни или за одит. Самата промяна не струва нищо.

Златното правило: никога не прескачайте направо към reject. Включете мониторинга първо, гледайте докладите, потвърдете, че реалната ви поща е разпозната, след това затегнете. Направено в онзи ред е безопасно; направено набързо може да изхвърли собствения ви имейл.

Стъпка 1 — Уверете се, че SPF и DKIM са на място първо. DMARC разчита на тях. Ако някое от двете липсва, наредете ги преди да наложите DMARC (вижте страниците за SPF и DKIM).

Стъпка 2 — Публикувайте мониторингов запис с включено докладване. Добавете DNS TXT запис:

• Host / name: _dmarc.yourdomain (DNS доставчикът ви може да го показва само като _dmarc)
• Type: TXT
• Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain; adkim=s; aspf=s

Това наблюдава и докладва без блокиране на нищо засега. Частите adkim=s; aspf=s изискват строго наредване — пропуснете ги начало, ако сте несигурни, и добавете след потвърждаване на чистата поща.

Стъпка 3 — Четете докладите ~2 седмици. Суровите DMARC доклади са гъсти XML. Използвайте безплатна услуга за докладване (например dmarcian или безплатния DMARC инструмент на Postmark), за да ги превърнете в четим таблу. Потвърдете, че всеки легитимен подател — доставчикът на пощенска кутия, инструментът за бюлетини, CRM, помощно бюро, приложението за фактуриране — минава. Поправете всеки истински подател, който не минава.

Стъпка 4 — Преминете към quarantine. След като реалната ви поща е чиста, сменете p=none с p=quarantine. Наблюдавайте още няколко дни.

Стъпка 5 — Преминете към reject. Накрая сменете p=quarantine с p=reject. Вече сте напълно защитени. Крайният запис изглежда така:

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain; adkim=s; aspf=s

Стъпка 6 — Не забравяйте поддомейните. Уверете се, че не сте оставили sp=none на място. Ако не публикувате изобщо sp, поддомейните наследяват основната ви p= политика, което е желаното.

Бележки по обичайна платформа:

• Google Workspace / Microsoft 365: И двете напълно поддържат DMARC. Самият DMARC запис отива в DNS доставчика ви, а не в административната конзола на Google или Microsoft — уверете се, че SPF и DKIM са активирани в административната конзола първо, след това публикувайте DMARC TXT записа при регистратора/DNS хоста.
• Cloudflare: DNS > Records > Add record > TXT, наименование _dmarc, поставете стойността. Cloudflare предлага и вградено DMARC управление, което може да настрои това и да събира докладите вместо вас.
• Обичайни хостове/регистратори (Blacknight, GoDaddy и т.н.): Потърсете „DNS”, „DNS Zone” или „Advanced DNS”, добавете TXT запис с наименование _dmarc и горестоящата стойност. Разпространението обикновено отнема минути до час.

Чести грешки

• Спиране при p=none. Най-честата грешка до голяма степен. Мониторингът е началото, а не краят — домейн, заседнал при none, е все още изцяло имитируем. Двигателят ни го оценява като неуспех именно по тази причина.
• Прескачане направо към reject без мониторинг. Обратната грешка. Без фазата на докладване може да не осъзнаете, че даден легитимен подател (нерядко инструмент за бюлетини или фактуриране) не е нареден — и ще започнете да блокирате собствената си поща.
• Забравяне на политиката за поддомейни. Силен p=reject с sp=none оставя страничен вход широко отворен; нападателите просто фалшифицират поддомейн вместо.
• Счупен адрес за докладване. Сгрешен rua= (или такъв без префикса mailto:) означава докладите не отиват никъде и оставате слепи без да разберете. Форматът трябва да е валиден mailto: или https: URI, иначе докладите никога не се доставят.
• „Ние не изпращаме имейл, затова ще го пропуснем.” Неизпращащ домейн е основна цел именно защото никой не го наблюдава. Публикувайте строга reject политика, за да го заключите изцяло.

Бележка за оценяването

Проверката на политиката (p=) е едно от най-тежко оценяваните елементи в цялата оценка — защото е единственият най-важен фактор за това дали бизнесът ви може да бъде имперсониран. reject носи пълни точки; quarantine носи приблизително половина; none и липсващ запис се оценяват като неуспехи. По-слабата политика за поддомейни или частичното въвеждане с pct= дърпа оценката надолу, за да съвпада с реалното ниво на защита, реално имате.

Проверката за докладване (rua=) носи и тя реално тегло, но мислете за нея по-малко като кутия за отметка и повече като инструмент, позволяващ ви безопасно да достигнете reject. Настройте я едновременно с мониторинговия запис и тя се изплаща във видимост от първия ден.

Настройте го при вашия хост

Стъпка по стъпка за популярни доставчици:

• Настройте DMARC при GoDaddy
• Настройте DMARC при Namecheap
• Настройте DMARC при Cloudflare
• Настройте DMARC при Google Workspace
• Настройте DMARC при Microsoft 365
• Настройте DMARC при Squarespace
• Настройте DMARC при Wix
• Настройте DMARC при AWS Route 53
• Настройте DMARC при Hostinger
• Настройте DMARC при Porkbun
• Настройте DMARC при IONOS
• Настройте DMARC при Bluehost

Чести ситуации

• 'DMARC policy not enabled'
• DMARC fails but SPF and DKIM pass
• Moving from p=none to p=reject
• Someone is spoofing your domain
• Newsletter platform failing DMARC
• Gmail bounce 550-5.7.26

ЧЗВ