Модул 4 · 4.5
DMARC: какво трябва да правят получателите с фалшива поща
Модул 4: Записи за имейл · Време за четене: 10 минути
Цел на урока: След този урок ще можете да обясните как DMARC съчетава SPF и DKIM, да съставите валиден DMARC запис и да затегнете политиката стъпка по стъпка.
Основни понятия: DMARC, _dmarc, v=DMARC1, политика p=none / quarantine / reject, съгласуване (alignment), rua отчети, sp= и np=, тестов режим t=, само един DMARC запис
Липсващата част
SPF (урок 4.3) проверява от кой сървър идва писмото, но гледа техническия envelope адрес. DKIM (урок 4.4) проверява подпис, но той може да е от всеки домейн. Измамник може да изпрати писмо с "Van: info@example.com", което минава успешно през SPF за своя собствен домейн и е коректно подписано от своя собствен домейн.
DMARC (Domain-based Message Authentication, Reporting and Conformance) затваря този кръг. Той задава един въпрос: дали успешната SPF или DKIM проверка принадлежи на домейна, който получателят вижда в адреса "Van:"? Това се нарича съгласуване (alignment). И Вие казвате на получателите какво да правят, ако отговорът е не.
DMARC е описан през 2015 г. в RFC 7489. През май 2026 г. е публикувана преработената версия като официален интернет стандарт: RFC 9989 (с RFC 9990 и 9991 за отчетите). Съществуващите записи с v=DMARC1 остават валидни.
Как решава получателят
Когато пристигне писмо с подател info@example.com, получателят прави следното:
- SPF: идва ли писмото от разрешен сървър и принадлежи ли envelope домейнът на
example.com? - DKIM: има ли валиден подпис и принадлежи ли подписващият домейн (
d=) наexample.com? - DMARC: успешна ли е поне една от двете проверки и съгласувана ли е? Тогава писмото е наред. Ако не, получателят следва Вашата политика.
Едно от двете е достатъчно. Затова DKIM е толкова важен за услуги, които изпращат със собствен envelope адрес, като много услуги за бюлетини: при тях SPF минава, но не за Вашия домейн. Само DKIM подпис с d=example.com прави писмото валидно тогава.
"Принадлежи на" по подразбиране означава: същия организационен домейн. nieuws.example.com принадлежи на example.com. Това се нарича relaxed съгласуване. С adkim=s или aspf=s (strict) трябва да е точно същият домейн. За почти всички relaxed е подходящо.
Как изглежда DMARC запис?
DMARC записът е TXT запис на името _dmarc на Вашия домейн:
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"Състои се от части (tags), разделени с точка и запетая.
| Tag | Значение |
|---|---|
v=DMARC1 | Това е DMARC запис. Трябва да е на първо място. |
p= | Политиката за Вашия домейн: none, quarantine или reject. |
rua=mailto:... | По избор: адрес за ежедневни обобщени отчети. |
sp= | По избор: друга политика за съществуващи поддомейни. |
np= | По избор (ново в RFC 9989): политика за поддомейни, които не съществуват, например factuur.example.com, ако никога не сте го създавали. Измамниците обичат да използват такива имена. |
adkim= / aspf= | По избор: r (relaxed, по подразбиране) или s (strict). |
t=y | По избор (ново в RFC 9989): тестов режим. Получателите прилагат с една стъпка по-мека политика. Заменя старото pct=. |
Избор на политика
| Политика | Какво прави получателят |
|---|---|
p=none | Нищо. Писмото просто се доставя. Получавате отчети, ако попълните rua. Нарича се още наблюдение. |
p=quarantine | Писмата, които не отговарят на изискванията, отиват в папка спам. |
p=reject | Писмата, които не отговарят на изискванията, се отхвърлят. Най-добрата защита срещу злоупотреба с Вашето име. |
Разумен ред на действие:
- Първо уредете SPF и DKIM за всички услуги, които изпращат имейли от Ваше име: Вашия имейл доставчик, Вашия уебсайт, Вашата услуга за бюлетини, Вашата счетоводна програма, Вашия онлайн магазин.
- Започнете с
p=noneи адрес заrua. Прегледайте отчетите няколко седмици, за да видите кои услуги изпращат имейли от името на Вашия домейн и дали успяват. - Преминете към
p=quarantine, и ако всичко продължава да работи добре, преминете къмp=reject.
Ако не сте сигурни дали всички Ваши услуги са настроени правилно, не преминавайте веднага към reject. Забравена услуга (например програмата, която изпраща Вашите фактури) тогава вече няма да достига до получателите.
Някои хостинг компании задават строг DMARC запис (p=reject) веднага при нов пакет. Това е безопасно, стига цялата Ваша поща да минава през техните сървъри. Ако изпращате поща и чрез други услуги, първо проверете SPF и DKIM на тези услуги.
Отчети
С rua=mailto:dmarc@example.com получавате от големите получатели ежедневен преглед (XML файл) на това кой е изпращал поща от името на Вашия домейн и дали е успял. Полезно, но технически. Използвайте отделен адрес за това; бързо ще получавате по няколко на ден. Има услуги, които правят отчетите четими.
Ако изпращате отчетите на адрес в друг домейн (например услуга за отчитане), този друг домейн трябва да даде разрешение в своя DNS. Услугата обикновено урежда това сама.
Чести грешки
- Два DMARC записа. На
_dmarcможе да има само един. При два записа получателят приема, че нямате DMARC. Коригирайте съществуващия запис. - На грешното име. Записът принадлежи на
_dmarc.example.com, а не на самияexample.com. - Правописни грешки в tags.
p=rejectработи,p=rejectedилиpolicy=rejectне работят. Без валиденp=записът се брои заp=none. - Включване на DMARC преди SPF и DKIM да са наред. Тогава отхвърляте собствената си поща.
- Твърде бърза повторна проверка след промяна. DMARC записът понякога има дълго TTL (например четири часа). След промяна ще видите стария запис известно време.
Защо е важно
От февруари 2024 г. Gmail и Yahoo изискват от подателите на големи обеми поща (над около 5000 на ден) DMARC запис, минимум с p=none, и SPF или DKIM да успява съгласувано. Microsoft изисква същото от май 2025 г. за Outlook.com и Hotmail. И за малки подателите DMARC подобрява доставянето и защитава Вашите клиенти от фалшиви фактури от Ваше име.
На практика: така изглежда в панел
В този пример използваме DirectAdmin. В DNS Administration кликвате върху молива до TXT записа _dmarc, или създавате нов TXT запис с име _dmarc и избирате DMARC при TXT Record Type. При Domain policy type избирате None, Quarantine или Reject; при Aggregate Email (RUA) въвеждате по желание адрес за отчети. Моят WebOké разполага с подобен DMARC помощник в раздела DNS.
Ако Вашият панел няма такъв помощник, създавате обикновен TXT запис на _dmarc и въвеждате текста сами. Резултатът е същият.
Обобщение
- DMARC проверява дали SPF или DKIM успяват за домейна в адреса "Van:" (съгласуване).
- Записът се намира на
_dmarc.<domein>, започва сv=DMARC1и има политикаp=none,quarantineилиreject. - Първо SPF и DKIM за всички услуги, после
p=noneс отчети, после затягане. - Точно един DMARC запис на домейн.
Тест
Задача
Задача Z4.5: Търсене на DMARC. Потърсете DMARC записа на sidn.nl (или на Вашия собствен домейн). Вмъкнете пълния запис и посочете каква политика (p=) е зададена.
Задача O4.5: Самостоятелна настройка в тренировъчната зона. В тренировъчната зона изпращате отчетите на фиксиран тренировъчен адрес; за Вашия реален домейн използвате собствен адрес. Създайте в тренировъчната зона <code>.dnspractice.euquarantine (или none, ако искате да започнете с наблюдение) и отчети към dmarc@dnspractice.eu (rua=mailto:dmarc@dnspractice.eu).
Задача O4.5
Тази задача изпълнявате във Вашата собствена тренировъчна зона: истинска DNS зона на DNS сървърите на WebOké, само за Вас. Впишете се с Вашия имейл адрес. Ще получите линк за вход по имейл и след това ще се върнете на този урок. Използваме Вашия адрес само за курса.
Допълнително четене
Стъпките в тези статии важат за панелите на WebOké; в други панели работи по подобен начин.
- Какво е DMARC? Обяснение на разбираем език
- Ръководство за DirectAdmin 5.9: DMARC инсталиране
- Създаване на DMARC запис в DirectAdmin
- Ръководство на WebOké 5.5: DNS помощници: MX, SPF, DMARC, CAA и SRV
- Публична проверка на имейл (SPF, DMARC, MX): https://www.weboke.nl/bg/proverka-na-imeyl, и имейл тестът на internet.nl: https://internet.nl
- RFC 9989 (DMARC), RFC 9990 (отчети); исторически RFC 7489