Кой изпраща имейли от името на вашата фирма

Трите записа отговарят на три различни въпроса

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

SPF отговаря на въпроса: има ли този сървър право да изпраща от наше име. Домейнът публикува списък с IP адреси и включени доставчици; получателят сравнява IP адреса на свързалия се сървър с този списък. Важната подробност, която почти винаги се пропуска: SPF се проверява спрямо адреса в SMTP плика (MAIL FROM), а не спрямо адреса, който потребителят вижда в полето From. Двата могат да са различни. Стандартът е RFC 7208.

DKIM отговаря на въпроса: променено ли е съобщението по пътя. Изпращащият сървър подписва криптографски избрани заглавки и тялото и добавя заглавката DKIM-Signature. Получателят изтегля публичния ключ от DNS и проверява подписа. DKIM не казва нищо за това кой е имал право да изпраща — казва само, че притежателят на ключа е поел отговорност и че съдържанието не е било пипано. Стандартът е RFC 6376, който има статут на Internet Standard (STD 76).

DMARC отговаря на въпроса: какво да направи получаващият сървър, когато няма успешен SPF или DKIM резултат, съответстващ на видимия подател. Той прави и нещо, което другите два не правят — свързва резултата с домейна във видимото поле From. Изисква поне един от SPF или DKIM да е минал и домейнът му да съвпада с домейна в From. Това съвпадение се нарича подравняване (alignment) и е основата на удостоверяването по DMARC. От май 2026 г. DMARC е Standards Track документ — RFC 9989, който замени информационния RFC 7489.

Проверката за десет минути

Направете тези заявки за собствения си домейн. От Linux или macOS с dig, от Windows с nslookup -type=TXT. Заменете example.com с вашия домейн.

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short MX example.com

Как да прочетете отговора:

• Няма запис v=spf1. На проверения домейн няма SPF политика. Уточнете действителния домейн в SMTP плика.
• -all, ~all, ?all, +all. Това са fail, softfail, neutral и pass за останалите изпращачи. Получателят решава доставянето; softfail не изисква сам по себе си папка „Спам“. Избягвайте +all.
• Няма запис при _dmarc. Проверете за наследена политика от организационния домейн, преди да заключите, че DMARC липсва.
• p=none. Не се изисква карантина или отхвърляне по DMARC. Обобщените отчети изискват валиден адрес в rua и получатели, които изпращат отчети. Другите филтри могат да отхвърлят пощата.
• Поддомейни и въвеждане. Без отделна политика се наследява приложимата политика. Липсата на sp или np сама по себе си не оставя поддомейна незащитен. RFC 9989 заменя pct с флаг за тестване t; проверете поддръжката от получателите преди промяна на съществуващото въвеждане.

DKIM не може да се провери отвън, ако не знаете селектора — той не е публично изброим. Вземете го от истинско съобщение, което вие сте изпратили: отворете изходния текст и намерете s= в заглавката DKIM-Signature. После проверете dig +short TXT s1._domainkey.example.com със стойността на s=.

Последната стъпка е тази, която променя разговора. Изпратете съобщение от вашата поща до пощенска кутия при голям доставчик и погледнете заглавката Authentication-Results (RFC 8601). Там пише какво е заключил чуждият сървър: spf=pass, dkim=pass, dmarc=pass (p=NONE). Успехът при това легитимно съобщение потвърждава конкретния път на изпращане; не проверява отхвърлянето на подправена поща.

Защо „имаме DMARC“ не е отговор

DNS ви казва какво сте публикували. Не ви казва какво се случва, когато някой опита.

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

Затова интересният въпрос не е „имате ли DMARC“. Интересният въпрос е дали някой е проверил какво реално се случва, когато някой опита — от неоторизиран сървър, с вашия домейн в From, към кутия, която вие контролирате. Това е измерване, не документ. Уговорете обхвата и прозореца за тест; резултатът дава отговор, който само DNS не може да даде.

Какво не спира нито един DNS запис

Три неща минават през безупречно конфигуриран DMARC.

Сходен домейн. Нападателят регистрира example-bg.com, exarnple.com или същото име в друг домейн от първо ниво и публикува на него собствени SPF, DKIM и DMARC записи. Всички проверки минават, защото съобщението наистина е автентично — за неговия домейн. Кирилицата прави това по-остро: „а“, „о“, „е“, „р“, „с“ имат визуално идентични латински двойници, но правилата на регистрите и браузърите ограничават някои комбинации и начина на показването им.

Показвано име. Полето From може да гласи Финансов отдел – [фирма] <нечий.адрес@gmail.com>. DMARC минава безупречно, защото проверява домейна gmail.com и той е коректен. На телефон видимата част често е само показваното име; адресът изобщо не се показва.

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

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

Защо това е търговски въпрос

Три причини, всяка от които стои и без другите две.

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

Второ, въпросникът за сигурност на клиента може да пита за DMARC. „Прилагате ли DMARC на p=quarantine или p=reject“ е въпрос с отговор да или не и купувачът може да го провери сам, отвън, за секунди, без да ви вярва на думата. Малко други твърдения в такъв документ са толкова лесно опровержими — вижте и как се отговаря на въпросник за сигурност.

Трето, това вече е въпрос на доставяемост. От февруари 2024 г. Google изисква SPF, DKIM и валиден DMARC запис от изпращачите на 5 000 и повече съобщения дневно към Gmail. От 5 май 2025 г. Microsoft въведе същия праг за потребителските си услуги (Outlook.com, Hotmail.com, Live.com); несъответстващата поща се отхвърля с код 550 5.7.15. Проверете текущите правила на всеки получаващ доставчик; прагът за големи изпращачи не гарантира доставяне под него.

Какво да направите първо

1. Съставете списък на легитимните изпращачи. Не по памет. Извадете го от фактурите за услуги и от стойностите d= и s= в заглавките на собствената ви изходяща поща за последния месец. Пропуснат изпращач може да спре да се доставя след затягането.
2. Направете трите заявки от предната секция и запишете отговорите. Датирайте ги. Това е изходната точка, спрямо която ще мерите.
3. Включете докладването преди прилагането. Публикувайте v=DMARC1; p=none; rua=mailto:... с адрес, който някой действително чете, и оставете месец. Отчетите ще покажат изпращачи, които не сте знаели, че съществуват.
4. Затегнете на стъпки и покрийте поддомейните. От p=none към p=quarantine, после към p=reject, и проверете действащите политики за изпращащи, неизпращащи и несъществуващи поддомейни. Задавайте изрични изключения, когато са необходими.
5. Затворете домейните, които не изпращат поща. За всеки паркиран или защитно регистриран домейн публикувайте v=spf1 -all, v=DMARC1; p=reject; и null MX (RFC 7505) само ако този домейн не трябва и да получава поща. Това е най-евтината печалба и почти винаги е забравена.
6. Проверете, вместо да предполагате. Опитайте доставка с вашия домейн в From от неоторизиран сървър към кутия, която контролирате, и прочетете какво е направил получателят. Само върху ваши домейни и ваши кутии.

Удостоверено писмо може да поиска измамна промяна на банковата сметка. Използвайте отделната проверка на плащането при одобрението.

Границата

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

Затягането може да счупи легитимна поща. Препращането и пощенските списъци нарушават SPF; ARC (RFC 8617) съществува за този случай, но не се зачита навсякъде. Затова стъпките са постепенни и отчетите се четат, а не се пропускат.

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

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

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

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

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