Defaults.Exposed › Поправки › Guides

DKIM минава, но DMARC не минава: Клопката с подписа по подразбиране gappssmtp.com / onmicrosoft.com (2026)

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

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

Пощата ви минава DKIM с подразбиращия се подпис на доставчика — d= завършващ с gappssmtp.com (Google Workspace) или onmicrosoft.com (Microsoft 365) — но този домейн не съвпада с вашия From домейн, така че DMARC не получава aligned pass. Включете подписване с потребителски домейн, за да го поправите. От 12,145,313 домейна, оторизиращи пощенските сървъри на Google, само 18.5% прилагат DMARC, според census-а на Defaults.Exposed от 261,086,232 оценени домейна.

Поправката е една от най-чистите при автентикацията на имейл: включете персонализирано DKIM подписване за вашия домейн. В Google Workspace това е екранът „Authenticate email” в Admin конзолата — генерирайте ключа, публикувайте един TXT запис, включете го. В Microsoft 365 това е страницата за DKIM в Defender портала — публикувайте два selector CNAME, активирайте. Двадесет минути работа и DMARC най-после получава aligned pass, за който е чакал.

Защо DKIM минава, но DMARC все пак не минава?

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

По подразбиране Google Workspace подписва пощата ви с домейн като yourdomain-com.20230601.gappssmtp.com (датовото клеймо варира за домейн) и Microsoft 365 подписва с yourtenant.onmicrosoft.com. И двата подписа са криптографски валидни — DKIM проверките казват pass — но домейнът d= принадлежи на Google или Microsoft, а не на вас. Дори при relaxed alignment на DMARC, изискващ само съвпадение на организационните домейни, gappssmtp.com не е yourdomain.com. Без съвпадение, без aligned pass, и ако SPF не е aligned (честа ситуация — получателите оценяват SPF спрямо домейна Return-Path, а не хедъра From, и препращането го чупи напълно), DMARC не минава.

Това е определящата клопка на подразбиращите се настройки на доставчиците: подразбиращото се ви дава доставяемост, не защита — alignment е липсващото завъртане на ключа. Census-ът показва колко изпращачи спират при подразбиращото се: от 12,145,313 домейна, оторизиращи пощенските сървъри на Google чрез _spf.google.com (от 138,927,207 SPF публикуващи в света), само 18.5% прилагат DMARC. Картината на Microsoft е на същата форма: 10,205,070 домейна оторизират spf.protection.outlook.com, 85.0% носят строгия SPF запис, даден от настройката на M365 — и само 21.7% прилагат DMARC. Пълно сравнение в нашата таблица на SPF лигата за имейл доставчици.

Клопката е невидима при ежедневна употреба: пощата се доставя, тестовете за inbox изглеждат добре, нищо не дава грешка — докато не публикувате DMARC политика и собствената ви поща не започне да не минава нея. Нашето безплатно сканиране разкрива именно тази пропаст.

Как да разпозная клопката с подразбиращия се подпис в Authentication-Results?

Отворете съобщение, изпратено от вас (до пощенска кутия в Gmail или Outlook), прегледайте оригиналния/суровия код и намерете хедъра Authentication-Results. Признакът е DKIM pass с грешен d= — пример от Gmail изглежда така:

Authentication-Results: mx.google.com;
       dkim=pass [email protected];
       spf=pass smtp.mailfrom=yourdomain.com;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com

Прочетете го като три въпроса:

В поща, получена от Microsoft, същата история се появява като dkim=pass (signature was verified) header.d=yourtenant.onmicrosoft.com заедно с compauth=fail — моделът, разгледан в ръководството за отхвърляне от Outlook.

Ако хедърът ви вместо това показва и dkim=pass, и spf=pass при неуспешен DMARC, намирате се в по-широкия случай с alignment — ръководството за DMARC неуспех при успешни SPF и DKIM разглежда relaxed срещу strict alignment изцяло.

Как да активирам DKIM подписване за персонализиран домейн?

