DMARC не минава, но SPF и DKIM минават? Поправката на alignment (2026)

Публикувано 2026-07-08

Данни към 2026-06-29 · методология v7. Агрегирани census данни от 261 милиона оценени домейна. Вижте как оценяваме.

DMARC се нуждае от повече от pass — домейнът, минал SPF или DKIM, трябва да съвпада с вашия From домейн. Повечето „SPF pass, DMARC fail” поща е минала SPF при bounce домейна на доставчика, а не при вашия. Само 7.4% от 261,086,232 оценени домейна минават SPF с alignment под прилагаща DMARC политика, според census-а на Defaults.Exposed (2026-06-29).

Поправката е по-бърза от объркването, което предполага. Прочетете хедъра Authentication-Results, за да видите кой крак — SPF или DKIM — минава при грешния домейн; след това или активирайте персонализирано DKIM подписване на изпращащата услуга (обикновено няколко CNAME записа и поправката, оцеляваща при препращане), или задайте персонализиран return-path, за да мине SPF при вашия домейн. Един aligned крак е всичко, което DMARC изисква.

Как може DMARC да не мине, когато SPF и DKIM и двата минават?

Защото DMARC никога не пита „мина ли SPF?” Пита: мина ли SPF или DKIM за домейн, съвпадащ с From адреса, виждан от получателя? Това допълнително условие се нарича alignment и е цялата цел на DMARC — без него всеки може да мине SPF при домейн, който притежава, докато показва вашия в хедъра From.

Всяка проверка автентикира различен домейн:

Проверка	Домейнът, действително оценяван	Където да го видите
SPF	Return-Path (RFC5321.MailFrom, bounce/envelope-from адресът) — не хедъра From	`smtp.mailfrom=` в Authentication-Results
DKIM	Домейнът в тага `d=` на подписа — каквото и да е избрал подписващият	`header.d=` в Authentication-Results
DMARC	*Вашият From-хедър домейн — и изисква домейнът на SPF или* `d=` на DKIM да съвпада с него**	`header.from=` в Authentication-Results

Ето как нещата обикновено се объркват: платформата за бюлетини или CRM изпраща с Return-Path като [email protected], SPF се проверява спрямо vendor.com и минава, DKIM минава с d=vendor.com — и DMARC не минава, защото нито един от минаващите домейни не съвпада с yourcompany.com. Всяка проверка е казала истината; нито една от тях не ви е автентикирала вас. Редактирането на SPF записа ви не може да поправи това — никога не е бил консултиран. Това е същата клопка, разгледана в SPF неуспех за SaaS инструментите.

Census-ът показва колко малко изпращачи завършват тази последна стъпка: 27,640,987 от 261,086,232 оценени домейна (10.59%) имат прилагаща DMARC политика изобщо, а само 7.4% минават SPF с alignment под такава. Сред 77.5 милиона домейна, чийто SPF завършва с softfail (~all), само 9.2% са под прилагаща DMARC политика; сред публикуващите hardfail (-all), 12,142,351 са приложени, докато 42,514,532 не са. Повечето домейни спират при „SPF минава” — което без DMARC, действащ по него, почти не защитава нищо.

Как да прочета Authentication-Results, за да видя кой крак е неaligned?

Изпратете си съобщение през неминаващата услуга, отворете суровия код и намерете хедъра Authentication-Results. Типичен неaligned резултат изглежда така:

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=bounces.espmail.net;
       dkim=pass header.d=espmail.net;
       dmarc=fail (p=NONE) header.from=yourcompany.com

Прочетете го в три сравнения:

Крак SPF: завършва ли smtp.mailfrom= с вашия домейн? Тук е bounces.espmail.net — не aligned.
Крак DKIM: завършва ли header.d= с вашия домейн? Тук е espmail.net — не aligned.
Присъда DMARC: header.from= е домейнът, защитаван от DMARC. Нито един крак не го е съпоставил, така че dmarc=fail — дори при двете индивидуални проверки, казващи pass.

Кракът, вече включващ вашия собствен домейн (или който може да бъде направен да го прави), е този за поправяне. Нужен ви е само един.

Каква е разликата между relaxed и strict alignment?

DMARC предлага два режима на съпоставяне, задавани с таговете aspf (SPF) и adkim (DKIM) в DMARC записа ви:

Relaxed (r, по подразбиране): двата домейна трябва да споделят един и същ организационен домейн — регистрируемият домейн по Public Suffix List. bounce.yourcompany.com е aligned с yourcompany.com; също и DKIM d=mail.yourcompany.com. Ето защо персонализираните return-path и персонализираният DKIM на доставчиците, живеещи на поддомейни, работят.
Strict (s): домейните трябва да съвпадат точно, символ по символ. bounce.yourcompany.com вече не е aligned с yourcompany.com.

Ако записът ви не споменава aspf или adkim, сте в relaxed режим — и почти сигурно искате да останете там. Strict режимът не добавя значима сигурност за повечето изпращачи и безшумно чупи всеки легитимен изпращач на поддомейн, настроен от вас. Ако DMARC не минава и записът ви съдържа aspf=s или adkim=s, само това може да е грешката.

Как да поправя DMARC alignment?

