Внедряване на DMARC: от none до reject

Модул 4: Доставимост: SPF, DKIM и DMARC на практика · Време за четене: 12 минути

Учебна цел: След този урок ще можете да обясните как работи подравняването, да планирате поетапно внедряване на DMARC от p=none към p=reject, да изберете правилните тагове (rua, sp, np, t) и да се справите с познатите капани при пренасочване и пощенски списъци.

Основни понятия: DMARC (RFC 9989), Author Domain (домейнът в полето From), подравняване (alignment), relaxed и strict (adkim, aspf), организационен домейн, DNS tree walk, p=none, p=quarantine, p=reject, rua, sp, np, t=y (тестов режим), отпаднали тагове pct, rf, ri, пощенски списъци, пренаписване на From, ARC

Какво проверява DMARC точно

DMARC отговаря на един въпрос за всяко входящо писмо: успешен ли е SPF или DKIM за домейн, който принадлежи към адреса от полето From? Домейнът в полето From се нарича в стандарта Author Domain. Основите на записа са описани в DNS курса, урок 4.5. През май 2026 г. беше публикуван преработеният стандарт: RFC 9989, с RFC 9990 за обобщените отчети и RFC 9991 за отчетите за грешки. Съществуващите записи с v=DMARC1 остават напълно валидни.

Подравняване на практика

„Принадлежи към“ се нарича подравняване (alignment). Съществуват два режима:

• relaxed (по подразбиране): домейните имат един и същ организационен домейн. nieuws.example.com и example.com са подравнени; example.com и example.net не са.
• strict (adkim=s или aspf=s): домейните трябва да бъдат точно еднакви.

За SPF DMARC сравнява домейна от Return-Path с домейна от From. За DKIM, домейна d= на валиден подпис. Няколко примера за писмо с Van: info@example.com:

Затова оставете adkim и aspf на relaxed, освен ако нямате основателна причина.

Как получателят знае какъв е организационният домейн? По-рано това се определяше с Public Suffix List, списък с домейни като .nl, .co.uk и github.io. RFC 9989 заменя това с DNS tree walk: получателят търси записи _dmarc на домейна и на по-горните домейни. За обикновения потребител нищо не се променя; забелязва се само ако работите със записи на поддомейни.

Внедряването в четири фази

Целта е p=reject: тогава получателите отказват писма, които се представят за Вас, и това е най-добрата защита срещу фалшиви фактури и phishing от Ваше име. Но който веднага премине към reject, без да познава своите подателите, скоро ще отхвърля собствените си фактури. Затова следвайте тази последователност (препоръчителният подход в този курс):

Фаза 0: подготовка

• Направете инвентаризация на всички Ваши подателите (урок 4.2).
• Уверете се, че всеки подател има подравнен SPF или DKIM; за предпочитане DKIM, тъй като той оцелява при пренасочване.
• Създайте отделен адрес за отчетите, например dmarc@example.com, или използвайте услуга за отчети. Много бързо ще получавате по няколко отчета на ден.

Фаза 1: измерване с p=none

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

p=none не прави нищо със самото писмо. Получателите доставят всичко както обикновено, но Ви изпращат ежедневно обобщен отчет (aggregate report) с всеки сървър, изпращал поща от името на Вашия домейн, и дали SPF, DKIM и DMARC са преминали успешно. По този начин изпълнявате и минималното изискване на Gmail, Yahoo и Microsoft за масови подателите (урок 5.3).

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

Фаза 2: p=quarantine

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

Писма, които не преминат DMARC, отиват при получателя в папката за спам. Ако все пак пропуснете даден източник, писмото не изчезва, но е трудно да се намери. Ако искате да бъдете предпазливи, добавете първо t=y (тестов режим): тогава получателите прилагат с една стъпка по-мека политика (при quarantine, следователно none), но в отчетите виждате какво би се случило. Това в RFC 9989 е заместителят на стария таг pct=.

Наблюдавайте отново отчетите в продължение на няколко седмици.

Фаза 3: p=reject

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Писма, които не преминат DMARC, се отхвърлят. Подателят получава bounce, при Microsoft например с код 5.7.509, а при Gmail с позоваване на политиката DMARC (модул 6). Продължавайте да следите отчетите: винаги се появяват нови услуги.