1. Стартирайте безплатното сканиране на defaults.exposed преди да докосвате каквото и да е. Показва дали домейнът ви има aligned DKIM, какво всъщност е DMARC политиката и дали нещо друго (SPF, синтаксис на DMARC запис) пак ще ви блокира след тази поправка — за да свършите цялата работа наведнъж.
2. Идентифицирайте с кой подразбиращ се подпис подписвате. Проверете header.d= в Authentication-Results, както е по-горе: gappssmtp.com означава Google Workspace по подразбиране, onmicrosoft.com означава Microsoft 365 по подразбиране.
3. Google Workspace: генерирайте и публикувайте собствен ключ. В Admin конзолата отидете на Apps → Google Workspace → Gmail → Authenticate email, изберете домейна си и кликнете Generate New Record (2048-bit, освен ако DNS хостът не може да го съхрани). Публикувайте TXT записа на google._domainkey.yourdomain.com, изчакайте DNS (до 48 часа), след това — стъпката, която хората пропускат — кликнете Start authentication. Генерирането на записа не прави нищо, докато не включите подписването. Пълно ръководство: настройка на DKIM в Google Workspace.
4. Microsoft 365: публикувайте двата selector CNAME и активирайте. В Defender портала отидете на Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM, изберете персонализирания домейн и създайте ключовете. Публикувайте двата CNAME — selector1._domainkey и selector2._domainkey, сочещи към целите, показани от Microsoft (копирайте точните цели от портала — домейни, активирани преди май 2025, завършват в .onmicrosoft.com на наемателя; по-новите завършват в .dkim.mail.microsoft) — след което включете подписването. Два селектора не е опционално: Microsoft ротира ключовете между тях. Пълно ръководство: настройка на DKIM в Microsoft 365.
5. Верифицирайте новия подпис. Изпратете ново съобщение до външна пощенска кутия и проверете отново Authentication-Results: dkim=pass трябва сега да показва header.d=yourdomain.com. Ако DNS панелът ви е автоматично прикачил зоната към CNAME целта или е повредил дългата TXT стойност, подписът няма да превключи — специфики на панела, а не на доставчика, причиняват повечето неуспехи тук.
6. Направете ново сканиране и използвайте aligned pass-а за нещо. Потвърдете, че сканирането показва aligned DKIM, след което го използвайте: DMARC политика на p=none не защитава нищо. При всички 261,086,232 оценени домейна само 10.59% прилагат DMARC (данни към 2026-06-29) — aligned DKIM е това, което прави прилагането безопасно за повишаване. Започнете от как да поправите DMARC.

Активирането на персонализиран DKIM ще счупи ли нещо?

Не — това е рядката поправка при автентикацията на имейл с практически никакво взривно действие: поща, излизала с подразбиращия се подпис, просто излиза с по-добър, и доставчикът продължава да управлява ключовете (Microsoft ротира автоматично между двата селектора). Реалният сценарий за неуспех е половинчато изпълнение — публикуване на TXT на Google, но никога не кликане на Start authentication, или публикуване на един M365 selector вместо двата. И не изтривайте DNS записите по-късно „за подредба”; подписването спира в момента, в който ключът изчезне.

Бележка за обхвата: това поправя поща, изпратена чрез Google или Microsoft. Инструментите за бюлетини и CRM подписват и с техни подразбиращи се настройки и всеки се нуждае от активирано персонализирано DKIM — моделът и правилата на Gmail за масови изпращачи, сега изискващи го, са разгледани в ръководството за 550-5.7.26.

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

DKIM показва „pass” на всеки инструмент за проверка — защо трябва да се поправя нещо? Защото инструментите отговарят на по-тесен въпрос от DMARC. Подписът е валиден — но принадлежи на gappssmtp.com или onmicrosoft.com, а не на вас, така че не се брои за нищо при DMARC alignment. Ето защо толкова много изпращачи спират при подразбиращото се: от 12,145,313 домейна, оторизиращи Google, само 18.5% прилагат DMARC (данни към 2026-06-29).

Relaxed DMARC alignment позволява ли подразбиращия се подпис да мине? Не. Relaxed alignment само разхлабва съвпадението до организационните домейни — mail.yourdomain.com е aligned с yourdomain.com. Организационният домейн на подразбиращия се подпис е gappssmtp.com или onmicrosoft.com, което не споделя нищо с вашия. Никакъв режим на alignment не спасява d= на трета страна.

Подписът gappssmtp.com / onmicrosoft.com лош ли е? Трябва ли да го премахна? Не е лош — гарантира, че пощата ви носи някакъв валиден подпис, което помага на spam филтрирането. Просто не е ваш. Не го премахвате; заместете го, като активирате подписване за персонализиран домейн.

Домейнът ми е в Microsoft 365 с строг SPF — вече ли съм покрит? Вероятно не: строгият запис е подразбиращото се на M365, вършещо единствената си работа. От 10,205,070 домейна, оторизиращи spf.protection.outlook.com, 85.0% имат строг SPF, но само 21.7% прилагат DMARC (данни към 2026-06-29). SPF се чупи и при препращане, защото се оценява спрямо Return-Path, а не хедъра From — aligned DKIM е кракът, който оцелява, точно защото тази поправка е важна.

Колко дълго отнема поправката? Работата в конзолата е минути за всеки доставчик. DNS е изчакването: Google казва да се позволи до 48 часа преди стартиране на автентикацията; CNAME записите на Microsoft обикновено са живи в рамките на часове. Планирайте един работен ден от начало до край, повечето от него в изчакване.

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

Ако поправяте това за клиент или работодател, затворете цикъла с доказателства. Пуснете отново безплатното сканиране щом новият подпис е активен и препратете оценения доклад на собственика на бизнеса: датиран, разбираем за обикновен човек, показващ DKIM aligned с техния домейн. Това е артефактът за подновяването на киберзастраховката и следващия въпросник за сигурност на доставчик — доказателство, че домейнът се автентикира като себе си, а не като поднаемател на gappssmtp.com.

Проверете DKIM alignment безплатно

Вижте дали пощата ви се подписва като ваш собствен домейн — и точно какво да поправите — частно и само за собственика.

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