Стартирайте безплатното сканиране на defaults.exposed преди да докосвате DNS. Показва DMARC записа и политиката, дали SPF и DKIM са настроени да бъдат aligned и какво друго е счупено — за да поправите правилния крак първи.
Тествайте всяка изпращаща услуга и прочетете нейния Authentication-Results (като по-горе). Избройте всеки источник — доставчик на пощенска кутия, инструмент за бюлетини, CRM, приложение за фактуриране — и отбележете за всеки дали smtp.mailfrom и header.d са вашият домейн или на доставчика.
Активирайте персонализирано DKIM подписване за всеки доставчик — поправката, която трае. Всяка сериозна изпращаща услуга предлага „домейн автентикация”: няколко CNAME записа, позволяващи й да подписва като d=yourcompany.com (или поддомейн, aligned в relaxed режим). Aligned DKIM обикновено е по-лесната поправка и единствената, оцеляваща при препращане, защото препращането чупи SPF по дизайн.
За SPF alignment, активирайте персонализирания return-path на доставчика (часто наречен персонализиран bounce домейн) — обикновено един CNAME като bounce.yourcompany.com, сочещ към доставчика. SPF тогава минава при вашия организационен домейн и е aligned. Правете го където се предлага, но го третирайте като втори крак, не заместител на aligned DKIM.
Оставете alignment-а в relaxed режим освен ако нямате конкретна, разбрана причина за aspf=s/adkim=s.
Направете ново сканиране и потвърдете двата крака, след което преминете към прилагане. DMARC политика на p=none докладва, но не блокира нищо; след като реалните изпращачи са aligned, пълният път към политика, защитаваща ви, е на страницата за поправка на DMARC, а ръководствата за доставчици като DMARC в IONOS покриват кликванията в DNS панела.

Трябва ли да поправя SPF alignment или DKIM alignment?

Нужен ви е един aligned крак за всяка изпращаща услуга. Ако можете да направите само едно, изборът не е труден:

Поправка	Какво включва	Оцелява при препращане?
Aligned DKIM (персонализирано подписване)	Няколко CNAME записа в панела „домейн автентикация” на доставчика	Да — подписът пътува с съобщението
Aligned SPF (персонализиран return-path/bounce домейн)	Един CNAME, където доставчикът го предлага	Не — IP-то на всеки препращащ заменя IP-то на доставчика

Специалният случай, заслужаващ да знаете: Google Workspace и Microsoft 365 ще DKIM-подписват пощата ви по подразбиране с техни резервни домейни (gappssmtp.com, onmicrosoft.com) — така DKIM показва pass, докато DMARC все пак не минава. Това е единственият най-честен конкретен случай на целия проблем, и има собствено ръководство: DKIM минава, но DMARC все пак не минава: клопката с подразбиращия се подпис.

Често задавани въпроси

Трябва ли и SPF, и DKIM да са aligned, за да мине DMARC? Не — един aligned pass е достатъчен. Добрата практика е да aligned-нете и двата, за да може когато препращането чупи крака SPF, кракът DKIM все пак да носи DMARC pass-а. От 261,086,232 домейна, оценени в census-а от 2026-06-29, само 3.87% завършват пълната триада SPF + DMARC + DKIM.

Таблото на ESP-а казва, че SPF и DKIM са „verified” — защо DMARC все пак не минава? „Verified” обикновено означава, че изпращането на доставчика минава при домейните на доставчика. Освен ако не сте завършили персонализираните домейн стъпки (DKIM CNAME записи, персонализиран return-path), пощата се автентикира като доставчика, а не като вас — и DMARC сравнява с вашия From домейн.

Строг SPF запис -all достатъчен ли е без alignment? Не. Строгият qualifier засилва присъдата на SPF при домейна Return-Path, но DMARC все пак изисква този домейн да е ваш. Към census-а от 2026-06-29, само 12,142,351 от домейните, публикуващи -all, са под прилагаща DMARC политика — другите 42,514,532 имат строг запис, по който никоя политика не действа.

Трябва ли да превключа към strict alignment (aspf=s/adkim=s) за повече сигурност? Почти никога. Relaxed alignment вече изисква един и същ регистрируем домейн, който спуфърът не контролира. Strict режимът предимно чупи собствените изпращачи на поддомейни — проверявайте за него всеки път, когато alignment неочаквано не минава.

DMARC не минава само при поща, която получателите препращат — същата поправка ли е? Кракът SPF умира по пътя: IP-то на препращащия не е в SPF записа на никого за вашия return-path. Не можете да поправите SPF за препратена поща; aligned DKIM е отговорът, тъй като подписът оцелява при препращане непроменен. Подробности в препратена поща не минава SPF.

Изпратете доклада на собственика

Ако поправяте това за клиент или работодател, затворете цикъла с доказателства. Пуснете отново безплатното сканиране след като CNAME записите са добавени и препратете оценения доклад на собственика на бизнеса: датиран, разбираем за обикновен човек, показващ SPF, DKIM и DMARC aligned и минаващи. Това е артефактът, от който ще се нуждаят за подновяването на киберзастраховката и следващия въпросник за сигурност на доставчик — доказателство за работеща конфигурация, а не просто „добавих DNS записи”.

Проверете домейна → · DKIM минава, но DMARC все пак не минава → · Поправете DMARC → · Как оценяваме → · Само агрегирани данни. Данните се съхраняват и обработват в ЕС.