Кога може по-бързо?

Ако цялата Ви поща минава през един доставчик, който урежда SPF и DKIM вместо Вас, и нищо друго не се изпраща от името на Вашия домейн? Тогава може веднага да приложите строга политика. Някои хостинг компании затова задават по подразбиране p=reject. Ако впоследствие решите да използвате услуга за бюлетини или счетоводна програма, задайте временно обратно p=none с адрес за отчети, докато тази услуга заработи правилно.

Другите тагове

Адрес за отчети на друг домейн (например услуга за отчети) работи само ако този домейн даде разрешение с запис като example.com._report._dmarc.rapportdienst.example. Услугата обикновено урежда това сама (RFC 9990, глава 4).

Капани

Пощенски списъци

Класически пощенски списък препраща Вашето писмо до всички членове от собствения си сървър и често добавя [списък] към темата или футър. Тогава SPF се проваля (друг сървър) и DKIM се проваля (писмото е променено). С p=reject получателите отхвърлят Вашето съобщение към списъка. Съвременният софтуер за списъци решава това, като пренаписва адреса From към адреса на списъка („Jan via Leden“), или като препраща писмото непроменено. Ако използвате списък, който не прави това, ще го видите в отчетите си.

Пренасочване

Вижте урок 3.3: SPF се проваля, DKIM обикновено оцелява. Получателят може с помощта на ARC да реши да се довери на познат пренасочващ сървър. В отчетите това се разпознава като писмо от непознат сървър с DKIM pass и SPF fail; това не е причина да смекчите политиката си.

Два записа или печатна грешка

Два DMARC записа на _dmarc правят политиката невалидна, а печатна грешка в p= също (p=rejected не съществува). Проверявайте след всяка промяна.

На практика: ето как изглежда в панел за управление

При хостинг пакет на WebOké по подразбиране е зададено v=DMARC1;p=reject, без адрес за отчети. Това е безопасно, ако цялата Ви поща минава през тези сървъри. Ако изпращате поща и през други услуги, задайте p=none с адрес rua и преминете през фазите. В DirectAdmin това се прави в DNS Administration с иконата на молив до записа _dmarc (полета Domain policy type и Aggregate Email (RUA)); в Моят WebOké с помощника за DMARC в раздела DNS. При други доставчици създавате TXT запис с име _dmarc и въвеждате текста ръчно; резултатът е същият.

Обобщение

• DMARC е успешен, ако SPF или DKIM успее за домейн, подравнен с домейна от From; relaxed подравняване приема поддомейни.
• Внедряване: инвентаризация, p=none с rua и четене на отчети, p=quarantine (евентуално с t=y), и след това p=reject.
• Използвайте np=reject за несъществуващи поддомейни, щом основната политика е строга. pct, rf и ri са отпаднали.
• Пощенските списъци и пренасочването създават очаквани грешки; DKIM и ARC компенсират част от тях.
• Точно един запис на _dmarc, без печатни грешки.

Тест

Задача

Задача Z4.4: Проверка на DMARC на Вашия домейн и избор на следваща стъпка. Въведете Вашия собствен домейн (или internet.nl). Попълнете DMARC записа, както сте го намерили, стойността на p= и дали в него има адрес rua. След това изберете коя фаза от внедряването според Вас е следващата стъпка и защо. Програмата заявява записа на живо, проверява синтаксиса според RFC 9989 (един запис, валиден p, познати тагове, отпаднали тагове като предупреждение) и поставя Вашите отговори до него.

Да четете повече

Стъпките в тези статии важат за панелите на WebOké; при други доставчици работи по сходен начин.

• Безплатен курс по DNS 4.5: DMARC: какво трябва да правят получателите с фалшива поща
• Ръководство за DirectAdmin 5.9: DMARC инсталиране
• Какво е DMARC? Обяснение на разбираем език
• Създаване на DMARC запис в DirectAdmin
• RFC 9989 (DMARC), по-специално 4.7 (тагове) и приложение C (промени от RFC 7489)