SPF: кой има право да изпраща
RFC 7208 тръгва от един факт: нищо в протокола за електронна поща не пречи на сървър да обяви какъвто и да е адрес на подател. SPF позволява на собственика на домейн да публикува в DNS списъка на сървърите, оправомощени да изпращат от негово име, а на получаващия сървър да провери това разрешение.
Две уточнения променят всичко:
- SPF проверява адреса на плика (този от диалога между сървърите, т.нар. „MAIL FROM“) и името, обявено от сървъра, а не адреса, който получателят чете в „От“.
- SPF преценява последния сървър, който е доставил съобщението. Когато съобщение бъде препратено от друг сървър, то вече не се доставя от сървър, оправомощен от изходния домейн: проверката може да е неуспешна, макар съобщението да е легитимно.
Един домейн публикува само един SPF запис. В него фигурират всички източници на изпращане: пощенската система, софтуерът за фактуриране, инструментът за бюлетини, CRM системата, копирната машина, която сканира към имейл.
DKIM: съобщението е подписано
Според RFC 6376 DKIM позволява на собственика на подписващ домейн да поеме част от отговорността за съобщение чрез криптографски подпис. Публичният ключ е в DNS. Проверката на подписа установява, че подписаните части не са променени след подписването.
Подписът пътува заедно със съобщението. Затова той понася по-добре от SPF преминаването през релейен сървър или препращането, стига този сървър да не променя темата или тялото. Пощенски списък, който добавя текст в края на съобщението, го разваля.
Какво DKIM не прави според същия RFC: не криптира съобщението, неуспехът не налага то да бъде отхвърлено, а подписващият домейн не е задължително този, който е показан в „От“. Точно тази празнина запълва DMARC.
DMARC: съответствие и политика
RFC 7489 определя DMARC като начин собственикът на домейн да изрази политика на ниво домейн. Механизмът се основава на съответствието (alignment): домейнът на адреса, показан в „От“, трябва да съответства на домейна, валидиран от SPF или от DKIM. Ако нито едното, нито другото съответства, DMARC е неуспешен.
Тогава домейнът публикува какво иска:
- none: не се изисква действие, само се наблюдава;
- quarantine: съобщението да се третира като подозрително;
- reject: съобщението да се отхвърли.
DMARC предвижда и отчети: обобщени отчети, които показват кои сървъри са изпращали от името на домейна и с какъв резултат, и отчети за неуспех, съобщение по съобщение. Именно те позволяват да откриете забравен инструмент, който изпраща от ваше име, или някой, който злоупотребява с вашия домейн.
| Механизъм | Какво проверява | Какво не разглежда |
|---|
| SPF | Сървърът, който доставя съобщението, е оправомощен за домейна на плика | Показания адрес, съдържанието |
| DKIM | Подписаното съобщение не е променено; даден домейн поема отговорност за него | Показания адрес, честността на съдържанието |
| DMARC | Показаният домейн съответства на SPF или DKIM; политика при неуспех | Сходните домейни, показваното име, текста |
Спира ли DMARC фишинга?
Той спира част от злоупотребите с домейна, но не и фишинга като цяло. RFC 7489 го казва изрично: DMARC не обработва визуално сходни имена на домейни, нито злоупотребата с показваното име, а анализът на съдържанието е извън обхвата му. Той не се опитва да реши всички проблеми на измамната поща.
На практика DMARC не вижда:
- домейн двойник: измамникът удостоверява безупречно собствения си домейн, който прилича на вашия;
- подправено показвано име: „Счетоводен отдел“, изписано от адрес без никаква връзка;
- компрометиран акаунт, който подписва правилно, тъй като изпраща истинският сървър;
- съобщение без връзка с вашия домейн: фалшиво известие от куриерска фирма идва от домейн, който няма нищо общо с вашия;
- домейн без политика: ако имитираният домейн публикува „none“, получателят няма указание за отхвърляне.
Тези случаи изискват други анализи: сходство на домейните, репутация, съдържание, поведение. Вижте Спам, фишинг, зловреден софтуер и компрометиран акаунт.
Препращане и пощенски списъци: ARC
Препращането често разваля SPF, списък, който променя съобщението, разваля DKIM, и тогава DMARC е неуспешен за легитимно съобщение. ARC, описан в RFC 8617 (експериментален статус), позволява на всеки посредник да удостовери резултата от проверката на автентичността, който е установил. Крайният сървър може да реши да го вземе предвид.
Да защитите домейна си, да филтрирате входящото
Това са две теми, които често се бъркат.
- Защита на домейна, който изпраща: публикуване на SPF, DKIM и DMARC за вашия домейн, за да могат другите да отказват съобщенията, които злоупотребяват с него. Вие публикувате; получателите прилагат.
- Филтриране на входящото: проверка на записите на другите домейни за пощата, която получавате, и след това прилагане на всички останали анализи.
Постепенно внедряване
- Опис на всичко, което изпраща от името на домейна.
- Един-единствен SPF запис, който ги оправомощава; DKIM подпис за всяка услуга, която може да подписва.
- DMARC в режим „none“, с адрес за получаване на отчетите.
- Четене на отчетите в продължение на няколко седмици; коригиране на забравените източници.
- Преминаване към „quarantine“, а след това към „reject“, когато всички легитимни изпращания съответстват.
Пример, за илюстрация. Една кантора публикува DMARC в режим „none“ и чете първите си отчети. В тях открива три източника: своята пощенска система, с правилно съответствие; софтуера си за фактуриране, който изпраща фактурите с домейна на кантората без DKIM подпис; и непознат сървър в чужбина, който изпраща стотици съобщения от нейно име. Тя коригира софтуера за фактуриране, изчаква един чист цикъл от отчети и преминава към „quarantine“: получателите, които прилагат DMARC, вече третират съобщенията от непознатия сървър като подозрителни.
Когато се сменя пощенската система, тези записи се подготвят преди смяната на MX. Ръководството Миграция на електронната поща без прекъсване описва този момент; тук той не се разглежда.
Често задавани въпроси
Защитава ли DMARC политика „none“?
Не. Тя позволява наблюдение чрез отчетите. Защитата започва с „quarantine“ или „reject“.
Защо легитимно съобщение не преминава DMARC?
Най-често: препращане, пощенски списък или услуга, която изпраща от ваше име, без да е декларирана в SPF и без да подписва с DKIM.
Нашата пощенска система не подписва с DKIM: какво да направим?
Шлюз, поставен по пътя на изходящата поща, може да подписва вместо нея. Вижте Защита на електронната поща, която вече имате.
Къде да видя резултата от тези проверки за получено съобщение?
В заглавните редове на съобщението. За Klytic MTA вижте Четене и експорт на решение на филтъра.
Къде е Klytic
Klytic MTA покрива и двете теми, пред всяка пощенска система:
- Essential и Advanced: проверка на SPF, DKIM и MX; проверка на DMARC, включително за препратени съобщения благодарение на ARC; DKIM подпис на изходящата поща, дори ако вашата пощенска система не го прави.
- Advanced: DMARC конзола с отчетите за вашите домейни, известия и насоки за корекции, за да проведете постепенното преминаване към „reject“.
DMARC е само един слой: Klytic MTA добавя разпознаване на домейни двойници, на показваното име и на сценарии за измами, описано в Подправяне на самоличност и измама „фалшив ръководител“.
Ако използвате Klytic Mail, SPF, DKIM и DMARC са настроени за вашия домейн: това е защитата на домейна, който изпраща. Klytic MTA се заявява със или без Klytic Mail.
Източници
Консултирани през октомври 2026 г.
- RFC 7208, SPF: собственикът на домейн публикува хостовете, оправомощени да използват неговия домейн в идентичността „MAIL FROM“ или „HELO“, а получателят проверява това разрешение. rfc-editor.org
- RFC 6376, DKIM: домейн поема отговорност за съобщение чрез криптографски подпис; без криптиране, без наложено отхвърляне, подписващият домейн може да е различен от показания автор. rfc-editor.org
- RFC 7489, DMARC: съответствие на домейна от „From“ със SPF или DKIM, политики none, quarantine и reject, обобщени отчети и отчети за неуспех; визуално сходни домейни, показвано име и анализ на съдържанието са извън обхвата. rfc-editor.org
- RFC 9989 (май 2026 г.), който заменя RFC 7489: същите стойности на политиката и същите изключения (сходни домейни, показвано име). rfc-editor.org
- RFC 8617, ARC (експериментален): удостоверена верига на предаване; DMARC получател може да приеме оценките, пренесени от валидна ARC верига. rfc-editor.org
- Klytic, страница Klytic MTA: проверки на автентичността, DKIM подпис на изходящата поща и DMARC конзола в плановете Essential и Advanced, опции, начини на внедряване, пускане в действие чрез MX. klytic.com
